From lnunez@c3isecurity.com Tue May 1 08:27:04 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 76C3221F8C48 for ; Tue, 1 May 2012 08:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKuKoR96TfvM for ; Tue, 1 May 2012 08:27:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8C6B21F8C47 for ; Tue, 1 May 2012 08:27:02 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2253492ghb.31 for ; Tue, 01 May 2012 08:27:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer:x-gm-message-state; bh=7auaklAehzxJOnJatqOlPW/hHzgSrfSGVRWeI0/o0G4=; b=dX3LAMvwcJ6ZOLLfxRH/c+wz1a3Yd6tP6+KIVDKjrxyeccWS9A7e6NwFf/MKadR3oQ dXqgqH4/6auTsT7aMRj2E7SAtxjRSo1ITHPCT1eoqoN5xJjldexPO/faLFR+GHGFeSgP 8MGZXJedG16U8AoQuoQzkWEWZlrgfH1NZlQoplQMV+9Ngi/S4RH5sIORhBf2t9/6jGVh /hNz13tYoHW5ZRZGHuEJGHoNWUChahJIh6t3Imnx5+iRmhOqqunMnwMzvrevXvsu8IIR J+aj5RavSVyc1m2EiIr14mxKnM06PfdkWpIjNl9RsIH/OsADKmA/UWRrBDOO4vhR2mgc cXVA== Received: by 10.236.175.202 with SMTP id z50mr13987416yhl.123.1335886022381; Tue, 01 May 2012 08:27:02 -0700 (PDT) Received: from [172.16.1.100] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id u15sm21893682anb.9.2012.05.01.08.27.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 08:27:01 -0700 (PDT) From: Luis Nunez Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 11:27:00 -0400 References: <2C1BA1EB-2BD9-4B0D-8033-64DF650A3105@c3isecurity.com> To: sacm@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkZAVL3+T7+RF22NzB48iHl+3BVU8Xfu2E8Pr8mweJzyP2eNLVk2lKJ9B0gnXBZyQwlonw1 Subject: [sacm] Fwd: [Content Repositories] Access Vulnerability Database with Java 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, 01 May 2012 15:27:04 -0000 I neglected posting to this list. -ln Begin forwarded message: > From: Luis Nunez > Subject: Re: [Content Repositories] Access Vulnerability Database with = Java > Date: April 30, 2012 12:39:21 PM EDT > To: "OVAL Developer List (Closed Public Discussion)" = >=20 > Cross posting to SACM. =20 >=20 > Depicted in slide 6 of: > http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html=20 >=20 > We see three layers. Authoritative, Organizational and Tool Vendor = content. I think we can evolve to creating a dynamic query once we = establish a "Query/Response" protocol between these entities. Question: = is there an existing protocol we can leverage? Preference being = something that has TLS support. >=20 > As for "Global Registry". Will having one central registry suffice or = will there need to be a disturbed/decentralized regional registry. This = a bigger problem to address along long the lines of globalizing CVE. = But in any case a common protocol to connect will be needed. >=20 > -ln >=20 > On Apr 30, 2012, at 8:52 AM, David Solin wrote: >=20 >> I've been thinking about how a user might interact with such a = capability from a tool like jOVAL or ovaldi, and really I can't think of = a way that it would be practical and useful. Even if you could do = something like upload the CPE ID if your target system, you wouldn't = necessarily always want to scan for every definition that's conceivably = applicable. What you really need is some way to assign the definitions = that are relevant, then have them sucked down automatically by the = scanner. >>=20 >> Interestingly, this is an issue that XCCDF has already solved to some = extent. An XCCDF document has profiles -- so in that way it already = defines what definitions are relevant. XCCDF also has check "hrefs", = which make it possible for the definition to be fetched from a URL that = may point to a dynamic repository. Perhaps better still are XCCDF 1.2 = streams, which define checks inline with the rest of the XCCDF (more or = less) -- so the whole XCCDF document could be generated dynamically by a = server. Working from that angle, you'd only need a URL and a = profile name to pull down all the definitions you want. >>=20 >> XCCDF covers more than just OVAL, however; not sure if that's = considered an issue or a bonus! :) >>=20 >> Regards, >> --David Solin >>=20 >> On 4/30/2012 6:29 AM, Baker, Jon wrote: >>> We would certainly would try to support a standard interface to the = OVAL Repository. If there is interest in the OVAL community we could = hash out the OVAL specific portion of the larger set of security = automation content interfaces that are needed. We could be fairly agile = in developing and testing interfaces in the OVAL Repository if that = would help us to come to agreement around what the standard set should = be. We would be happy to facilitate the community = development of repository interfaces. >>>=20 >>> People have been asking for standard content repository interfaces = for a long time. Perhaps if we start with figuring out what is needed = for OVAL and implementing it we will be able to make some progress as a = community towards addressing the larger need. >>>=20 >>> As a reminder, in addition to the normal web interface to the = repository we have provided a few other ways to grab content from the = repository. >>>=20 >>> - Content RSS Feed - = https://oval.mitre.org/repository/data/rss >>> This link provides some more information about the query parameters = that are supported by the repository feed: = https://oval.mitre.org/rss.html >>>=20 >>> - Download Definition By ID - = https://oval.mitre.org/repository/data/DownloadDefinition?id=3D >>>=20 >>> - Download Test/Object/State/Variable By ID - = https://oval.mitre.org/repository/data/DownloadItem?id=3D >>>=20 >>> These are far from the complete set of interfaces that are needed, = but they are available in the OVAL Repository today. >>>=20 >>> Thanks, >>>=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 >>> From: Gaurav Kumar [mailto:gk@PIVOTALSECURITY.COM]=20 >>> Sent: Saturday, April 28, 2012 3:30 PM >>> To: oval-developer-list OVAL Developer List/Closed Public Discussion >>> Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database = with Java >>>=20 >>> I think it is a great idea. Currently I am associating file names = with platforms based upon their name -for Windows 7 definitions, I am = using microsoft.windows.7.xml. It would be nice if we can have meta-data = associated with content repositories. It can include details like- last = updated, md5/sha1 hash, size, # of defs etc >>>=20 >>> On Sat, Apr 28, 2012 at 9:37 AM, David Solin = wrote: >>> We'd certainly be interested in implementing any such standard. Can = you point me to who's actively discussing it? Does MITRE intend to = support any standard approaches to repository access? >>>=20 >>> Regards, >>> --David >>>=20 >>>=20 >>> On 4/28/2012 6:56 AM, Luis Nunez wrote: >>> You know there is talk of producing a standard spec (sacm) to do = something like this. I know we are busy but something to think about. >>>=20 >>> It would be cool to joval be able to directly query and pull down = content directly from SecPod and other repositories in a common way. >>>=20 >>> -ln >>>=20 >>>=20 >>>=20 >>> On Apr 27, 2012, at 5:39 PM, David Solin wrote: >>>=20 >>>=20 >>> jOVAL provides a ready-to-use JAXB data model for the OVAL language, = various utility classes, and of course, an evaluation engine and scan = plug-ins. It does not, however, implement access to any on-line = repositories. >>>=20 >>> Feel free to contact me directly if you have any questions. >>>=20 >>> Regards, >>> --David Solin >>>=20 >>> -- >>> jOVAL.org: OVAL implemented in Java. >>> Scan any machine from any machine. For free! >>> Learn More | Features | Download >>>=20 >>>=20 >>> On 4/27/2012 8:48 AM, vulists wrote: >>> Hi There, >>>=20 >>> I'm looking for a way to access a Vulnerability Database with Java. >>>=20 >>> At the moment I'm not 100% sure if its gonna be OpenVAS or something >>> else, like e.g. OVAL. >>>=20 >>> I wanted to ask, if somebody knows some ready-to-use Java API to = access >>> "one of those" Vulnerability Databases. >>>=20 >>> If thats not the case, does it mean I have to implement my own XML >>> Parser to get the vulnerability data into my database? >>>=20 >>> What about standard formats? >>>=20 >>>=20 >>> Thanks and kind regards >>>=20 >>> To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with >>> SIGNOFF OVAL-DEVELOPER-LIST >>> in the BODY of the message. If you have difficulties, write to = OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >>>=20 >>> To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >>>=20 >>> To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >>>=20 >>>=20 >>> -- >>> jOVAL.org: OVAL implemented in Java. >>> Scan any machine from any machine. For free! >>> Learn More | Features | Download >>>=20 >>> To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Gaurav Kumar >>> Chief Security Consultant, Pivotal Security LLC | Email: = gk@pivotalsecurity.com | Phone:(425)686-9695=20 >>>=20 >>> To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >>> To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >>=20 >>=20 >> --=20 >> jOVAL.org: OVAL implemented in Java. >> Scan any machine from any machine. For free! >> Learn More | Features | Download >>=20 >> To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >=20 From david.waltermire@nist.gov Wed May 2 14:34: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 6261D11E80C7 for ; Wed, 2 May 2012 14:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.024 X-Spam-Level: X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27DwbolGpALH for ; Wed, 2 May 2012 14:34:18 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D543811E808F for ; Wed, 2 May 2012 14:34:17 -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.355.2; Wed, 2 May 2012 17:34:10 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 2 May 2012 17:34:16 -0400 From: "Waltermire, David A." To: "OVAL Developer List (Closed Public Discussion)" , "sacm@ietf.org" Date: Wed, 2 May 2012 17:34:15 -0400 Thread-Topic: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Thread-Index: Ac0ljIOigBHNzmTYT3mqkxvcsVkXEADF7mug 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_D7A0423E5E193F40BE6E94126930C4930B98F866C3MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java 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, 02 May 2012 21:34:24 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B98F866C3MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" With some of the current email discussion, I'd like to provide a brief update on some projects my team has been working on in this area. We are currently working on the following activities: 1) Prototyping a federated, generalized XML-based content repository approach. The current effort is using a metamodel to describe the key objects (called "entities") in an XML model and the content references (called "relationships") that exist within an XML document. We have developed a shredder that reads in an XML instance, breaking down the entities and relationships. It then persists the XML chunks in an XML database and the entity and relationship information in a non-relational RDF database. We can also request the content back out of the datastore and reconstitute it. The approach we are using does not perturb the underlying XML infoset, so signatures can be verified for content retrieved out of the repository. We are currently working on web service (SOAP and REST) interfaces and a generalized query language. Our current development phase will end in the next couple months. We hope to have a downloadable demo available before Security Automation Developer Days in early July that will support requesting an SCAP datastream or a collection of OVAL/OCIL definitions (and related components) by identifier and version. We are avoiding the registration problem by extracting a DNS name out of the content identifier. For example the content referenced by: oval:org.mitre.oval:def:1 Can be retrieved by the content server "oval.mitre.org". The plan is to use this to lookup a DNS SRV record (RFC 2782) to locate the repository that is responsible for the content identified. This can be used to dynamically retrieve the referenced content. We are just starting to work out an XML format for repository-to-repository information exchange to enable this communication. At this point our current repository code is not far from replacing the data backend that is used for the OVAL repository. The cool thing about the overall approach is that no OVAL specific code is necessary. We have created XML-based shredding rules for SCAP datastream, OVAL 5.10.1 and XCCDF 1.2 formats. It is fairly trivial to create new shredding rules for additional models. You can review the code at: http://code.google.com/p/security-automation-content-repository/ Most of our work is being done in the SVN branch: http://security-automation-content-repository.googlecode.com/svn/branches/new-shredder The documentation is very sparse and the code needs some cleanup. We plan to work on this in the near future. Our long-term goal is to provide a freely available, production capable content repository server that can participate in a federated network of content servers. 2) We have also been working on a content repository specification. The goal for this document is to describe the overall federation approach and to detail the data exchange models, interfaces and transports needed to support interoperability. I plan to have a draft of this specification ready in September. I would be happy to submit this as an individual submission to the IETF when it is more complete. My hope is that this work will address many of the communities challenges in this area. I'd appreciate any thoughts or feedback on this overall approach. Please let me know if you have any questions. I have also requested a session at the Security Automation Developer Days hosted by MITRE in early July to review and discuss this work in greater detail. Sincerely, Dave Waltermire From: Kent Landfield [mailto:Kent_Landfield@MCAFEE.COM] Sent: Saturday, April 28, 2012 6:17 PM To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java ;-) As was properly pointed out to me ...there was a typo in my message... "This is one of the topics I would like to see developed on the SCAM list." Should have been... This is one of the topics I would like to see developed on the SACM list. ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java This has been discussed at the last two ITSAC conference and the Winter Developer Days last year. Discussions have been had around the needs on the SACM list as well. This is an effort to get a standard means for distributing SCAP related content within an organization and as a potentially federated means of managing content developed by guidance authors such as CIS, NIST, other government entities and industry verticals. Couple links to past presentations. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDAQFjAB&url=http%3A%2F%2Fscap.nist.gov%2Fevents%2F2011%2Fsaddsp%2Fpresentations%2FKent_Landfield-Automation_Content_Repositories.pdf&ei=nlOcT-P7L8aWiAKGo6GTAQ&usg=AFQjCNHvTNEztVQmZhkisLkdcB58EpS8Sw&sig2=HY5JjENzc4wMe2tVc4inAA http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf http://scap.nist.gov/events/2011/itsac/presentations/day3/Landfield,%20Chernin,%20Basavanna%20-%20Content%20Repositories.pdf There was also a presentation that Adam Montville prepared for the IETF SACM Side meeting. They are available in the zip file of the presentations located in http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html This is one of the topics I would like to see developed on the SCAM list. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: David Solin > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java We'd certainly be interested in implementing any such standard. Can you point me to who's actively discussing it? Does MITRE intend to support any standard approaches to repository access? Regards, --David On 4/28/2012 6:56 AM, Luis Nunez wrote: You know there is talk of producing a standard spec (sacm) to do something like this. I know we are busy but something to think about. It would be cool to joval be able to directly query and pull down content directly from SecPod and other repositories in a common way. -ln On Apr 27, 2012, at 5:39 PM, David Solin wrote: jOVAL provides a ready-to-use JAXB data model for the OVAL language, various utility classes, and of course, an evaluation engine and scan plug-ins. It does not, however, implement access to any on-line repositories. Feel free to contact me directly if you have any questions. Regards, --David Solin -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download On 4/27/2012 8:48 AM, vulists wrote: Hi There, I'm looking for a way to access a Vulnerability Database with Java. At the moment I'm not 100% sure if its gonna be OpenVAS or something else, like e.g. OVAL. I wanted to ask, if somebody knows some ready-to-use Java API to access "one of those" Vulnerability Databases. If thats not the case, does it mean I have to implement my own XML Parser to get the vulnerability data into my database? What about standard formats? Thanks and kind regards To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. --_000_D7A0423E5E193F40BE6E94126930C4930B98F866C3MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnR0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5 bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2NjU5MzcwMjQ7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyNDQwNjQwMzIgNjc2OTg3MDUgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hl YWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29y ZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldpdGgg c29tZSBvZiB0aGUgY3VycmVudCBlbWFpbCBkaXNjdXNzaW9uLCBJJiM4MjE3O2QgbGlrZSB0byBw cm92aWRlIGEgYnJpZWYgdXBkYXRlIG9uIHNvbWUgcHJvamVjdHMgbXkgdGVhbSBoYXMgYmVlbiB3 b3JraW5nIG9uIGluIHRoaXMgYXJlYS4mbmJzcDsgV2UgYXJlIGN1cnJlbnRseSB3b3JraW5nIG9u IHRoZSBmb2xsb3dpbmcgYWN0aXZpdGllczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xKTxzcGFuIHN0eWxlPSdm b250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ UHJvdG90eXBpbmcgYSBmZWRlcmF0ZWQsIGdlbmVyYWxpemVkIFhNTC1iYXNlZCBjb250ZW50IHJl cG9zaXRvcnkgYXBwcm9hY2guJm5ic3A7IFRoZSBjdXJyZW50IGVmZm9ydCBpcyB1c2luZyBhIG1l dGFtb2RlbCB0byBkZXNjcmliZSB0aGUga2V5IG9iamVjdHMgKGNhbGxlZCAmIzgyMjA7ZW50aXRp ZXMmIzgyMjE7KSBpbiBhbiBYTUwgbW9kZWwgYW5kIHRoZSBjb250ZW50IHJlZmVyZW5jZXMgKGNh bGxlZCAmIzgyMjA7cmVsYXRpb25zaGlwcyYjODIyMTspIHRoYXQgZXhpc3Qgd2l0aGluIGFuIFhN TCBkb2N1bWVudC4mbmJzcDsgV2UgaGF2ZSBkZXZlbG9wZWQgYSBzaHJlZGRlciB0aGF0IHJlYWRz IGluIGFuIFhNTCBpbnN0YW5jZSwgYnJlYWtpbmcgZG93biB0aGUgZW50aXRpZXMgYW5kIHJlbGF0 aW9uc2hpcHMuJm5ic3A7IEl0IHRoZW4gcGVyc2lzdHMgdGhlIFhNTCBjaHVua3MgaW4gYW4gWE1M IGRhdGFiYXNlIGFuZCB0aGUgZW50aXR5IGFuZCByZWxhdGlvbnNoaXAgaW5mb3JtYXRpb24gaW4g YSBub24tcmVsYXRpb25hbCBSREYgZGF0YWJhc2UuJm5ic3A7IFdlIGNhbiBhbHNvIHJlcXVlc3Qg dGhlIGNvbnRlbnQgYmFjayBvdXQgb2YgdGhlIGRhdGFzdG9yZSBhbmQgcmVjb25zdGl0dXRlIGl0 LiZuYnNwOyBUaGUgYXBwcm9hY2ggd2UgYXJlIHVzaW5nIGRvZXMgbm90IHBlcnR1cmIgdGhlIHVu ZGVybHlpbmcgWE1MIGluZm9zZXQsIHNvIHNpZ25hdHVyZXMgY2FuIGJlIHZlcmlmaWVkIGZvciBj b250ZW50IHJldHJpZXZlZCBvdXQgb2YgdGhlIHJlcG9zaXRvcnkuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5XZSBhcmUgY3VycmVudGx5IHdvcmtpbmcgb24gd2ViIHNlcnZpY2Ug KFNPQVAgYW5kIFJFU1QpIGludGVyZmFjZXMgYW5kIGEgZ2VuZXJhbGl6ZWQgcXVlcnkgbGFuZ3Vh Z2UuJm5ic3A7IE91ciBjdXJyZW50IGRldmVsb3BtZW50IHBoYXNlIHdpbGwgZW5kIGluIHRoZSBu ZXh0IGNvdXBsZSBtb250aHMuJm5ic3A7IFdlIGhvcGUgdG8gaGF2ZSBhIGRvd25sb2FkYWJsZSBk ZW1vIGF2YWlsYWJsZSBiZWZvcmUgU2VjdXJpdHkgQXV0b21hdGlvbiBEZXZlbG9wZXIgRGF5cyBp biBlYXJseSBKdWx5IHRoYXQgd2lsbCBzdXBwb3J0IHJlcXVlc3RpbmcgYW4gU0NBUCBkYXRhc3Ry ZWFtIG9yIGEgY29sbGVjdGlvbiBvZiBPVkFML09DSUwgZGVmaW5pdGlvbnMgKGFuZCByZWxhdGVk IGNvbXBvbmVudHMpIGJ5IGlkZW50aWZpZXIgYW5kIHZlcnNpb24uPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPldlIGFyZSBhdm9pZGluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2JsZW0g YnkgZXh0cmFjdGluZyBhIEROUyBuYW1lIG91dCBvZiB0aGUgY29udGVudCBpZGVudGlmaWVyLiZu YnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Rm9yIGV4YW1wbGUgdGhlIGNv bnRlbnQgcmVmZXJlbmNlZCBieTogPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPm92 YWw6b3JnLm1pdHJlLm92YWw6ZGVmOjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Q2FuIGJlIHJldHJpZXZlZCBieSB0aGUgY29udGVudCBzZXJ2ZXIgJiM4MjIwO292YWwubWl0cmUu b3JnJiM4MjIxOy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFw aD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHBsYW4gaXMg dG8gdXNlIHRoaXMgdG8gbG9va3VwIGEgRE5TIFNSViByZWNvcmQgKDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjL3JmYzI3ODIudHh0Ij5SRkMgMjc4MjwvYT4pIHRvIGxvY2F0ZSB0aGUg cmVwb3NpdG9yeSB0aGF0IGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgY29udGVudCBpZGVudGlmaWVk LiZuYnNwOyBUaGlzIGNhbiBiZSB1c2VkIHRvIGR5bmFtaWNhbGx5IHJldHJpZXZlIHRoZSByZWZl cmVuY2VkIGNvbnRlbnQuJm5ic3A7IFdlIGFyZSBqdXN0IHN0YXJ0aW5nIHRvIHdvcmsgb3V0IGFu IFhNTCBmb3JtYXQgZm9yIHJlcG9zaXRvcnktdG8tcmVwb3NpdG9yeSBpbmZvcm1hdGlvbiBleGNo YW5nZSB0byBlbmFibGUgdGhpcyBjb21tdW5pY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5BdCB0aGlzIHBvaW50IG91ciBjdXJyZW50IHJlcG9zaXRvcnkgY29kZSBpcyBu b3QgZmFyIGZyb20gcmVwbGFjaW5nIHRoZSBkYXRhIGJhY2tlbmQgdGhhdCBpcyB1c2VkIGZvciB0 aGUgT1ZBTCByZXBvc2l0b3J5LiZuYnNwOyBUaGUgY29vbCB0aGluZyBhYm91dCB0aGUgb3ZlcmFs bCBhcHByb2FjaCBpcyB0aGF0IG5vIE9WQUwgc3BlY2lmaWMgY29kZSBpcyBuZWNlc3NhcnkuJm5i c3A7IFdlIGhhdmUgY3JlYXRlZCBYTUwtYmFzZWQgc2hyZWRkaW5nIHJ1bGVzIGZvciBTQ0FQIGRh dGFzdHJlYW0sIE9WQUwgNS4xMC4xIGFuZCBYQ0NERiAxLjIgZm9ybWF0cy4gJm5ic3A7SXQgaXMg ZmFpcmx5IHRyaXZpYWwgdG8gY3JlYXRlIG5ldyBzaHJlZGRpbmcgcnVsZXMgZm9yIGFkZGl0aW9u YWwgbW9kZWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Zb3UgY2FuIHJldmll dyB0aGUgY29kZSBhdDogPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9 Imh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9zZWN1cml0eS1hdXRvbWF0aW9uLWNvbnRlbnQtcmVw b3NpdG9yeS8iPmh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9zZWN1cml0eS1hdXRvbWF0aW9uLWNv bnRlbnQtcmVwb3NpdG9yeS88L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk1v c3Qgb2Ygb3VyIHdvcmsgaXMgYmVpbmcgZG9uZSBpbiB0aGUgU1ZOIGJyYW5jaDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PGEgaHJlZj0iaHR0cDovL3NlY3VyaXR5LWF1dG9tYXRp b24tY29udGVudC1yZXBvc2l0b3J5Lmdvb2dsZWNvZGUuY29tL3N2bi9icmFuY2hlcy9uZXctc2hy ZWRkZXIiPmh0dHA6Ly9zZWN1cml0eS1hdXRvbWF0aW9uLWNvbnRlbnQtcmVwb3NpdG9yeS5nb29n bGVjb2RlLmNvbS9zdm4vYnJhbmNoZXMvbmV3LXNocmVkZGVyPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5UaGUgZG9jdW1lbnRhdGlvbiBpcyB2ZXJ5IHNwYXJzZSBhbmQgdGhl IGNvZGUgbmVlZHMgc29tZSBjbGVhbnVwLiZuYnNwOyBXZSBwbGFuIHRvIHdvcmsgb24gdGhpcyBp biB0aGUgbmVhciBmdXR1cmUuJm5ic3A7IE91ciBsb25nLXRlcm0gZ29hbCBpcyB0byBwcm92aWRl IGEgZnJlZWx5IGF2YWlsYWJsZSwgcHJvZHVjdGlvbiBjYXBhYmxlIGNvbnRlbnQgcmVwb3NpdG9y eSBzZXJ2ZXIgdGhhdCBjYW4gcGFydGljaXBhdGUgaW4gYSBmZWRlcmF0ZWQgbmV0d29yayBvZiBj b250ZW50IHNlcnZlcnMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIpPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XZSBo YXZlIGFsc28gYmVlbiB3b3JraW5nIG9uIGEgY29udGVudCByZXBvc2l0b3J5IHNwZWNpZmljYXRp b24uJm5ic3A7IFRoZSBnb2FsIGZvciB0aGlzIGRvY3VtZW50IGlzIHRvIGRlc2NyaWJlIHRoZSBv dmVyYWxsIGZlZGVyYXRpb24gYXBwcm9hY2ggYW5kIHRvIGRldGFpbCB0aGUgZGF0YSBleGNoYW5n ZSBtb2RlbHMsIGludGVyZmFjZXMgYW5kIHRyYW5zcG9ydHMgbmVlZGVkIHRvIHN1cHBvcnQgaW50 ZXJvcGVyYWJpbGl0eS4mbmJzcDsgSSBwbGFuIHRvIGhhdmUgYSBkcmFmdCBvZiB0aGlzIHNwZWNp ZmljYXRpb24gcmVhZHkgaW4gU2VwdGVtYmVyLiZuYnNwOyBJIHdvdWxkIGJlIGhhcHB5IHRvIHN1 Ym1pdCB0aGlzIGFzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiB0byB0aGUgSUVURiB3aGVuIGl0 IGlzIG1vcmUgY29tcGxldGUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NeSBob3BlIGlzIHRoYXQgdGhp cyB3b3JrIHdpbGwgYWRkcmVzcyBtYW55IG9mIHRoZSBjb21tdW5pdGllcyBjaGFsbGVuZ2VzIGlu IHRoaXMgYXJlYS4mbmJzcDsgSSYjODIxNztkIGFwcHJlY2lhdGUgYW55IHRob3VnaHRzIG9yIGZl ZWRiYWNrIG9uIHRoaXMgb3ZlcmFsbCBhcHByb2FjaC4mbmJzcDsgUGxlYXNlIGxldCBtZSBrbm93 IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMuJm5ic3A7IEkgaGF2ZSBhbHNvIHJlcXVlc3RlZCBh IHNlc3Npb24gYXQgdGhlIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXMgaG9zdGVk IGJ5IE1JVFJFIGluIGVhcmx5IEp1bHkgdG8gcmV2aWV3IGFuZCBkaXNjdXNzIHRoaXMgd29yayBp biBncmVhdGVyIGRldGFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U2luY2VyZWx5LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5EYXZlIFdhbHRlcm1pcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBLZW50IExhbmRmaWVsZCBbbWFpbHRvOktlbnRf TGFuZGZpZWxkQE1DQUZFRS5DT01dIDxicj48Yj5TZW50OjwvYj4gU2F0dXJkYXksIEFwcmlsIDI4 LCAyMDEyIDY6MTcgUE08YnI+PGI+VG86PC9iPiBPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1J VFJFLk9SRzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBBY2Nl c3MgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3aXRoIEphdmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjst KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkFzIHdhcyBw cm9wZXJseSBwb2ludGVkIG91dCB0byBtZSAmIzgyMzA7dGhlcmUgd2FzIGEgdHlwbyBpbiBteSBt ZXNzYWdlJiM4MjMwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZxdW90O1RoaXMgaXMgb25lIG9mIHRoZSB0b3BpY3MgSSB3b3VsZCBsaWtlIHRvIHNlZSBk ZXZlbG9wZWQgb24gdGhlIFNDQU0gbGlzdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TaG91bGQgaGF2ZSBiZWVuJiM4MjMwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoaXMgaXMgb25lIG9mIHRoZSB0 b3BpY3MgSSB3b3VsZCBsaWtlIHRvIHNlZSBkZXZlbG9wZWQgb24gdGhlIDxiPlNBQ008L2I+IGxp c3QuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Oy0pPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPktlbnQg TGFuZGZpZWxkPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJyPjxzcGFuIGNs YXNzPWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0 dXJlIGFuZCBTdGFuZGFyZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwv c3Bhbj48L3N0cm9uZz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41MDAwIEhlYWRx dWFydGVycyBEci48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+UGxhbm8s IFRleGFzIDc1MDI0PC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5E aXJlY3Q6ICsxLjk3Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUt c3R5bGUtc3Bhbj5Nb2JpbGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8L3Nw YW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRwOi8v d3d3Lm1jYWZlZS5jb20vIj53d3cubWNhZmVlLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbHQ7TGFuZGZpZWxkJmd0OywgS2VudCBMYW5kZmll bGQgJmx0OzxhIGhyZWY9Im1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tIj5LZW50X0xh bmRmaWVsZEBNY0FmZWUuY29tPC9hPiZndDs8YnI+PGI+UmVwbHktVG86IDwvYj4mcXVvdDtPVkFM IERldmVsb3BlciBMaXN0IChDbG9zZWQgUHVibGljIERpc2N1c3Npb24pJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkciPk9WQUwtREVW RUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZndDs8YnI+PGI+VG86IDwvYj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkciPk9WQUwt REVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1M SVNUQExJU1RTLk1JVFJFLk9SRzwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6IDwvYj5SZTogW09WQUwt REVWRUxPUEVSLUxJU1RdIEFjY2VzcyBWdWxuZXJhYmlsaXR5IERhdGFiYXNlIHdpdGggSmF2YTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48Ymxv Y2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmln aHQ6MGluJyBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2 PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPlRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGF0IHRoZSBsYXN0IHR3byBJVFNBQyBjb25mZXJl bmNlIGFuZCB0aGUgV2ludGVyIERldmVsb3BlciBEYXlzIGxhc3QgeWVhci4gJm5ic3A7RGlzY3Vz c2lvbnMgaGF2ZSBiZWVuIGhhZCBhcm91bmQgdGhlIG5lZWRzIG9uIHRoZSBTQUNNIGxpc3QgYXMg d2VsbC4gJm5ic3A7IFRoaXMgaXMgYW4gZWZmb3J0IHRvIGdldCBhIHN0YW5kYXJkIG1lYW5zIGZv ciBkaXN0cmlidXRpbmcgU0NBUCByZWxhdGVkIGNvbnRlbnQgd2l0aGluIGFuIG9yZ2FuaXphdGlv biBhbmQgYXMgYSBwb3RlbnRpYWxseSBmZWRlcmF0ZWQgbWVhbnMgb2YgbWFuYWdpbmcgY29udGVu dCBkZXZlbG9wZWQgYnkgZ3VpZGFuY2UgYXV0aG9ycyBzdWNoIGFzIENJUywgTklTVCwgb3RoZXIg Z292ZXJubWVudCBlbnRpdGllcyBhbmQgaW5kdXN0cnkgdmVydGljYWxzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkNvdXBsZSBsaW5rcyB0byBwYXN0IHBy ZXNlbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PGEgaHJlZj0iaHR0cDovL3d3dy5nb29nbGUuY29tL3VybD9zYT10JmFtcDtyY3Q9aiZhbXA7 cT0mYW1wO2VzcmM9cyZhbXA7c291cmNlPXdlYiZhbXA7Y2Q9MiZhbXA7dmVkPTBDREFRRmpBQiZh bXA7dXJsPWh0dHAlM0ElMkYlMkZzY2FwLm5pc3QuZ292JTJGZXZlbnRzJTJGMjAxMSUyRnNhZGRz cCUyRnByZXNlbnRhdGlvbnMlMkZLZW50X0xhbmRmaWVsZC1BdXRvbWF0aW9uX0NvbnRlbnRfUmVw b3NpdG9yaWVzLnBkZiZhbXA7ZWk9bmxPY1QtUDdMOGFXaUFLR282R1RBUSZhbXA7dXNnPUFGUWpD Tkh2VE5FenRWUW1aaGtpc0xrZGNCNThFcFM4U3cmYW1wO3NpZzI9SFk1SmpFTnpjNHdNZTJ0VmM0 aW5BQSI+aHR0cDovL3d3dy5nb29nbGUuY29tL3VybD9zYT10JmFtcDtyY3Q9aiZhbXA7cT0mYW1w O2VzcmM9cyZhbXA7c291cmNlPXdlYiZhbXA7Y2Q9MiZhbXA7dmVkPTBDREFRRmpBQiZhbXA7dXJs PWh0dHAlM0ElMkYlMkZzY2FwLm5pc3QuZ292JTJGZXZlbnRzJTJGMjAxMSUyRnNhZGRzcCUyRnBy ZXNlbnRhdGlvbnMlMkZLZW50X0xhbmRmaWVsZC1BdXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9y aWVzLnBkZiZhbXA7ZWk9bmxPY1QtUDdMOGFXaUFLR282R1RBUSZhbXA7dXNnPUFGUWpDTkh2VE5F enRWUW1aaGtpc0xrZGNCNThFcFM4U3cmYW1wO3NpZzI9SFk1SmpFTnpjNHdNZTJ0VmM0aW5BQTwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9zY2FwLm5pc3QuZ292L2V2ZW50cy8y MDExL3NhZGRzcC9wcmVzZW50YXRpb25zL1NlY3VyaXR5X0F1dG9tYXRpb25fQ29udGVudF9SZXBv c2l0b3J5X0RlbW8ucGRmIj5odHRwOi8vc2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9zYWRkc3Av cHJlc2VudGF0aW9ucy9TZWN1cml0eV9BdXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yeV9EZW1v LnBkZjwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGEgaHJlZj0iaHR0cDovL3Nj YXAubmlzdC5nb3YvZXZlbnRzLzIwMTEvaXRzYWMvcHJlc2VudGF0aW9ucy9kYXkzL0xhbmRmaWVs ZCwlMjBDaGVybmluLCUyMEJhc2F2YW5uYSUyMC0lMjBDb250ZW50JTIwUmVwb3NpdG9yaWVzLnBk ZiI+aHR0cDovL3NjYXAubmlzdC5nb3YvZXZlbnRzLzIwMTEvaXRzYWMvcHJlc2VudGF0aW9ucy9k YXkzL0xhbmRmaWVsZCwlMjBDaGVybmluLCUyMEJhc2F2YW5uYSUyMC0lMjBDb250ZW50JTIwUmVw b3NpdG9yaWVzLnBkZjwvYT4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5UaGVyZSB3YXMgYWxzbyBhIHByZXNlbnRhdGlvbiB0aGF0IEFk YW0gTW9udHZpbGxlIHByZXBhcmVkIGZvciB0aGUgSUVURiBTQUNNIFNpZGUgbWVldGluZy4gVGhl eSBhcmUgYXZhaWxhYmxlIGluIHRoZSB6aXAgZmlsZSBvZiB0aGUgcHJlc2VudGF0aW9ucyBsb2Nh dGVkIGluJm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Y29sb3I6YmxhY2snPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zYWNtL2N1cnJlbnQvbXNnMDAxNzguaHRtbCI+aHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NhY20vY3VycmVudC9tc2cwMDE3OC5odG1s PC9hPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGlzIGlzIG9uZSBvZiB0 aGUgdG9waWNzIEkgd291bGQgbGlrZSB0byBzZWUgZGV2ZWxvcGVkIG9uIHRoZSBTQ0FNIGxpc3Qu PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPktl bnQgTGFuZGZpZWxkPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJyPjxzcGFu IGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0 ZWN0dXJlIGFuZCBTdGFuZGFyZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFu eTwvc3Bhbj48L3N0cm9uZz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41MDAwIEhl YWRxdWFydGVycyBEci48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+UGxh bm8sIFRleGFzIDc1MDI0PC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bh bj5EaXJlY3Q6ICsxLjk3Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBw bGUtc3R5bGUtc3Bhbj5Nb2JpbGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8 L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRw Oi8vd3d3Lm1jYWZlZS5jb20vIj53d3cubWNhZmVlLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5EYXZpZCBTb2xpbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmRhdmlkQEpPVkFMLk9SRyI+ZGF2aWRASk9WQUwuT1JHPC9hPiZndDs8YnI+PGI+UmVwbHkt VG86IDwvYj4mcXVvdDtPVkFMIERldmVsb3BlciBMaXN0IChDbG9zZWQgUHVibGljIERpc2N1c3Np b24pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5N SVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZndDs8YnI+ PGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNU Uy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JH Ij5PVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRzwvYT4mZ3Q7PGJyPjxiPlN1Ympl Y3Q6IDwvYj5SZTogW09WQUwtREVWRUxPUEVSLUxJU1RdIEFjY2VzcyBWdWxuZXJhYmlsaXR5IERh dGFiYXNlIHdpdGggSmF2YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0 OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluJyBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSI+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPldlJ2QgY2VydGFpbmx5IGJlIGludGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIGFueSBz dWNoIHN0YW5kYXJkLiZuYnNwOyBDYW4geW91IHBvaW50IG1lIHRvIHdobydzIGFjdGl2ZWx5IGRp c2N1c3NpbmcgaXQ/Jm5ic3A7IERvZXMgTUlUUkUgaW50ZW5kIHRvIHN1cHBvcnQgYW55IHN0YW5k YXJkIGFwcHJvYWNoZXMgdG8gcmVwb3NpdG9yeSBhY2Nlc3M/PGJyPjxicj5SZWdhcmRzLDxicj4t LURhdmlkPGJyPjxicj5PbiA0LzI4LzIwMTIgNjo1NiBBTSwgTHVpcyBOdW5leiB3cm90ZTogPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPllvdSBrbm93IHRoZXJlIGlzIHRhbGsgb2YgcHJvZHVjaW5nIGEgc3RhbmRhcmQgc3Bl YyAoc2FjbSkgdG8gZG8gc29tZXRoaW5nIGxpa2UgdGhpcy4gJm5ic3A7SSBrbm93IHdlIGFyZSBi dXN5IGJ1dCBzb21ldGhpbmcgdG8gdGhpbmsgYWJvdXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPkl0IHdvdWxkIGJlIGNvb2wgdG8gam92YWwgYmUgYWJsZSB0byBk aXJlY3RseSBxdWVyeSBhbmQgcHVsbCBkb3duIGNvbnRlbnQgZGlyZWN0bHkgZnJvbSBTZWNQb2Qg YW5kIG90aGVyIHJlcG9zaXRvcmllcyBpbiBhIGNvbW1vbiB3YXkuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LWxuPG86cD48L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPk9uIEFwciAyNywgMjAxMiwgYXQgNTozOSBQTSwgRGF2aWQgU29s aW4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5qT1ZBTCBwcm92aWRlcyBhIHJlYWR5LXRvLXVzZSBKQVhCIGRh dGEgbW9kZWwgZm9yIHRoZSBPVkFMIGxhbmd1YWdlLCB2YXJpb3VzIHV0aWxpdHkgY2xhc3Nlcywg YW5kIG9mIGNvdXJzZSwgYW4gZXZhbHVhdGlvbiBlbmdpbmUgYW5kIHNjYW4gcGx1Zy1pbnMuJm5i c3A7IEl0IGRvZXMgbm90LCBob3dldmVyLCBpbXBsZW1lbnQgYWNjZXNzIHRvIGFueSBvbi1saW5l IHJlcG9zaXRvcmllcy48YnI+PGJyPkZlZWwgZnJlZSB0byBjb250YWN0IG1lIGRpcmVjdGx5IGlm IHlvdSBoYXZlIGFueSBxdWVzdGlvbnMuPGJyPjxicj5SZWdhcmRzLDxicj4tLURhdmlkIFNvbGlu PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+LS0gPG86cD48L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdsaW5lLWhl aWdodDoxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxhIGhyZWY9Imh0dHA6Ly9qT1ZBTC5v cmciPmpPVkFMLm9yZzwvYT46IE9WQUwgaW1wbGVtZW50ZWQgaW4gSmF2YS48L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojMzMzMzMzJz48YnI+PC9zcGFuPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+U2NhbiBhbnkg bWFjaGluZSBmcm9tIGFueSBtYWNoaW5lLiBGb3IgZnJlZSE8L3NwYW4+PC9pPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzMzMzMzMyc+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuam92YWwub3JnLyI+PHNwYW4gc3R5bGU9 J2NvbG9yOiMzMzY2MDAnPkxlYXJuIE1vcmU8L3NwYW4+PC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly93 d3cuam92YWwub3JnL2ZlYXR1cmVzLyI+PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzY2MDAnPkZlYXR1 cmVzPC9zcGFuPjwvYT4gfCA8YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy9kb3dubG9hZC8i PjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5Eb3dubG9hZDwvc3Bhbj48L2E+IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48YnI+T24gNC8yNy8yMDEyIDg6NDggQU0sIHZ1bGlzdHMgd3JvdGU6IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+SGkgVGhlcmUsPG86 cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5J J20gbG9va2luZyBmb3IgYSB3YXkgdG8gYWNjZXNzIGEgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3 aXRoIEphdmEuPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz5BdCB0aGUgbW9tZW50IEknbSBub3QgMTAwJSBzdXJlIGlmIGl0cyBnb25uYSBi ZSBPcGVuVkFTIG9yIHNvbWV0aGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5lbHNlLCBsaWtlIGUuZy4gT1ZBTC48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkkgd2FudGVkIHRvIGFz aywgaWYgc29tZWJvZHkga25vd3Mgc29tZSByZWFkeS10by11c2UgSmF2YSBBUEkgdG8gYWNjZXNz PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZx dW90O29uZSBvZiB0aG9zZSZxdW90OyBWdWxuZXJhYmlsaXR5IERhdGFiYXNlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPklmIHRoYXRz IG5vdCB0aGUgY2FzZSwgZG9lcyBpdCBtZWFuIEkgaGF2ZSB0byBpbXBsZW1lbnQgbXkgb3duIFhN TDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5Q YXJzZXIgdG8gZ2V0IHRoZSB2dWxuZXJhYmlsaXR5IGRhdGEgaW50byBteSBkYXRhYmFzZT88bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPldo YXQgYWJvdXQgc3RhbmRhcmQgZm9ybWF0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+PHBy ZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl PjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGFua3MgYW5kIGtpbmQgcmVnYXJkczxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byA8YSBocmVmPSJtYWlsdG86 TElTVFNFUlZATElTVFMuTUlUUkUuT1JHIj5MSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc8L2E+IHdp dGg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ U0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmluIHRoZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiZuYnNw OyBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIDxhIGhyZWY9Im1haWx0bzpPVkFM LURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1M SVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byA8YSBocmVm PSJtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHIj5MSVNUU0VSVkBMSVNUUy5NSVRSRS5P Ukc8L2E+IHdpdGggU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRo ZSBtZXNzYWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIDxhIGhyZWY9Im1h aWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURF VkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9hPi4gPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbyB1bnN1YnNjcmliZSwgc2VuZCBh biBlbWFpbCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5P UkciPkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzwvYT4gd2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxP UEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3Vs dGllcywgd3JpdGUgdG8gPGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVz dEBMSVNUUy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRS RS5PUkc8L2E+LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J2xpbmUtaGVp Z2h0OjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+ak9WQUwub3JnOiBPVkFMIGltcGxlbWVu dGVkIGluIEphdmEuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+PGJyPjwvc3Bhbj48aT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiMzMzMzMzMnPlNjYW4gYW55IG1hY2hpbmUgZnJvbSBhbnkgbWFjaGluZS4gRm9yIGZy ZWUhPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxicj48YSBocmVmPSJodHRwOi8vd3d3 LmpvdmFsLm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzY2MDAnPkxlYXJuIE1vcmU8L3NwYW4+ PC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly93d3cuam92YWwub3JnL2ZlYXR1cmVzLyI+PHNwYW4gc3R5 bGU9J2NvbG9yOiMzMzY2MDAnPkZlYXR1cmVzPC9zcGFuPjwvYT4gfCA8YSBocmVmPSJodHRwOi8v d3d3LmpvdmFsLm9yZy9kb3dubG9hZC8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5Eb3du bG9hZDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRvIHVuc3Vic2NyaWJlLCBzZW5kIGFuIGVt YWlsIG1lc3NhZ2UgdG8gPGEgaHJlZj0ibWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRyI+ TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPC9hPiB3aXRoIFNJR05PRkYgT1ZBTC1ERVZFTE9QRVIt TElTVCBpbiB0aGUgQk9EWSBvZiB0aGUgbWVzc2FnZS4gSWYgeW91IGhhdmUgZGlmZmljdWx0aWVz LCB3cml0ZSB0byA8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJ U1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9S RzwvYT4uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VG8gdW5zdWJzY3JpYmUs IHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byA8YSBocmVmPSJtYWlsdG86TElTVFNFUlZATElTVFMu TUlUUkUuT1JHIj5MSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc8L2E+IHdpdGggU0lHTk9GRiBPVkFM LURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiBJZiB5b3UgaGF2ZSBk aWZmaWN1bHRpZXMsIHdyaXRlIHRvIDxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNU LXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElT VFMuTUlUUkUuT1JHPC9hPi4gPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxv Y2txdW90ZT48cCBjbGFzcz1Nc29Ob3JtYWw+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwg bWVzc2FnZSB0byA8YSBocmVmPSJtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHIj5MSVNU U0VSVkBMSVNUUy5NSVRSRS5PUkc8L2E+IHdpdGggU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNU IGluIHRoZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdy aXRlIHRvIDxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMu TUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9h Pi4gPG86cD48L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930B98F866C3MBCLUSTERxcha_-- From michael.hammer@yaanatech.com Wed May 2 16:34: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 6FAC021E8054 for ; Wed, 2 May 2012 16:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvqexwlvSLCG for ; Wed, 2 May 2012 16:34:25 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 9922621E8042 for ; Wed, 2 May 2012 16:34:25 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 2 May 2012 16:34:20 -0700 From: Michael Hammer To: "david.waltermire@nist.gov" , "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" , "sacm@ietf.org" Thread-Topic: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Thread-Index: Ac0ljIOigBHNzmTYT3mqkxvcsVkXEADF7mugAAXtH1A= Date: Wed, 2 May 2012 23:34:20 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38A6DAD@EX2K10MB1.corp.yaanatech.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01CD289A.91545470" MIME-Version: 1.0 Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java 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, 02 May 2012 23:34:31 -0000 ------=_NextPart_000_0011_01CD289A.91545470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01CD289A.91545470" ------=_NextPart_001_0012_01CD289A.91545470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David, Is there any IPR associated with this? Mike From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, May 02, 2012 5:34 PM To: OVAL Developer List (Closed Public Discussion); sacm@ietf.org Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java With some of the current email discussion, I'd like to provide a brief update on some projects my team has been working on in this area. We are currently working on the following activities: 1) Prototyping a federated, generalized XML-based content repository approach. The current effort is using a metamodel to describe the key objects (called "entities") in an XML model and the content references (called "relationships") that exist within an XML document. We have developed a shredder that reads in an XML instance, breaking down the entities and relationships. It then persists the XML chunks in an XML database and the entity and relationship information in a non-relational RDF database. We can also request the content back out of the datastore and reconstitute it. The approach we are using does not perturb the underlying XML infoset, so signatures can be verified for content retrieved out of the repository. We are currently working on web service (SOAP and REST) interfaces and a generalized query language. Our current development phase will end in the next couple months. We hope to have a downloadable demo available before Security Automation Developer Days in early July that will support requesting an SCAP datastream or a collection of OVAL/OCIL definitions (and related components) by identifier and version. We are avoiding the registration problem by extracting a DNS name out of the content identifier. For example the content referenced by: oval:org.mitre.oval:def:1 Can be retrieved by the content server "oval.mitre.org". The plan is to use this to lookup a DNS SRV record (RFC 2782 ) to locate the repository that is responsible for the content identified. This can be used to dynamically retrieve the referenced content. We are just starting to work out an XML format for repository-to-repository information exchange to enable this communication. At this point our current repository code is not far from replacing the data backend that is used for the OVAL repository. The cool thing about the overall approach is that no OVAL specific code is necessary. We have created XML-based shredding rules for SCAP datastream, OVAL 5.10.1 and XCCDF 1.2 formats. It is fairly trivial to create new shredding rules for additional models. You can review the code at: http://code.google.com/p/security-automation-content-repository/ Most of our work is being done in the SVN branch: http://security-automation-content-repository.googlecode.com/svn/branches/ne w-shredder The documentation is very sparse and the code needs some cleanup. We plan to work on this in the near future. Our long-term goal is to provide a freely available, production capable content repository server that can participate in a federated network of content servers. 2) We have also been working on a content repository specification. The goal for this document is to describe the overall federation approach and to detail the data exchange models, interfaces and transports needed to support interoperability. I plan to have a draft of this specification ready in September. I would be happy to submit this as an individual submission to the IETF when it is more complete. My hope is that this work will address many of the communities challenges in this area. I'd appreciate any thoughts or feedback on this overall approach. Please let me know if you have any questions. I have also requested a session at the Security Automation Developer Days hosted by MITRE in early July to review and discuss this work in greater detail. Sincerely, Dave Waltermire From: Kent Landfield [mailto:Kent_Landfield@MCAFEE.COM] Sent: Saturday, April 28, 2012 6:17 PM To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java ;-) As was properly pointed out to me .there was a typo in my message. "This is one of the topics I would like to see developed on the SCAM list." Should have been. This is one of the topics I would like to see developed on the SACM list. ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java This has been discussed at the last two ITSAC conference and the Winter Developer Days last year. Discussions have been had around the needs on the SACM list as well. This is an effort to get a standard means for distributing SCAP related content within an organization and as a potentially federated means of managing content developed by guidance authors such as CIS, NIST, other government entities and industry verticals. Couple links to past presentations. http://www.google.com/url?sa=t &rct=j&q=&esrc=s&source=web&cd=2&ved=0CDAQFjAB&url=http%3A%2F%2Fscap.nist.go v%2Fevents%2F2011%2Fsaddsp%2Fpresentations%2FKent_Landfield-Automation_Conte nt_Repositories.pdf&ei=nlOcT-P7L8aWiAKGo6GTAQ&usg=AFQjCNHvTNEztVQmZhkisLkdcB 58EpS8Sw&sig2=HY5JjENzc4wMe2tVc4inAA http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Co ntent_Repository_Demo.pdf http://scap.nist.gov/events/2011/itsac/presentations/day3/Landfield,%20Chern in,%20Basavanna%20-%20Content%20Repositories.pdf There was also a presentation that Adam Montville prepared for the IETF SACM Side meeting. They are available in the zip file of the presentations located in http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html This is one of the topics I would like to see developed on the SCAM list. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: David Solin Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java We'd certainly be interested in implementing any such standard. Can you point me to who's actively discussing it? Does MITRE intend to support any standard approaches to repository access? Regards, --David On 4/28/2012 6:56 AM, Luis Nunez wrote: You know there is talk of producing a standard spec (sacm) to do something like this. I know we are busy but something to think about. It would be cool to joval be able to directly query and pull down content directly from SecPod and other repositories in a common way. -ln On Apr 27, 2012, at 5:39 PM, David Solin wrote: jOVAL provides a ready-to-use JAXB data model for the OVAL language, various utility classes, and of course, an evaluation engine and scan plug-ins. It does not, however, implement access to any on-line repositories. Feel free to contact me directly if you have any questions. Regards, --David Solin -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download On 4/27/2012 8:48 AM, vulists wrote: Hi There, I'm looking for a way to access a Vulnerability Database with Java. At the moment I'm not 100% sure if its gonna be OpenVAS or something else, like e.g. OVAL. I wanted to ask, if somebody knows some ready-to-use Java API to access "one of those" Vulnerability Databases. If thats not the case, does it mean I have to implement my own XML Parser to get the vulnerability data into my database? What about standard formats? Thanks and kind regards To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. ------=_NextPart_001_0012_01CD289A.91545470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

 

Is there any IPR associated with this?

 

Mike

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Waltermire, David A.
Sent: Wednesday, May 02, 2012 5:34 = PM
To: OVAL Developer List (Closed Public Discussion); = sacm@ietf.org
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access = Vulnerability Database with Java

 

With some of the current email discussion, I’d like to provide = a brief update on some projects my team has been working on in this = area.  We are currently working on the following = activities:

 

1)      = Prototyping a federated, generalized XML-based content repository = approach.  The current effort is using a metamodel to describe the = key objects (called “entities”) in an XML model and the = content references (called “relationships”) that exist = within an XML document.  We have developed a shredder that reads in = an XML instance, breaking down the entities and relationships.  It = then persists the XML chunks in an XML database and the entity and = relationship information in a non-relational RDF database.  We can = also request the content back out of the datastore and reconstitute = it.  The approach we are using does not perturb the underlying XML = infoset, so signatures can be verified for content retrieved out of the = repository.

 

We are currently working on web service (SOAP and REST) interfaces = and a generalized query language.  Our current development phase = will end in the next couple months.  We hope to have a downloadable = demo available before Security Automation Developer Days in early July = that will support requesting an SCAP datastream or a collection of = OVAL/OCIL definitions (and related components) by identifier and = version.

 

We are avoiding the registration problem by extracting a DNS name out = of the content identifier. 

 

For example the content referenced by:

 

oval:org.mitre.oval:def:1

 

Can be retrieved by the content server = “oval.mitre.org”.

 

The plan is to use this to lookup a DNS SRV record (RFC 2782) to locate the = repository that is responsible for the content identified.  This = can be used to dynamically retrieve the referenced content.  We are = just starting to work out an XML format for repository-to-repository = information exchange to enable this = communication.

 

At this point our current repository code is not far from replacing = the data backend that is used for the OVAL repository.  The cool = thing about the overall approach is that no OVAL specific code is = necessary.  We have created XML-based shredding rules for SCAP = datastream, OVAL 5.10.1 and XCCDF 1.2 formats.  It is fairly = trivial to create new shredding rules for additional = models.

 

You can review the code at:

 

http://code.google.com/p/security-automation-content-repository/

 

Most of our work is being done in the SVN = branch:

 

http://security-automation-content-repository.goog= lecode.com/svn/branches/new-shredder

 

The documentation is very sparse and the code needs some = cleanup.  We plan to work on this in the near future.  Our = long-term goal is to provide a freely available, production capable = content repository server that can participate in a federated network of = content servers.

 

2)      = We have also been working on a content repository = specification.  The goal for this document is to describe the = overall federation approach and to detail the data exchange models, = interfaces and transports needed to support interoperability.  I = plan to have a draft of this specification ready in September.  I = would be happy to submit this as an individual submission to the IETF = when it is more complete.

 

My hope is that this work will address many of the communities = challenges in this area.  I’d appreciate any thoughts or = feedback on this overall approach.  Please let me know if you have = any questions.  I have also requested a session at the Security = Automation Developer Days hosted by MITRE in early July to review and = discuss this work in greater detail.

 

Sincerely,

Dave Waltermire

 

From:= = Kent Landfield [mailto:Kent_Landfield= @MCAFEE.COM]
Sent: Saturday, April 28, 2012 6:17 = PM
To: OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG
Subject: Re: [OVAL-DEVELOPER-LIST] Access = Vulnerability Database with Java

 

;-)

 

As was properly pointed = out to me …there was a typo in my = message…

 

"This is one of the = topics I would like to see developed on the SCAM = list."

 

Should have = been…

 

This is one of the topics = I would like to see developed on the SACM = list.

 

;-)

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

=

 

From: <Landfield>, Kent Landfield <Kent_Landfield@McAfee.com&g= t;
Reply-To: "OVAL Developer List (Closed Public = Discussion)" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] = Access Vulnerability Database with = Java

 

This has been discussed at = the last two ITSAC conference and the Winter Developer Days last year. =  Discussions have been had around the needs on the SACM list as = well.   This is an effort to get a standard means for distributing = SCAP related content within an organization and as a potentially = federated means of managing content developed by guidance authors such = as CIS, NIST, other government entities and industry = verticals.

 

Couple links to past = presentations.

 

 

 

 

There was also a = presentation that Adam Montville prepared for the IETF SACM Side = meeting. They are available in the zip file of the presentations located = in = http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html =

 

This is one of the topics = I would like to see developed on the SCAM = list.

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

=

 

From: David Solin <david@JOVAL.ORG>
Reply-To: = "OVAL Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] = Access Vulnerability Database with = Java

 

We'd certainly be = interested in implementing any such standard.  Can you point me to = who's actively discussing it?  Does MITRE intend to support any = standard approaches to repository = access?

Regards,
--David

On 4/28/2012 6:56 AM, Luis = Nunez wrote:

You know there is talk of producing a standard = spec (sacm) to do something like this.  I know we are busy but = something to think about.

 

It would be cool to joval = be able to directly query and pull down content directly from SecPod and = other repositories in a common way.

 

-ln

 

 

 

On Apr 27, 2012, at 5:39 = PM, David Solin wrote:

 

jOVAL provides a ready-to-use JAXB data model for = the OVAL language, various utility classes, and of course, an evaluation = engine and scan plug-ins.  It does not, however, implement access = to any on-line repositories.

Feel free to contact me directly if = you have any questions.

Regards,
--David = Solin

--

jOVAL.org: OVAL implemented in = Java.=
= Scan any machine from any machine. For free!=
Learn More | Features | Download =


On 4/27/2012 8:48 AM, vulists wrote: = 

Hi =
There,
 
I'm looking for a way to access a Vulnerability =
Database with Java.
 
At the moment I'm not 100% sure if its gonna be =
OpenVAS or something
else, like e.g. =
OVAL.
 
I wanted to ask, if somebody knows some =
ready-to-use Java API to access
"one of those" Vulnerability =
Databases.
 
If thats not the case, does it mean I have to =
implement my own XML
Parser to get the vulnerability data into my =
database?
 
What about standard =
formats?
 
 
Thanks and kind =
regards
 
To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG =
with
SIGNOFF =
OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have =
difficulties, write to OVAL-DEVELOPE=
R-LIST-request@LISTS.MITRE.ORG.

 

To unsubscribe, send an = email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

 

To unsubscribe, send an = email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

 

-- =

jOVAL.org: OVAL implemented in Java.=
= Scan any machine from any machine. For free!=
Learn = More | Features | Download

To unsubscribe, send an = email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG. =

To unsubscribe, send an = email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG. =

To = unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

------=_NextPart_001_0012_01CD289A.91545470-- ------=_NextPart_000_0011_01CD289A.91545470 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUw MjIzMzQxOVowIwYJKoZIhvcNAQkEMRYEFIVDVQe/KLrVRCBrzaQvjAXXFMW0MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAWE+z9hIAj/DZ+O0Fb5vdbLJC2oGsxLvWBKpXBQXAuPEP kyWff/q63ZsMoZV0kYe7BvY8EM6GAPgsyqRYsEm4/vnI/yVsppywGzxavSv7ja30lkevzCtwtLNW XZiuIIbWlY+MZ/HdBYZ0w/RMmgcb7ulMEuvyRrNqPg08Ogk9gbEAAAAAAAA= ------=_NextPart_000_0011_01CD289A.91545470-- From solin@farnamhallventures.com Wed May 2 16:56:55 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 DA77B21F84E6 for ; Wed, 2 May 2012 16:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8EJC7Os1Nnv for ; Wed, 2 May 2012 16:56:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF321F84E4 for ; Wed, 2 May 2012 16:56:50 -0700 (PDT) Received: by yenq7 with SMTP id q7so1537286yen.31 for ; Wed, 02 May 2012 16:56:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=QRovuH6LU0MuHw135PTp4RO1z24inYpNetT4IwAVryg=; b=Ld3MQqInVIfqS/LGV5PvU/sJ0rUB+hy4xAGki6+n/zP5iqRL/9O/egbTq+CWIE1PAT ecYi1faoj6VumF2OB6+LMtODR2Lls+ppwHqVNTPlZ24/tUorNQLWRL0w/MzenEnnnKwS NYEB+GiihxQfta1uDM1spKWOKFIohojt0hppP0ENwK47N0nOQnpke2Nw+/AOOVMKmKQ1 LQuK0BugK35/3bof3056vGVIrgBrKVV6G9YuF6o9up4ZGO9S7y7ir/pL//KU0ukqHaCz qRRKnDytjFOPeplOcf/h3AVewDyr5+LucHtTF5DioY+3BNjKvh8Cmz4RTmc9Sdp4IJW9 3IQQ== Received: by 10.60.20.230 with SMTP id q6mr48732oee.60.1336003010040; Wed, 02 May 2012 16:56:50 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id j2sm3803632obn.1.2012.05.02.16.56.47 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 16:56:48 -0700 (PDT) Sender: David Solin Message-ID: <4FA1C9B2.3000101@joval.org> Date: Wed, 02 May 2012 18:56:34 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sacm@ietf.org References: <00C069FD01E0324C9FFCADF539701DB38A6DAD@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A6DAD@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------000008010205000707060101" X-Gm-Message-State: ALoCoQl+SIZ0kxR2faS1OKn4ynq1XlAVfqCHvd13Bz1Mjn94D0PKD7Hxd03bwuDYGx6pooLnOhvW Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java 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, 02 May 2012 23:56:56 -0000 This is a multi-part message in MIME format. --------------000008010205000707060101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi David, Will this project include a reference client implementation? Will your team be seeking comments on the REST and SOAP interfaces? Regards, --David Solin On 5/2/2012 6:34 PM, Michael Hammer wrote: > > David, > > Is there any IPR associated with this? > > Mike > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Waltermire, David A. > *Sent:* Wednesday, May 02, 2012 5:34 PM > *To:* OVAL Developer List (Closed Public Discussion); sacm@ietf.org > *Subject:* Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability > Database with Java > > With some of the current email discussion, I'd like to provide a brief > update on some projects my team has been working on in this area. We > are currently working on the following activities: > > 1)Prototyping a federated, generalized XML-based content repository > approach. The current effort is using a metamodel to describe the key > objects (called "entities") in an XML model and the content references > (called "relationships") that exist within an XML document. We have > developed a shredder that reads in an XML instance, breaking down the > entities and relationships. It then persists the XML chunks in an XML > database and the entity and relationship information in a > non-relational RDF database. We can also request the content back out > of the datastore and reconstitute it. The approach we are using does > not perturb the underlying XML infoset, so signatures can be verified > for content retrieved out of the repository. > > We are currently working on web service (SOAP and REST) interfaces and > a generalized query language. Our current development phase will end > in the next couple months. We hope to have a downloadable demo > available before Security Automation Developer Days in early July that > will support requesting an SCAP datastream or a collection of > OVAL/OCIL definitions (and related components) by identifier and version. > > We are avoiding the registration problem by extracting a DNS name out > of the content identifier. > > For example the content referenced by: > > oval:org.mitre.oval:def:1 > > Can be retrieved by the content server "oval.mitre.org". > > The plan is to use this to lookup a DNS SRV record (RFC 2782 > ) to locate the repository that > is responsible for the content identified. This can be used to > dynamically retrieve the referenced content. We are just starting to > work out an XML format for repository-to-repository information > exchange to enable this communication. > > At this point our current repository code is not far from replacing > the data backend that is used for the OVAL repository. The cool thing > about the overall approach is that no OVAL specific code is > necessary. We have created XML-based shredding rules for SCAP > datastream, OVAL 5.10.1 and XCCDF 1.2 formats. It is fairly trivial > to create new shredding rules for additional models. > > You can review the code at: > > http://code.google.com/p/security-automation-content-repository/ > > Most of our work is being done in the SVN branch: > > http://security-automation-content-repository.googlecode.com/svn/branches/new-shredder > > The documentation is very sparse and the code needs some cleanup. We > plan to work on this in the near future. Our long-term goal is to > provide a freely available, production capable content repository > server that can participate in a federated network of content servers. > > 2)We have also been working on a content repository specification. > The goal for this document is to describe the overall federation > approach and to detail the data exchange models, interfaces and > transports needed to support interoperability. I plan to have a draft > of this specification ready in September. I would be happy to submit > this as an individual submission to the IETF when it is more complete. > > My hope is that this work will address many of the communities > challenges in this area. I'd appreciate any thoughts or feedback on > this overall approach. Please let me know if you have any questions. > I have also requested a session at the Security Automation Developer > Days hosted by MITRE in early July to review and discuss this work in > greater detail. > > Sincerely, > > Dave Waltermire > > *From:*Kent Landfield [mailto:Kent_Landfield@MCAFEE.COM] > > *Sent:* Saturday, April 28, 2012 6:17 PM > *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > > *Subject:* Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database > with Java > > ;-) > > As was properly pointed out to me ...there was a typo in my message... > > "This is one of the topics I would like to see developed on the SCAM > list." > > Should have been... > > This is one of the topics I would like to see developed on the *SACM* > list. > > ;-) > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Kent Landfield > > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > > > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > " > > > *Subject: *Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database > with Java > > This has been discussed at the last two ITSAC conference and the > Winter Developer Days last year. Discussions have been had around > the needs on the SACM list as well. This is an effort to get a > standard means for distributing SCAP related content within an > organization and as a potentially federated means of managing > content developed by guidance authors such as CIS, NIST, other > government entities and industry verticals. > > Couple links to past presentations. > > http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDAQFjAB&url=http%3A%2F%2Fscap.nist.gov%2Fevents%2F2011%2Fsaddsp%2Fpresentations%2FKent_Landfield-Automation_Content_Repositories.pdf&ei=nlOcT-P7L8aWiAKGo6GTAQ&usg=AFQjCNHvTNEztVQmZhkisLkdcB58EpS8Sw&sig2=HY5JjENzc4wMe2tVc4inAA > > > http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf > > http://scap.nist.gov/events/2011/itsac/presentations/day3/Landfield,%20Chernin,%20Basavanna%20-%20Content%20Repositories.pdf > > > There was also a presentation that Adam Montville prepared for the > IETF SACM Side meeting. They are available in the zip file of the > presentations located in > http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html > > This is one of the topics I would like to see developed on the > SCAM list. > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *David Solin > > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > > > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > " > > > *Subject: *Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database > with Java > > We'd certainly be interested in implementing any such > standard. Can you point me to who's actively discussing it? > Does MITRE intend to support any standard approaches to > repository access? > > Regards, > --David > > On 4/28/2012 6:56 AM, Luis Nunez wrote: > > You know there is talk of producing a standard spec (sacm) to > do something like this. I know we are busy but something to > think about. > > It would be cool to joval be able to directly query and pull > down content directly from SecPod and other repositories in a > common way. > > -ln > > On Apr 27, 2012, at 5:39 PM, David Solin wrote: > > jOVAL provides a ready-to-use JAXB data model for the OVAL > language, various utility classes, and of course, an > evaluation engine and scan plug-ins. It does not, however, > implement access to any on-line repositories. > > Feel free to contact me directly if you have any questions. > > Regards, > --David Solin > > -- > > jOVAL.org : OVAL implemented in Java. > /Scan any machine from any machine. For free!/ > Learn More | Features > | Download > > > > On 4/27/2012 8:48 AM, vulists wrote: > > Hi There, > > > > I'm looking for a way to access a Vulnerability Database with Java. > > > > At the moment I'm not 100% sure if its gonna be OpenVAS or something > > else, like e.g. OVAL. > > > > I wanted to ask, if somebody knows some ready-to-use Java API to access > > "one of those" Vulnerability Databases. > > > > If thats not the case, does it mean I have to implement my own XML > > Parser to get the vulnerability data into my database? > > > > What about standard formats? > > > > > > Thanks and kind regards > > > > To unsubscribe, send an email message toLISTSERV@LISTS.MITRE.ORG with > > SIGNOFF OVAL-DEVELOPER-LIST > > in the BODY of the message. If you have difficulties, write toOVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG > with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. > If you have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG > with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. > If you have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > -- > > jOVAL.org: OVAL implemented in Java. > /Scan any machine from any machine. For free!/ > Learn More | Features > | Download > > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG > with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. > If you have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG > with SIGNOFF OVAL-DEVELOPER-LIST > in the BODY of the message. If you have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG > with SIGNOFF OVAL-DEVELOPER-LIST in > the BODY of the message. If you have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download --------------000008010205000707060101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi David,

Will this project include a reference client implementation?  Will your team be seeking comments on the REST and SOAP interfaces?

Regards,
--David Solin

On 5/2/2012 6:34 PM, Michael Hammer wrote:

David,

 

Is there any IPR associated with this?

 

Mike

 

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Wednesday, May 02, 2012 5:34 PM
To: OVAL Developer List (Closed Public Discussion); sacm@ietf.org
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java

 

With some of the current email discussion, I’d like to provide a brief update on some projects my team has been working on in this area.  We are currently working on the following activities:

 

1)      Prototyping a federated, generalized XML-based content repository approach.  The current effort is using a metamodel to describe the key objects (called “entities”) in an XML model and the content references (called “relationships”) that exist within an XML document.  We have developed a shredder that reads in an XML instance, breaking down the entities and relationships.  It then persists the XML chunks in an XML database and the entity and relationship information in a non-relational RDF database.  We can also request the content back out of the datastore and reconstitute it.  The approach we are using does not perturb the underlying XML infoset, so signatures can be verified for content retrieved out of the repository.

 

We are currently working on web service (SOAP and REST) interfaces and a generalized query language.  Our current development phase will end in the next couple months.  We hope to have a downloadable demo available before Security Automation Developer Days in early July that will support requesting an SCAP datastream or a collection of OVAL/OCIL definitions (and related components) by identifier and version.

 

We are avoiding the registration problem by extracting a DNS name out of the content identifier. 

 

For example the content referenced by:

 

oval:org.mitre.oval:def:1

 

Can be retrieved by the content server “oval.mitre.org”.

 

The plan is to use this to lookup a DNS SRV record (RFC 2782) to locate the repository that is responsible for the content identified.  This can be used to dynamically retrieve the referenced content.  We are just starting to work out an XML format for repository-to-repository information exchange to enable this communication.

 

At this point our current repository code is not far from replacing the data backend that is used for the OVAL repository.  The cool thing about the overall approach is that no OVAL specific code is necessary.  We have created XML-based shredding rules for SCAP datastream, OVAL 5.10.1 and XCCDF 1.2 formats.  It is fairly trivial to create new shredding rules for additional models.

 

You can review the code at:

 

http://code.google.com/p/security-automation-content-repository/

 

Most of our work is being done in the SVN branch:

 

http://security-automation-content-repository.googlecode.com/svn/branches/new-shredder

 

The documentation is very sparse and the code needs some cleanup.  We plan to work on this in the near future.  Our long-term goal is to provide a freely available, production capable content repository server that can participate in a federated network of content servers.

 

2)      We have also been working on a content repository specification.  The goal for this document is to describe the overall federation approach and to detail the data exchange models, interfaces and transports needed to support interoperability.  I plan to have a draft of this specification ready in September.  I would be happy to submit this as an individual submission to the IETF when it is more complete.

 

My hope is that this work will address many of the communities challenges in this area.  I’d appreciate any thoughts or feedback on this overall approach.  Please let me know if you have any questions.  I have also requested a session at the Security Automation Developer Days hosted by MITRE in early July to review and discuss this work in greater detail.

 

Sincerely,

Dave Waltermire

 

From: Kent Landfield [mailto:Kent_Landfield@MCAFEE.COM]
Sent: Saturday, April 28, 2012 6:17 PM
To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java

 

;-)

 

As was properly pointed out to me …there was a typo in my message…

 

"This is one of the topics I would like to see developed on the SCAM list."

 

Should have been…

 

This is one of the topics I would like to see developed on the SACM list.

 

;-)

 

Kent Landfield
Director Content Strategy, Architecture and Standards

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

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: <Landfield>, Kent Landfield <Kent_Landfield@McAfee.com>
Reply-To: "OVAL Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java

 

This has been discussed at the last two ITSAC conference and the Winter Developer Days last year.  Discussions have been had around the needs on the SACM list as well.   This is an effort to get a standard means for distributing SCAP related content within an organization and as a potentially federated means of managing content developed by guidance authors such as CIS, NIST, other government entities and industry verticals.

 

Couple links to past presentations.

 

 

 

 

There was also a presentation that Adam Montville prepared for the IETF SACM Side meeting. They are available in the zip file of the presentations located in http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html 

 

This is one of the topics I would like to see developed on the SCAM list.

 

Kent Landfield
Director Content Strategy, Architecture and Standards

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

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: David Solin <david@JOVAL.ORG>
Reply-To: "OVAL Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java

 

We'd certainly be interested in implementing any such standard.  Can you point me to who's actively discussing it?  Does MITRE intend to support any standard approaches to repository access?

Regards,
--David

On 4/28/2012 6:56 AM, Luis Nunez wrote:

You know there is talk of producing a standard spec (sacm) to do something like this.  I know we are busy but something to think about.

 

It would be cool to joval be able to directly query and pull down content directly from SecPod and other repositories in a common way.

 

-ln

 

 

 

On Apr 27, 2012, at 5:39 PM, David Solin wrote:

 

jOVAL provides a ready-to-use JAXB data model for the OVAL language, various utility classes, and of course, an evaluation engine and scan plug-ins.  It does not, however, implement access to any on-line repositories.

Feel free to contact me directly if you have any questions.

Regards,
--David Solin

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download


On 4/27/2012 8:48 AM, vulists wrote: 

Hi There,
 
I'm looking for a way to access a Vulnerability Database with Java.
 
At the moment I'm not 100% sure if its gonna be OpenVAS or something
else, like e.g. OVAL.
 
I wanted to ask, if somebody knows some ready-to-use Java API to access
"one of those" Vulnerability Databases.
 
If thats not the case, does it mean I have to implement my own XML
Parser to get the vulnerability data into my database?
 
What about standard formats?
 
 
Thanks and kind regards
 
To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

 

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

 

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. 



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


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

--------------000008010205000707060101-- From david.waltermire@nist.gov Wed May 2 19:35: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 F0A7221E802A for ; Wed, 2 May 2012 19:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBuINq4m2w7S for ; Wed, 2 May 2012 19:35:31 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9F021E8019 for ; Wed, 2 May 2012 19:35:30 -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.355.2; Wed, 2 May 2012 22:35:24 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 2 May 2012 22:35:02 -0400 From: "Waltermire, David A." To: "'michael.hammer@yaanatech.com'" , "'OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG'" , "'sacm@ietf.org'" Date: Wed, 2 May 2012 22:35:01 -0400 Thread-Topic: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Thread-Index: Ac0ljIOigBHNzmTYT3mqkxvcsVkXEADF7mugAAXtH1AABllzcg== Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A6DAD@EX2K10MB1.corp.yaanatech.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_D7A0423E5E193F40BE6E94126930C4930B981E80A5MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java 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, 03 May 2012 02:35:38 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B981E80A5MBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm9uZSB0aGF0IEkgYW0gYXdhcmUgb2YuIFRoaXMgd29yayB3aWxsIGJlIHJlbGVhc2VkIGluIHRo ZSBwdWJsaWMgZG9tYWluLg0KRGF2ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbTogTWljaGFlbCBIYW1tZXIgPG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20+DQpU bzogV2FsdGVybWlyZSwgRGF2aWQgQS47IE9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUu T1JHIDxPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRz47IHNhY21AaWV0Zi5vcmcg PHNhY21AaWV0Zi5vcmc+DQpTZW50OiBXZWQgTWF5IDAyIDE5OjM0OjIwIDIwMTINClN1YmplY3Q6 IFJFOiBbc2FjbV0gW09WQUwtREVWRUxPUEVSLUxJU1RdIEFjY2VzcyBWdWxuZXJhYmlsaXR5IERh dGFiYXNlIHdpdGggSmF2YQ0KDQpEYXZpZCwNCg0KSXMgdGhlcmUgYW55IElQUiBhc3NvY2lhdGVk IHdpdGggdGhpcz8NCg0KTWlrZQ0KDQoNCkZyb206IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdhbHRlcm1pcmUsIERhdmlk IEEuDQpTZW50OiBXZWRuZXNkYXksIE1heSAwMiwgMjAxMiA1OjM0IFBNDQpUbzogT1ZBTCBEZXZl bG9wZXIgTGlzdCAoQ2xvc2VkIFB1YmxpYyBEaXNjdXNzaW9uKTsgc2FjbUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtzYWNtXSBbT1ZBTC1ERVZFTE9QRVItTElTVF0gQWNjZXNzIFZ1bG5lcmFiaWxp dHkgRGF0YWJhc2Ugd2l0aCBKYXZhDQoNCldpdGggc29tZSBvZiB0aGUgY3VycmVudCBlbWFpbCBk aXNjdXNzaW9uLCBJ4oCZZCBsaWtlIHRvIHByb3ZpZGUgYSBicmllZiB1cGRhdGUgb24gc29tZSBw cm9qZWN0cyBteSB0ZWFtIGhhcyBiZWVuIHdvcmtpbmcgb24gaW4gdGhpcyBhcmVhLiAgV2UgYXJl IGN1cnJlbnRseSB3b3JraW5nIG9uIHRoZSBmb2xsb3dpbmcgYWN0aXZpdGllczoNCg0KDQoxKSAg ICAgIFByb3RvdHlwaW5nIGEgZmVkZXJhdGVkLCBnZW5lcmFsaXplZCBYTUwtYmFzZWQgY29udGVu dCByZXBvc2l0b3J5IGFwcHJvYWNoLiAgVGhlIGN1cnJlbnQgZWZmb3J0IGlzIHVzaW5nIGEgbWV0 YW1vZGVsIHRvIGRlc2NyaWJlIHRoZSBrZXkgb2JqZWN0cyAoY2FsbGVkIOKAnGVudGl0aWVz4oCd KSBpbiBhbiBYTUwgbW9kZWwgYW5kIHRoZSBjb250ZW50IHJlZmVyZW5jZXMgKGNhbGxlZCDigJxy ZWxhdGlvbnNoaXBz4oCdKSB0aGF0IGV4aXN0IHdpdGhpbiBhbiBYTUwgZG9jdW1lbnQuICBXZSBo YXZlIGRldmVsb3BlZCBhIHNocmVkZGVyIHRoYXQgcmVhZHMgaW4gYW4gWE1MIGluc3RhbmNlLCBi cmVha2luZyBkb3duIHRoZSBlbnRpdGllcyBhbmQgcmVsYXRpb25zaGlwcy4gIEl0IHRoZW4gcGVy c2lzdHMgdGhlIFhNTCBjaHVua3MgaW4gYW4gWE1MIGRhdGFiYXNlIGFuZCB0aGUgZW50aXR5IGFu ZCByZWxhdGlvbnNoaXAgaW5mb3JtYXRpb24gaW4gYSBub24tcmVsYXRpb25hbCBSREYgZGF0YWJh c2UuICBXZSBjYW4gYWxzbyByZXF1ZXN0IHRoZSBjb250ZW50IGJhY2sgb3V0IG9mIHRoZSBkYXRh c3RvcmUgYW5kIHJlY29uc3RpdHV0ZSBpdC4gIFRoZSBhcHByb2FjaCB3ZSBhcmUgdXNpbmcgZG9l cyBub3QgcGVydHVyYiB0aGUgdW5kZXJseWluZyBYTUwgaW5mb3NldCwgc28gc2lnbmF0dXJlcyBj YW4gYmUgdmVyaWZpZWQgZm9yIGNvbnRlbnQgcmV0cmlldmVkIG91dCBvZiB0aGUgcmVwb3NpdG9y eS4NCg0KDQoNCldlIGFyZSBjdXJyZW50bHkgd29ya2luZyBvbiB3ZWIgc2VydmljZSAoU09BUCBh bmQgUkVTVCkgaW50ZXJmYWNlcyBhbmQgYSBnZW5lcmFsaXplZCBxdWVyeSBsYW5ndWFnZS4gIE91 ciBjdXJyZW50IGRldmVsb3BtZW50IHBoYXNlIHdpbGwgZW5kIGluIHRoZSBuZXh0IGNvdXBsZSBt b250aHMuICBXZSBob3BlIHRvIGhhdmUgYSBkb3dubG9hZGFibGUgZGVtbyBhdmFpbGFibGUgYmVm b3JlIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXMgaW4gZWFybHkgSnVseSB0aGF0 IHdpbGwgc3VwcG9ydCByZXF1ZXN0aW5nIGFuIFNDQVAgZGF0YXN0cmVhbSBvciBhIGNvbGxlY3Rp b24gb2YgT1ZBTC9PQ0lMIGRlZmluaXRpb25zIChhbmQgcmVsYXRlZCBjb21wb25lbnRzKSBieSBp ZGVudGlmaWVyIGFuZCB2ZXJzaW9uLg0KDQoNCg0KV2UgYXJlIGF2b2lkaW5nIHRoZSByZWdpc3Ry YXRpb24gcHJvYmxlbSBieSBleHRyYWN0aW5nIGEgRE5TIG5hbWUgb3V0IG9mIHRoZSBjb250ZW50 IGlkZW50aWZpZXIuDQoNCg0KDQpGb3IgZXhhbXBsZSB0aGUgY29udGVudCByZWZlcmVuY2VkIGJ5 Og0KDQoNCg0Kb3ZhbDpvcmcubWl0cmUub3ZhbDpkZWY6MQ0KDQoNCg0KQ2FuIGJlIHJldHJpZXZl ZCBieSB0aGUgY29udGVudCBzZXJ2ZXIg4oCcb3ZhbC5taXRyZS5vcmfigJ0uDQoNCg0KDQpUaGUg cGxhbiBpcyB0byB1c2UgdGhpcyB0byBsb29rdXAgYSBETlMgU1JWIHJlY29yZCAoUkZDIDI3ODI8 aHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMjc4Mi50eHQ+KSB0byBsb2NhdGUgdGhlIHJlcG9z aXRvcnkgdGhhdCBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGNvbnRlbnQgaWRlbnRpZmllZC4gIFRo aXMgY2FuIGJlIHVzZWQgdG8gZHluYW1pY2FsbHkgcmV0cmlldmUgdGhlIHJlZmVyZW5jZWQgY29u dGVudC4gIFdlIGFyZSBqdXN0IHN0YXJ0aW5nIHRvIHdvcmsgb3V0IGFuIFhNTCBmb3JtYXQgZm9y IHJlcG9zaXRvcnktdG8tcmVwb3NpdG9yeSBpbmZvcm1hdGlvbiBleGNoYW5nZSB0byBlbmFibGUg dGhpcyBjb21tdW5pY2F0aW9uLg0KDQoNCg0KQXQgdGhpcyBwb2ludCBvdXIgY3VycmVudCByZXBv c2l0b3J5IGNvZGUgaXMgbm90IGZhciBmcm9tIHJlcGxhY2luZyB0aGUgZGF0YSBiYWNrZW5kIHRo YXQgaXMgdXNlZCBmb3IgdGhlIE9WQUwgcmVwb3NpdG9yeS4gIFRoZSBjb29sIHRoaW5nIGFib3V0 IHRoZSBvdmVyYWxsIGFwcHJvYWNoIGlzIHRoYXQgbm8gT1ZBTCBzcGVjaWZpYyBjb2RlIGlzIG5l Y2Vzc2FyeS4gIFdlIGhhdmUgY3JlYXRlZCBYTUwtYmFzZWQgc2hyZWRkaW5nIHJ1bGVzIGZvciBT Q0FQIGRhdGFzdHJlYW0sIE9WQUwgNS4xMC4xIGFuZCBYQ0NERiAxLjIgZm9ybWF0cy4gIEl0IGlz IGZhaXJseSB0cml2aWFsIHRvIGNyZWF0ZSBuZXcgc2hyZWRkaW5nIHJ1bGVzIGZvciBhZGRpdGlv bmFsIG1vZGVscy4NCg0KDQoNCllvdSBjYW4gcmV2aWV3IHRoZSBjb2RlIGF0Og0KDQoNCg0KaHR0 cDovL2NvZGUuZ29vZ2xlLmNvbS9wL3NlY3VyaXR5LWF1dG9tYXRpb24tY29udGVudC1yZXBvc2l0 b3J5Lw0KDQoNCg0KTW9zdCBvZiBvdXIgd29yayBpcyBiZWluZyBkb25lIGluIHRoZSBTVk4gYnJh bmNoOg0KDQoNCg0KaHR0cDovL3NlY3VyaXR5LWF1dG9tYXRpb24tY29udGVudC1yZXBvc2l0b3J5 Lmdvb2dsZWNvZGUuY29tL3N2bi9icmFuY2hlcy9uZXctc2hyZWRkZXINCg0KDQoNClRoZSBkb2N1 bWVudGF0aW9uIGlzIHZlcnkgc3BhcnNlIGFuZCB0aGUgY29kZSBuZWVkcyBzb21lIGNsZWFudXAu ICBXZSBwbGFuIHRvIHdvcmsgb24gdGhpcyBpbiB0aGUgbmVhciBmdXR1cmUuICBPdXIgbG9uZy10 ZXJtIGdvYWwgaXMgdG8gcHJvdmlkZSBhIGZyZWVseSBhdmFpbGFibGUsIHByb2R1Y3Rpb24gY2Fw YWJsZSBjb250ZW50IHJlcG9zaXRvcnkgc2VydmVyIHRoYXQgY2FuIHBhcnRpY2lwYXRlIGluIGEg ZmVkZXJhdGVkIG5ldHdvcmsgb2YgY29udGVudCBzZXJ2ZXJzLg0KDQoNCg0KMikgICAgICBXZSBo YXZlIGFsc28gYmVlbiB3b3JraW5nIG9uIGEgY29udGVudCByZXBvc2l0b3J5IHNwZWNpZmljYXRp b24uICBUaGUgZ29hbCBmb3IgdGhpcyBkb2N1bWVudCBpcyB0byBkZXNjcmliZSB0aGUgb3ZlcmFs bCBmZWRlcmF0aW9uIGFwcHJvYWNoIGFuZCB0byBkZXRhaWwgdGhlIGRhdGEgZXhjaGFuZ2UgbW9k ZWxzLCBpbnRlcmZhY2VzIGFuZCB0cmFuc3BvcnRzIG5lZWRlZCB0byBzdXBwb3J0IGludGVyb3Bl cmFiaWxpdHkuICBJIHBsYW4gdG8gaGF2ZSBhIGRyYWZ0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBy ZWFkeSBpbiBTZXB0ZW1iZXIuICBJIHdvdWxkIGJlIGhhcHB5IHRvIHN1Ym1pdCB0aGlzIGFzIGFu IGluZGl2aWR1YWwgc3VibWlzc2lvbiB0byB0aGUgSUVURiB3aGVuIGl0IGlzIG1vcmUgY29tcGxl dGUuDQoNCk15IGhvcGUgaXMgdGhhdCB0aGlzIHdvcmsgd2lsbCBhZGRyZXNzIG1hbnkgb2YgdGhl IGNvbW11bml0aWVzIGNoYWxsZW5nZXMgaW4gdGhpcyBhcmVhLiAgSeKAmWQgYXBwcmVjaWF0ZSBh bnkgdGhvdWdodHMgb3IgZmVlZGJhY2sgb24gdGhpcyBvdmVyYWxsIGFwcHJvYWNoLiAgUGxlYXNl IGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMuICBJIGhhdmUgYWxzbyByZXF1 ZXN0ZWQgYSBzZXNzaW9uIGF0IHRoZSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlz IGhvc3RlZCBieSBNSVRSRSBpbiBlYXJseSBKdWx5IHRvIHJldmlldyBhbmQgZGlzY3VzcyB0aGlz IHdvcmsgaW4gZ3JlYXRlciBkZXRhaWwuDQoNClNpbmNlcmVseSwNCkRhdmUgV2FsdGVybWlyZQ0K DQpGcm9tOiBLZW50IExhbmRmaWVsZCBbbWFpbHRvOktlbnRfTGFuZGZpZWxkQE1DQUZFRS5DT01d PG1haWx0bzpbbWFpbHRvOktlbnRfTGFuZGZpZWxkQE1DQUZFRS5DT01dPg0KU2VudDogU2F0dXJk YXksIEFwcmlsIDI4LCAyMDEyIDY6MTcgUE0NClRvOiBPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RT Lk1JVFJFLk9SRzxtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc+DQpT dWJqZWN0OiBSZTogW09WQUwtREVWRUxPUEVSLUxJU1RdIEFjY2VzcyBWdWxuZXJhYmlsaXR5IERh dGFiYXNlIHdpdGggSmF2YQ0KDQo7LSkNCg0KQXMgd2FzIHByb3Blcmx5IHBvaW50ZWQgb3V0IHRv IG1lIOKApnRoZXJlIHdhcyBhIHR5cG8gaW4gbXkgbWVzc2FnZeKApg0KDQoiVGhpcyBpcyBvbmUg b2YgdGhlIHRvcGljcyBJIHdvdWxkIGxpa2UgdG8gc2VlIGRldmVsb3BlZCBvbiB0aGUgU0NBTSBs aXN0LiINCg0KU2hvdWxkIGhhdmUgYmVlbuKApg0KDQpUaGlzIGlzIG9uZSBvZiB0aGUgdG9waWNz IEkgd291bGQgbGlrZSB0byBzZWUgZGV2ZWxvcGVkIG9uIHRoZSBTQUNNIGxpc3QuDQoNCjstKQ0K DQpLZW50IExhbmRmaWVsZA0KRGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJl IGFuZCBTdGFuZGFyZHMNCg0KTWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueQ0KNTAwMCBIZWFkcXVh cnRlcnMgRHIuDQpQbGFubywgVGV4YXMgNzUwMjQNCg0KRGlyZWN0OiArMS45NzIuOTYzLjcwOTYN Ck1vYmlsZTogKzEuODE3LjYzNy44MDI2DQpXZWI6IHd3dy5tY2FmZWUuY29tPGh0dHA6Ly93d3cu bWNhZmVlLmNvbS8+DQoNCkZyb206IDxMYW5kZmllbGQ+LCBLZW50IExhbmRmaWVsZCA8S2VudF9M YW5kZmllbGRATWNBZmVlLmNvbTxtYWlsdG86S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbT4+DQpS ZXBseS1UbzogIk9WQUwgRGV2ZWxvcGVyIExpc3QgKENsb3NlZCBQdWJsaWMgRGlzY3Vzc2lvbiki IDxPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRzxtYWlsdG86T1ZBTC1ERVZFTE9Q RVItTElTVEBMSVNUUy5NSVRSRS5PUkc+Pg0KVG86ICJPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RT Lk1JVFJFLk9SRzxtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc+IiA8 T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOk9WQUwtREVWRUxPUEVS LUxJU1RATElTVFMuTUlUUkUuT1JHPj4NClN1YmplY3Q6IFJlOiBbT1ZBTC1ERVZFTE9QRVItTElT VF0gQWNjZXNzIFZ1bG5lcmFiaWxpdHkgRGF0YWJhc2Ugd2l0aCBKYXZhDQoNClRoaXMgaGFzIGJl ZW4gZGlzY3Vzc2VkIGF0IHRoZSBsYXN0IHR3byBJVFNBQyBjb25mZXJlbmNlIGFuZCB0aGUgV2lu dGVyIERldmVsb3BlciBEYXlzIGxhc3QgeWVhci4gIERpc2N1c3Npb25zIGhhdmUgYmVlbiBoYWQg YXJvdW5kIHRoZSBuZWVkcyBvbiB0aGUgU0FDTSBsaXN0IGFzIHdlbGwuICAgVGhpcyBpcyBhbiBl ZmZvcnQgdG8gZ2V0IGEgc3RhbmRhcmQgbWVhbnMgZm9yIGRpc3RyaWJ1dGluZyBTQ0FQIHJlbGF0 ZWQgY29udGVudCB3aXRoaW4gYW4gb3JnYW5pemF0aW9uIGFuZCBhcyBhIHBvdGVudGlhbGx5IGZl ZGVyYXRlZCBtZWFucyBvZiBtYW5hZ2luZyBjb250ZW50IGRldmVsb3BlZCBieSBndWlkYW5jZSBh dXRob3JzIHN1Y2ggYXMgQ0lTLCBOSVNULCBvdGhlciBnb3Zlcm5tZW50IGVudGl0aWVzIGFuZCBp bmR1c3RyeSB2ZXJ0aWNhbHMuDQoNCkNvdXBsZSBsaW5rcyB0byBwYXN0IHByZXNlbnRhdGlvbnMu DQoNCmh0dHA6Ly93d3cuZ29vZ2xlLmNvbS91cmw/c2E9dCZyY3Q9aiZxPSZlc3JjPXMmc291cmNl PXdlYiZjZD0yJnZlZD0wQ0RBUUZqQUImdXJsPWh0dHAlM0ElMkYlMkZzY2FwLm5pc3QuZ292JTJG ZXZlbnRzJTJGMjAxMSUyRnNhZGRzcCUyRnByZXNlbnRhdGlvbnMlMkZLZW50X0xhbmRmaWVsZC1B dXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yaWVzLnBkZiZlaT1ubE9jVC1QN0w4YVdpQUtHbzZH VEFRJnVzZz1BRlFqQ05IdlRORXp0VlFtWmhraXNMa2RjQjU4RXBTOFN3JnNpZzI9SFk1SmpFTnpj NHdNZTJ0VmM0aW5BQQ0KDQpodHRwOi8vc2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9zYWRkc3Av cHJlc2VudGF0aW9ucy9TZWN1cml0eV9BdXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yeV9EZW1v LnBkZg0KDQpodHRwOi8vc2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9pdHNhYy9wcmVzZW50YXRp b25zL2RheTMvTGFuZGZpZWxkLCUyMENoZXJuaW4sJTIwQmFzYXZhbm5hJTIwLSUyMENvbnRlbnQl MjBSZXBvc2l0b3JpZXMucGRmDQoNClRoZXJlIHdhcyBhbHNvIGEgcHJlc2VudGF0aW9uIHRoYXQg QWRhbSBNb250dmlsbGUgcHJlcGFyZWQgZm9yIHRoZSBJRVRGIFNBQ00gU2lkZSBtZWV0aW5nLiBU aGV5IGFyZSBhdmFpbGFibGUgaW4gdGhlIHppcCBmaWxlIG9mIHRoZSBwcmVzZW50YXRpb25zIGxv Y2F0ZWQgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NhY20vY3VycmVu dC9tc2cwMDE3OC5odG1sDQoNClRoaXMgaXMgb25lIG9mIHRoZSB0b3BpY3MgSSB3b3VsZCBsaWtl IHRvIHNlZSBkZXZlbG9wZWQgb24gdGhlIFNDQU0gbGlzdC4NCg0KS2VudCBMYW5kZmllbGQNCkRp cmVjdG9yIENvbnRlbnQgU3RyYXRlZ3ksIEFyY2hpdGVjdHVyZSBhbmQgU3RhbmRhcmRzDQoNCk1j QWZlZSB8IEFuIEludGVsIENvbXBhbnkNCjUwMDAgSGVhZHF1YXJ0ZXJzIERyLg0KUGxhbm8sIFRl eGFzIDc1MDI0DQoNCkRpcmVjdDogKzEuOTcyLjk2My43MDk2DQpNb2JpbGU6ICsxLjgxNy42Mzcu ODAyNg0KV2ViOiB3d3cubWNhZmVlLmNvbTxodHRwOi8vd3d3Lm1jYWZlZS5jb20vPg0KDQpGcm9t OiBEYXZpZCBTb2xpbiA8ZGF2aWRASk9WQUwuT1JHPG1haWx0bzpkYXZpZEBKT1ZBTC5PUkc+Pg0K UmVwbHktVG86ICJPVkFMIERldmVsb3BlciBMaXN0IChDbG9zZWQgUHVibGljIERpc2N1c3Npb24p IiA8T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOk9WQUwtREVWRUxP UEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPj4NClRvOiAiT1ZBTC1ERVZFTE9QRVItTElTVEBMSVNU Uy5NSVRSRS5PUkc8bWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPiIg PE9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPG1haWx0bzpPVkFMLURFVkVMT1BF Ui1MSVNUQExJU1RTLk1JVFJFLk9SRz4+DQpTdWJqZWN0OiBSZTogW09WQUwtREVWRUxPUEVSLUxJ U1RdIEFjY2VzcyBWdWxuZXJhYmlsaXR5IERhdGFiYXNlIHdpdGggSmF2YQ0KDQpXZSdkIGNlcnRh aW5seSBiZSBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyBhbnkgc3VjaCBzdGFuZGFyZC4gIENh biB5b3UgcG9pbnQgbWUgdG8gd2hvJ3MgYWN0aXZlbHkgZGlzY3Vzc2luZyBpdD8gIERvZXMgTUlU UkUgaW50ZW5kIHRvIHN1cHBvcnQgYW55IHN0YW5kYXJkIGFwcHJvYWNoZXMgdG8gcmVwb3NpdG9y eSBhY2Nlc3M/DQoNClJlZ2FyZHMsDQotLURhdmlkDQoNCk9uIDQvMjgvMjAxMiA2OjU2IEFNLCBM dWlzIE51bmV6IHdyb3RlOg0KWW91IGtub3cgdGhlcmUgaXMgdGFsayBvZiBwcm9kdWNpbmcgYSBz dGFuZGFyZCBzcGVjIChzYWNtKSB0byBkbyBzb21ldGhpbmcgbGlrZSB0aGlzLiAgSSBrbm93IHdl IGFyZSBidXN5IGJ1dCBzb21ldGhpbmcgdG8gdGhpbmsgYWJvdXQuDQoNCkl0IHdvdWxkIGJlIGNv b2wgdG8gam92YWwgYmUgYWJsZSB0byBkaXJlY3RseSBxdWVyeSBhbmQgcHVsbCBkb3duIGNvbnRl bnQgZGlyZWN0bHkgZnJvbSBTZWNQb2QgYW5kIG90aGVyIHJlcG9zaXRvcmllcyBpbiBhIGNvbW1v biB3YXkuDQoNCi1sbg0KDQoNCg0KT24gQXByIDI3LCAyMDEyLCBhdCA1OjM5IFBNLCBEYXZpZCBT b2xpbiB3cm90ZToNCg0Kak9WQUwgcHJvdmlkZXMgYSByZWFkeS10by11c2UgSkFYQiBkYXRhIG1v ZGVsIGZvciB0aGUgT1ZBTCBsYW5ndWFnZSwgdmFyaW91cyB1dGlsaXR5IGNsYXNzZXMsIGFuZCBv ZiBjb3Vyc2UsIGFuIGV2YWx1YXRpb24gZW5naW5lIGFuZCBzY2FuIHBsdWctaW5zLiAgSXQgZG9l cyBub3QsIGhvd2V2ZXIsIGltcGxlbWVudCBhY2Nlc3MgdG8gYW55IG9uLWxpbmUgcmVwb3NpdG9y aWVzLg0KDQpGZWVsIGZyZWUgdG8gY29udGFjdCBtZSBkaXJlY3RseSBpZiB5b3UgaGF2ZSBhbnkg cXVlc3Rpb25zLg0KDQpSZWdhcmRzLA0KLS1EYXZpZCBTb2xpbg0KLS0NCg0Kak9WQUwub3JnPGh0 dHA6Ly9qT1ZBTC5vcmc+OiBPVkFMIGltcGxlbWVudGVkIGluIEphdmEuDQpTY2FuIGFueSBtYWNo aW5lIGZyb20gYW55IG1hY2hpbmUuIEZvciBmcmVlIQ0KTGVhcm4gTW9yZTxodHRwOi8vd3d3Lmpv dmFsLm9yZy8+IHwgRmVhdHVyZXM8aHR0cDovL3d3dy5qb3ZhbC5vcmcvZmVhdHVyZXMvPiB8IERv d25sb2FkPGh0dHA6Ly93d3cuam92YWwub3JnL2Rvd25sb2FkLz4NCg0KT24gNC8yNy8yMDEyIDg6 NDggQU0sIHZ1bGlzdHMgd3JvdGU6DQoNCkhpIFRoZXJlLA0KDQoNCg0KSSdtIGxvb2tpbmcgZm9y IGEgd2F5IHRvIGFjY2VzcyBhIFZ1bG5lcmFiaWxpdHkgRGF0YWJhc2Ugd2l0aCBKYXZhLg0KDQoN Cg0KQXQgdGhlIG1vbWVudCBJJ20gbm90IDEwMCUgc3VyZSBpZiBpdHMgZ29ubmEgYmUgT3BlblZB UyBvciBzb21ldGhpbmcNCg0KZWxzZSwgbGlrZSBlLmcuIE9WQUwuDQoNCg0KDQpJIHdhbnRlZCB0 byBhc2ssIGlmIHNvbWVib2R5IGtub3dzIHNvbWUgcmVhZHktdG8tdXNlIEphdmEgQVBJIHRvIGFj Y2Vzcw0KDQoib25lIG9mIHRob3NlIiBWdWxuZXJhYmlsaXR5IERhdGFiYXNlcy4NCg0KDQoNCklm IHRoYXRzIG5vdCB0aGUgY2FzZSwgZG9lcyBpdCBtZWFuIEkgaGF2ZSB0byBpbXBsZW1lbnQgbXkg b3duIFhNTA0KDQpQYXJzZXIgdG8gZ2V0IHRoZSB2dWxuZXJhYmlsaXR5IGRhdGEgaW50byBteSBk YXRhYmFzZT8NCg0KDQoNCldoYXQgYWJvdXQgc3RhbmRhcmQgZm9ybWF0cz8NCg0KDQoNCg0KDQpU aGFua3MgYW5kIGtpbmQgcmVnYXJkcw0KDQoNCg0KVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1h aWwgbWVzc2FnZSB0byBMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOkxJU1RTRVJWQExJ U1RTLk1JVFJFLk9SRz4gd2l0aA0KDQpTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1QNCg0KaW4g dGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuICBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRl IHRvIE9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOk9W QUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc+Lg0KDQpUbyB1bnN1YnNj cmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdlIHRvIExJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzxt YWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPiB3aXRoIFNJR05PRkYgT1ZBTC1ERVZFTE9Q RVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUgbWVzc2FnZS4gSWYgeW91IGhhdmUgZGlmZmljdWx0 aWVzLCB3cml0ZSB0byBPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JH PG1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPi4NCg0K VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byBMSVNUU0VSVkBMSVNUUy5N SVRSRS5PUkc8bWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRz4gd2l0aCBTSUdOT0ZGIE9W QUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZl IGRpZmZpY3VsdGllcywgd3JpdGUgdG8gT1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RT Lk1JVFJFLk9SRzxtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJF Lk9SRz4uDQoNCi0tDQoNCmpPVkFMLm9yZzogT1ZBTCBpbXBsZW1lbnRlZCBpbiBKYXZhLg0KU2Nh biBhbnkgbWFjaGluZSBmcm9tIGFueSBtYWNoaW5lLiBGb3IgZnJlZSENCkxlYXJuIE1vcmU8aHR0 cDovL3d3dy5qb3ZhbC5vcmc+IHwgRmVhdHVyZXM8aHR0cDovL3d3dy5qb3ZhbC5vcmcvZmVhdHVy ZXMvPiB8IERvd25sb2FkPGh0dHA6Ly93d3cuam92YWwub3JnL2Rvd25sb2FkLz4NClRvIHVuc3Vi c2NyaWJlLCBzZW5kIGFuIGVtYWlsIG1lc3NhZ2UgdG8gTElTVFNFUlZATElTVFMuTUlUUkUuT1JH PG1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc+IHdpdGggU0lHTk9GRiBPVkFMLURFVkVM T1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1 bHRpZXMsIHdyaXRlIHRvIE9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5P Ukc8bWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc+Lg0K VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byBMSVNUU0VSVkBMSVNUUy5N SVRSRS5PUkc8bWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRz4gd2l0aCBTSUdOT0ZGIE9W QUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZl IGRpZmZpY3VsdGllcywgd3JpdGUgdG8gT1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RT Lk1JVFJFLk9SRzxtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJF Lk9SRz4uDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdlIHRvIExJU1RTRVJW QExJU1RTLk1JVFJFLk9SRzxtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPiB3aXRoIFNJ R05PRkYgT1ZBTC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUgbWVzc2FnZS4gSWYg eW91IGhhdmUgZGlmZmljdWx0aWVzLCB3cml0ZSB0byBPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVl c3RATElTVFMuTUlUUkUuT1JHPG1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElT VFMuTUlUUkUuT1JHPi4NCg== --_000_D7A0423E5E193F40BE6E94126930C4930B981E80A5MBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KdHQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29B Y2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE2NjU5MzcwMjQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyNDQwNjQwMzIgNjc2OTg3MDUgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkg bGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXY+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD4NCk5vbmUgdGhhdCBJIGFtIGF3YXJlIG9mLiAgVGhpcyB3b3JrIHdp bGwgYmUgcmVsZWFzZWQgaW4gdGhlIHB1YmxpYyBkb21haW4uPGJyPkRhdmU8L2ZvbnQ+PC9kaXY+ DQo8YnI+PGRpdj48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9 LTE+DQo8Zm9udCBmYWNlPVRhaG9tYSBzaXplPTI+DQo8Yj5Gcm9tPC9iPjogTWljaGFlbCBIYW1t ZXIgJmx0O21pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20mZ3Q7DTxicj48Yj5UbzwvYj46IFdh bHRlcm1pcmUsIERhdmlkIEEuOyBPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRyAm bHQ7T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkcmZ3Q7OyBzYWNtQGlldGYub3Jn ICZsdDtzYWNtQGlldGYub3JnJmd0Ow08YnI+PGI+U2VudDwvYj46IFdlZCBNYXkgMDIgMTk6MzQ6 MjAgMjAxMjxicj48Yj5TdWJqZWN0PC9iPjogUkU6IFtzYWNtXSBbT1ZBTC1ERVZFTE9QRVItTElT VF0gQWNjZXNzIFZ1bG5lcmFiaWxpdHkgRGF0YWJhc2Ugd2l0aAlKYXZhDTxicj48L2ZvbnQ+PGJy PjwvZGl2Pg0KPGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+RGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JcyB0aGVyZSBhbnkg SVBSIGFzc29jaWF0ZWQgd2l0aCB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IE1pa2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPldhbHRlcm1pcmUsIERhdmlkIEEuPGJyPjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIE1heSAwMiwgMjAxMiA1OjM0IFBNPGJyPjxiPlRvOjwvYj4gT1ZB TCBEZXZlbG9wZXIgTGlzdCAoQ2xvc2VkIFB1YmxpYyBEaXNjdXNzaW9uKTsgc2FjbUBpZXRmLm9y Zzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBbT1ZBTC1ERVZFTE9QRVItTElTVF0gQWNj ZXNzIFZ1bG5lcmFiaWxpdHkgRGF0YWJhc2Ugd2l0aCBKYXZhPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XaXRoIHNvbWUgb2YgdGhlIGN1 cnJlbnQgZW1haWwgZGlzY3Vzc2lvbiwgSSYjODIxNztkIGxpa2UgdG8gcHJvdmlkZSBhIGJyaWVm IHVwZGF0ZSBvbiBzb21lIHByb2plY3RzIG15IHRlYW0gaGFzIGJlZW4gd29ya2luZyBvbiBpbiB0 aGlzIGFyZWEuJm5ic3A7IFdlIGFyZSBjdXJyZW50bHkgd29ya2luZyBvbiB0aGUgZm9sbG93aW5n IGFjdGl2aXRpZXM6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MSk8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByb3RvdHlwaW5nIGEg ZmVkZXJhdGVkLCBnZW5lcmFsaXplZCBYTUwtYmFzZWQgY29udGVudCByZXBvc2l0b3J5IGFwcHJv YWNoLiZuYnNwOyBUaGUgY3VycmVudCBlZmZvcnQgaXMgdXNpbmcgYSBtZXRhbW9kZWwgdG8gZGVz Y3JpYmUgdGhlIGtleSBvYmplY3RzIChjYWxsZWQgJiM4MjIwO2VudGl0aWVzJiM4MjIxOykgaW4g YW4gWE1MIG1vZGVsIGFuZCB0aGUgY29udGVudCByZWZlcmVuY2VzIChjYWxsZWQgJiM4MjIwO3Jl bGF0aW9uc2hpcHMmIzgyMjE7KSB0aGF0IGV4aXN0IHdpdGhpbiBhbiBYTUwgZG9jdW1lbnQuJm5i c3A7IFdlIGhhdmUgZGV2ZWxvcGVkIGEgc2hyZWRkZXIgdGhhdCByZWFkcyBpbiBhbiBYTUwgaW5z dGFuY2UsIGJyZWFraW5nIGRvd24gdGhlIGVudGl0aWVzIGFuZCByZWxhdGlvbnNoaXBzLiZuYnNw OyBJdCB0aGVuIHBlcnNpc3RzIHRoZSBYTUwgY2h1bmtzIGluIGFuIFhNTCBkYXRhYmFzZSBhbmQg dGhlIGVudGl0eSBhbmQgcmVsYXRpb25zaGlwIGluZm9ybWF0aW9uIGluIGEgbm9uLXJlbGF0aW9u YWwgUkRGIGRhdGFiYXNlLiZuYnNwOyBXZSBjYW4gYWxzbyByZXF1ZXN0IHRoZSBjb250ZW50IGJh Y2sgb3V0IG9mIHRoZSBkYXRhc3RvcmUgYW5kIHJlY29uc3RpdHV0ZSBpdC4mbmJzcDsgVGhlIGFw cHJvYWNoIHdlIGFyZSB1c2luZyBkb2VzIG5vdCBwZXJ0dXJiIHRoZSB1bmRlcmx5aW5nIFhNTCBp bmZvc2V0LCBzbyBzaWduYXR1cmVzIGNhbiBiZSB2ZXJpZmllZCBmb3IgY29udGVudCByZXRyaWV2 ZWQgb3V0IG9mIHRoZSByZXBvc2l0b3J5LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+V2UgYXJlIGN1cnJlbnRseSB3b3JraW5nIG9uIHdlYiBzZXJ2aWNlIChTT0FQIGFuZCBSRVNU KSBpbnRlcmZhY2VzIGFuZCBhIGdlbmVyYWxpemVkIHF1ZXJ5IGxhbmd1YWdlLiZuYnNwOyBPdXIg Y3VycmVudCBkZXZlbG9wbWVudCBwaGFzZSB3aWxsIGVuZCBpbiB0aGUgbmV4dCBjb3VwbGUgbW9u dGhzLiZuYnNwOyBXZSBob3BlIHRvIGhhdmUgYSBkb3dubG9hZGFibGUgZGVtbyBhdmFpbGFibGUg YmVmb3JlIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXMgaW4gZWFybHkgSnVseSB0 aGF0IHdpbGwgc3VwcG9ydCByZXF1ZXN0aW5nIGFuIFNDQVAgZGF0YXN0cmVhbSBvciBhIGNvbGxl Y3Rpb24gb2YgT1ZBTC9PQ0lMIGRlZmluaXRpb25zIChhbmQgcmVsYXRlZCBjb21wb25lbnRzKSBi eSBpZGVudGlmaWVyIGFuZCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5XZSBhcmUgYXZvaWRpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9ibGVtIGJ5IGV4dHJhY3Rpbmcg YSBETlMgbmFtZSBvdXQgb2YgdGhlIGNvbnRlbnQgaWRlbnRpZmllci4mbmJzcDsgPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFw aD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkZvciBleGFtcGxlIHRoZSBjb250ZW50IHJlZmVyZW5j ZWQgYnk6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5vdmFsOm9yZy5taXRyZS5v dmFsOmRlZjoxPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNhbiBiZSByZXRyaWV2 ZWQgYnkgdGhlIGNvbnRlbnQgc2VydmVyICYjODIyMDtvdmFsLm1pdHJlLm9yZyYjODIyMTsuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBwbGFuIGlzIHRvIHVzZSB0aGlzIHRv IGxvb2t1cCBhIEROUyBTUlYgcmVjb3JkICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Jm Yy9yZmMyNzgyLnR4dCI+UkZDIDI3ODI8L2E+KSB0byBsb2NhdGUgdGhlIHJlcG9zaXRvcnkgdGhh dCBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGNvbnRlbnQgaWRlbnRpZmllZC4mbmJzcDsgVGhpcyBj YW4gYmUgdXNlZCB0byBkeW5hbWljYWxseSByZXRyaWV2ZSB0aGUgcmVmZXJlbmNlZCBjb250ZW50 LiZuYnNwOyBXZSBhcmUganVzdCBzdGFydGluZyB0byB3b3JrIG91dCBhbiBYTUwgZm9ybWF0IGZv ciByZXBvc2l0b3J5LXRvLXJlcG9zaXRvcnkgaW5mb3JtYXRpb24gZXhjaGFuZ2UgdG8gZW5hYmxl IHRoaXMgY29tbXVuaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXQg dGhpcyBwb2ludCBvdXIgY3VycmVudCByZXBvc2l0b3J5IGNvZGUgaXMgbm90IGZhciBmcm9tIHJl cGxhY2luZyB0aGUgZGF0YSBiYWNrZW5kIHRoYXQgaXMgdXNlZCBmb3IgdGhlIE9WQUwgcmVwb3Np dG9yeS4mbmJzcDsgVGhlIGNvb2wgdGhpbmcgYWJvdXQgdGhlIG92ZXJhbGwgYXBwcm9hY2ggaXMg dGhhdCBubyBPVkFMIHNwZWNpZmljIGNvZGUgaXMgbmVjZXNzYXJ5LiZuYnNwOyBXZSBoYXZlIGNy ZWF0ZWQgWE1MLWJhc2VkIHNocmVkZGluZyBydWxlcyBmb3IgU0NBUCBkYXRhc3RyZWFtLCBPVkFM IDUuMTAuMSBhbmQgWENDREYgMS4yIGZvcm1hdHMuICZuYnNwO0l0IGlzIGZhaXJseSB0cml2aWFs IHRvIGNyZWF0ZSBuZXcgc2hyZWRkaW5nIHJ1bGVzIGZvciBhZGRpdGlvbmFsIG1vZGVscy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+WW91IGNhbiByZXZpZXcgdGhlIGNvZGUgYXQ6 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vY29kZS5n b29nbGUuY29tL3Avc2VjdXJpdHktYXV0b21hdGlvbi1jb250ZW50LXJlcG9zaXRvcnkvIj5odHRw Oi8vY29kZS5nb29nbGUuY29tL3Avc2VjdXJpdHktYXV0b21hdGlvbi1jb250ZW50LXJlcG9zaXRv cnkvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Nb3N0IG9mIG91ciB3b3Jr IGlzIGJlaW5nIGRvbmUgaW4gdGhlIFNWTiBicmFuY2g6PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9zZWN1cml0eS1hdXRvbWF0aW9uLWNvbnRlbnQtcmVw b3NpdG9yeS5nb29nbGVjb2RlLmNvbS9zdm4vYnJhbmNoZXMvbmV3LXNocmVkZGVyIj5odHRwOi8v c2VjdXJpdHktYXV0b21hdGlvbi1jb250ZW50LXJlcG9zaXRvcnkuZ29vZ2xlY29kZS5jb20vc3Zu L2JyYW5jaGVzL25ldy1zaHJlZGRlcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+VGhlIGRvY3VtZW50YXRpb24gaXMgdmVyeSBzcGFyc2UgYW5kIHRoZSBjb2RlIG5lZWRzIHNv bWUgY2xlYW51cC4mbmJzcDsgV2UgcGxhbiB0byB3b3JrIG9uIHRoaXMgaW4gdGhlIG5lYXIgZnV0 dXJlLiZuYnNwOyBPdXIgbG9uZy10ZXJtIGdvYWwgaXMgdG8gcHJvdmlkZSBhIGZyZWVseSBhdmFp bGFibGUsIHByb2R1Y3Rpb24gY2FwYWJsZSBjb250ZW50IHJlcG9zaXRvcnkgc2VydmVyIHRoYXQg Y2FuIHBhcnRpY2lwYXRlIGluIGEgZmVkZXJhdGVkIG5ldHdvcmsgb2YgY29udGVudCBzZXJ2ZXJz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBz dHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yKTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgaGF2ZSBhbHNvIGJlZW4g d29ya2luZyBvbiBhIGNvbnRlbnQgcmVwb3NpdG9yeSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBUaGUg Z29hbCBmb3IgdGhpcyBkb2N1bWVudCBpcyB0byBkZXNjcmliZSB0aGUgb3ZlcmFsbCBmZWRlcmF0 aW9uIGFwcHJvYWNoIGFuZCB0byBkZXRhaWwgdGhlIGRhdGEgZXhjaGFuZ2UgbW9kZWxzLCBpbnRl cmZhY2VzIGFuZCB0cmFuc3BvcnRzIG5lZWRlZCB0byBzdXBwb3J0IGludGVyb3BlcmFiaWxpdHku Jm5ic3A7IEkgcGxhbiB0byBoYXZlIGEgZHJhZnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHJlYWR5 IGluIFNlcHRlbWJlci4mbmJzcDsgSSB3b3VsZCBiZSBoYXBweSB0byBzdWJtaXQgdGhpcyBhcyBh biBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gdG8gdGhlIElFVEYgd2hlbiBpdCBpcyBtb3JlIGNvbXBs ZXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TXkgaG9wZSBpcyB0aGF0IHRoaXMgd29yayB3aWxsIGFk ZHJlc3MgbWFueSBvZiB0aGUgY29tbXVuaXRpZXMgY2hhbGxlbmdlcyBpbiB0aGlzIGFyZWEuJm5i c3A7IEkmIzgyMTc7ZCBhcHByZWNpYXRlIGFueSB0aG91Z2h0cyBvciBmZWVkYmFjayBvbiB0aGlz IG92ZXJhbGwgYXBwcm9hY2guJm5ic3A7IFBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBh bnkgcXVlc3Rpb25zLiZuYnNwOyBJIGhhdmUgYWxzbyByZXF1ZXN0ZWQgYSBzZXNzaW9uIGF0IHRo ZSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlzIGhvc3RlZCBieSBNSVRSRSBpbiBl YXJseSBKdWx5IHRvIHJldmlldyBhbmQgZGlzY3VzcyB0aGlzIHdvcmsgaW4gZ3JlYXRlciBkZXRh aWwuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGF2ZSBXYWx0ZXJt aXJlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz4gS2VudCBMYW5kZmllbGQgPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86S2Vu dF9MYW5kZmllbGRATUNBRkVFLkNPTV0iPlttYWlsdG86S2VudF9MYW5kZmllbGRATUNBRkVFLkNP TV08L2E+IDxicj48Yj5TZW50OjwvYj4gU2F0dXJkYXksIEFwcmlsIDI4LCAyMDEyIDY6MTcgUE08 YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5N SVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPjxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBBY2Nlc3MgVnVsbmVyYWJpbGl0 eSBEYXRhYmFzZSB3aXRoIEphdmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjstKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkFzIHdhcyBwcm9wZXJseSBwb2ludGVk IG91dCB0byBtZSAmIzgyMzA7dGhlcmUgd2FzIGEgdHlwbyBpbiBteSBtZXNzYWdlJiM4MjMwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZxdW90O1RoaXMg aXMgb25lIG9mIHRoZSB0b3BpY3MgSSB3b3VsZCBsaWtlIHRvIHNlZSBkZXZlbG9wZWQgb24gdGhl IFNDQU0gbGlzdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5TaG91bGQgaGF2ZSBiZWVuJiM4MjMwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPlRoaXMgaXMgb25lIG9mIHRoZSB0b3BpY3MgSSB3b3VsZCBs aWtlIHRvIHNlZSBkZXZlbG9wZWQgb24gdGhlIDxiPlNBQ008L2I+IGxpc3QuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Oy0pPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPktlbnQgTGFuZGZpZWxkPC9zcGFu Pjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxl LXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJlIGFuZCBTdGFuZGFy ZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwvc3Bhbj48L3N0cm9uZz48 YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41MDAwIEhlYWRxdWFydGVycyBEci48L3Nw YW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+UGxhbm8sIFRleGFzIDc1MDI0PC9z cGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3Q6ICsxLjk3Mi45 NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5Nb2Jp bGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8L3NwYW4+PC9zdHJvbmc+PHNw YW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3Lm1jYWZlZS5jb20v Ij53d3cubWNhZmVlLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29O b3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz4mbHQ7TGFuZGZpZWxkJmd0OywgS2VudCBMYW5kZmllbGQgJmx0OzxhIGhyZWY9 Im1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tIj5LZW50X0xhbmRmaWVsZEBNY0FmZWUu Y29tPC9hPiZndDs8YnI+PGI+UmVwbHktVG86IDwvYj4mcXVvdDtPVkFMIERldmVsb3BlciBMaXN0 IChDbG9zZWQgUHVibGljIERpc2N1c3Npb24pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86T1ZB TC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElT VFMuTUlUUkUuT1JHPC9hPiZndDs8YnI+PGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RA TElTVFMuTUlUUkUuT1JHPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxP UEVSLUxJU1RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJF Lk9SRzwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6IDwvYj5SZTogW09WQUwtREVWRUxPUEVSLUxJU1Rd IEFjY2VzcyBWdWxuZXJhYmlsaXR5IERhdGFiYXNlIHdpdGggSmF2YTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9O X0JMT0NLUVVPVEUiPjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBhdCB0aGUg bGFzdCB0d28gSVRTQUMgY29uZmVyZW5jZSBhbmQgdGhlIFdpbnRlciBEZXZlbG9wZXIgRGF5cyBs YXN0IHllYXIuICZuYnNwO0Rpc2N1c3Npb25zIGhhdmUgYmVlbiBoYWQgYXJvdW5kIHRoZSBuZWVk cyBvbiB0aGUgU0FDTSBsaXN0IGFzIHdlbGwuICZuYnNwOyBUaGlzIGlzIGFuIGVmZm9ydCB0byBn ZXQgYSBzdGFuZGFyZCBtZWFucyBmb3IgZGlzdHJpYnV0aW5nIFNDQVAgcmVsYXRlZCBjb250ZW50 IHdpdGhpbiBhbiBvcmdhbml6YXRpb24gYW5kIGFzIGEgcG90ZW50aWFsbHkgZmVkZXJhdGVkIG1l YW5zIG9mIG1hbmFnaW5nIGNvbnRlbnQgZGV2ZWxvcGVkIGJ5IGd1aWRhbmNlIGF1dGhvcnMgc3Vj aCBhcyBDSVMsIE5JU1QsIG90aGVyIGdvdmVybm1lbnQgZW50aXRpZXMgYW5kIGluZHVzdHJ5IHZl cnRpY2Fscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5D b3VwbGUgbGlua3MgdG8gcGFzdCBwcmVzZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxhIGhyZWY9Imh0dHA6Ly93d3cuZ29vZ2xlLmNvbS91 cmw/c2E9dCZhbXA7cmN0PWomYW1wO3E9JmFtcDtlc3JjPXMmYW1wO3NvdXJjZT13ZWImYW1wO2Nk PTImYW1wO3ZlZD0wQ0RBUUZqQUImYW1wO3VybD1odHRwJTNBJTJGJTJGc2NhcC5uaXN0LmdvdiUy RmV2ZW50cyUyRjIwMTElMkZzYWRkc3AlMkZwcmVzZW50YXRpb25zJTJGS2VudF9MYW5kZmllbGQt QXV0b21hdGlvbl9Db250ZW50X1JlcG9zaXRvcmllcy5wZGYmYW1wO2VpPW5sT2NULVA3TDhhV2lB S0dvNkdUQVEmYW1wO3VzZz1BRlFqQ05IdlRORXp0VlFtWmhraXNMa2RjQjU4RXBTOFN3JmFtcDtz aWcyPUhZNUpqRU56YzR3TWUydFZjNGluQUEiPmh0dHA6Ly93d3cuZ29vZ2xlLmNvbS91cmw/c2E9 dCZhbXA7cmN0PWomYW1wO3E9JmFtcDtlc3JjPXMmYW1wO3NvdXJjZT13ZWImYW1wO2NkPTImYW1w O3ZlZD0wQ0RBUUZqQUImYW1wO3VybD1odHRwJTNBJTJGJTJGc2NhcC5uaXN0LmdvdiUyRmV2ZW50 cyUyRjIwMTElMkZzYWRkc3AlMkZwcmVzZW50YXRpb25zJTJGS2VudF9MYW5kZmllbGQtQXV0b21h dGlvbl9Db250ZW50X1JlcG9zaXRvcmllcy5wZGYmYW1wO2VpPW5sT2NULVA3TDhhV2lBS0dvNkdU QVEmYW1wO3VzZz1BRlFqQ05IdlRORXp0VlFtWmhraXNMa2RjQjU4RXBTOFN3JmFtcDtzaWcyPUhZ NUpqRU56YzR3TWUydFZjNGluQUE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGNsYXNz PWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8v c2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9zYWRkc3AvcHJlc2VudGF0aW9ucy9TZWN1cml0eV9B dXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yeV9EZW1vLnBkZiI+aHR0cDovL3NjYXAubmlzdC5n b3YvZXZlbnRzLzIwMTEvc2FkZHNwL3ByZXNlbnRhdGlvbnMvU2VjdXJpdHlfQXV0b21hdGlvbl9D b250ZW50X1JlcG9zaXRvcnlfRGVtby5wZGY8L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxhIGhyZWY9Imh0dHA6Ly9zY2FwLm5pc3QuZ292L2V2ZW50cy8yMDExL2l0c2FjL3ByZXNl bnRhdGlvbnMvZGF5My9MYW5kZmllbGQsJTIwQ2hlcm5pbiwlMjBCYXNhdmFubmElMjAtJTIwQ29u dGVudCUyMFJlcG9zaXRvcmllcy5wZGYiPmh0dHA6Ly9zY2FwLm5pc3QuZ292L2V2ZW50cy8yMDEx L2l0c2FjL3ByZXNlbnRhdGlvbnMvZGF5My9MYW5kZmllbGQsJTIwQ2hlcm5pbiwlMjBCYXNhdmFu bmElMjAtJTIwQ29udGVudCUyMFJlcG9zaXRvcmllcy5wZGY8L2E+Jm5ic3A7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhlcmUgd2FzIGFsc28g YSBwcmVzZW50YXRpb24gdGhhdCBBZGFtIE1vbnR2aWxsZSBwcmVwYXJlZCBmb3IgdGhlIElFVEYg U0FDTSBTaWRlIG1lZXRpbmcuIFRoZXkgYXJlIGF2YWlsYWJsZSBpbiB0aGUgemlwIGZpbGUgb2Yg dGhlIHByZXNlbnRhdGlvbnMgbG9jYXRlZCBpbiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz1hcHBs ZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2NvbG9yOmJsYWNrJz48 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2FjbS9jdXJyZW50 L21zZzAwMTc4Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zYWNt L2N1cnJlbnQvbXNnMDAxNzguaHRtbDwvYT4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+VGhpcyBpcyBvbmUgb2YgdGhlIHRvcGljcyBJIHdvdWxkIGxpa2UgdG8gc2VlIGRldmVs b3BlZCBvbiB0aGUgU0NBTSBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJvbmc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojNjA2QTcxJz5LZW50IExhbmRmaWVsZDwvc3Bhbj48L3N0cm9uZz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiM2MDZBNzEnPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPkRpcmVjdG9yIENv bnRlbnQgU3RyYXRlZ3ksIEFyY2hpdGVjdHVyZSBhbmQgU3RhbmRhcmRzPC9zcGFuPjxicj48YnI+ PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPk1j QWZlZSB8IEFuIEludGVsIENvbXBhbnk8L3NwYW4+PC9zdHJvbmc+PGJyPjxzcGFuIGNsYXNzPWFw cGxlLXN0eWxlLXNwYW4+NTAwMCBIZWFkcXVhcnRlcnMgRHIuPC9zcGFuPjxicj48c3BhbiBjbGFz cz1hcHBsZS1zdHlsZS1zcGFuPlBsYW5vLCBUZXhhcyA3NTAyNDwvc3Bhbj48YnI+PGJyPjxzcGFu IGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0OiArMS45NzIuOTYzLjcwOTYmbmJzcDs8L3Nw YW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+TW9iaWxlOiArMS44MTcuNjM3Ljgw MjY8L3NwYW4+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz5XZWI6Jm5ic3A7PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPWFwcGxlLXN0 eWxlLXNwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5tY2FmZWUuY29tLyI+d3d3Lm1jYWZlZS5jb208 L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RGF2aWQg U29saW4gJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZEBKT1ZBTC5PUkciPmRhdmlkQEpPVkFMLk9S RzwvYT4mZ3Q7PGJyPjxiPlJlcGx5LVRvOiA8L2I+JnF1b3Q7T1ZBTCBEZXZlbG9wZXIgTGlzdCAo Q2xvc2VkIFB1YmxpYyBEaXNjdXNzaW9uKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9WQUwt REVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNUQExJU1RT Lk1JVFJFLk9SRzwvYT4mZ3Q7PGJyPjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOk9W QUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNUQExJ U1RTLk1JVFJFLk9SRzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BF Ui1MSVNUQExJU1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5P Ukc8L2E+Jmd0Ozxicj48Yj5TdWJqZWN0OiA8L2I+UmU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBB Y2Nlc3MgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3aXRoIEphdmE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+V2UnZCBjZXJ0YWlubHkgYmUgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgYW55 IHN1Y2ggc3RhbmRhcmQuJm5ic3A7IENhbiB5b3UgcG9pbnQgbWUgdG8gd2hvJ3MgYWN0aXZlbHkg ZGlzY3Vzc2luZyBpdD8mbmJzcDsgRG9lcyBNSVRSRSBpbnRlbmQgdG8gc3VwcG9ydCBhbnkgc3Rh bmRhcmQgYXBwcm9hY2hlcyB0byByZXBvc2l0b3J5IGFjY2Vzcz88YnI+PGJyPlJlZ2FyZHMsPGJy Pi0tRGF2aWQ8YnI+PGJyPk9uIDQvMjgvMjAxMiA2OjU2IEFNLCBMdWlzIE51bmV6IHdyb3RlOiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+WW91IGtub3cgdGhlcmUgaXMgdGFsayBvZiBwcm9kdWNpbmcgYSBzdGFuZGFyZCBz cGVjIChzYWNtKSB0byBkbyBzb21ldGhpbmcgbGlrZSB0aGlzLiAmbmJzcDtJIGtub3cgd2UgYXJl IGJ1c3kgYnV0IHNvbWV0aGluZyB0byB0aGluayBhYm91dC4gPG86cD48L286cD48L3NwYW4+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+SXQgd291bGQgYmUgY29vbCB0byBqb3ZhbCBiZSBhYmxlIHRv IGRpcmVjdGx5IHF1ZXJ5IGFuZCBwdWxsIGRvd24gY29udGVudCBkaXJlY3RseSBmcm9tIFNlY1Bv ZCBhbmQgb3RoZXIgcmVwb3NpdG9yaWVzIGluIGEgY29tbW9uIHdheS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4tbG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+T24gQXByIDI3LCAyMDEyLCBhdCA1OjM5IFBNLCBEYXZpZCBT b2xpbiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmpPVkFMIHBy b3ZpZGVzIGEgcmVhZHktdG8tdXNlIEpBWEIgZGF0YSBtb2RlbCBmb3IgdGhlIE9WQUwgbGFuZ3Vh Z2UsIHZhcmlvdXMgdXRpbGl0eSBjbGFzc2VzLCBhbmQgb2YgY291cnNlLCBhbiBldmFsdWF0aW9u IGVuZ2luZSBhbmQgc2NhbiBwbHVnLWlucy4mbmJzcDsgSXQgZG9lcyBub3QsIGhvd2V2ZXIsIGlt cGxlbWVudCBhY2Nlc3MgdG8gYW55IG9uLWxpbmUgcmVwb3NpdG9yaWVzLjxicj48YnI+RmVlbCBm cmVlIHRvIGNvbnRhY3QgbWUgZGlyZWN0bHkgaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucy48YnI+ PGJyPlJlZ2FyZHMsPGJyPi0tRGF2aWQgU29saW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4tLSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgc3R5bGU9J2xpbmUtaGVpZ2h0OjEyLjBwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMz MzMzMyc+PGEgaHJlZj0iaHR0cDovL2pPVkFMLm9yZyI+ak9WQUwub3JnPC9hPjogT1ZBTCBpbXBs ZW1lbnRlZCBpbiBKYXZhLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxicj48L3NwYW4+PGk+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojMzMzMzMzJz5TY2FuIGFueSBtYWNoaW5lIGZyb20gYW55IG1hY2hpbmUuIEZv ciBmcmVlITwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PGEgaHJlZj0iaHR0cDov L3d3dy5qb3ZhbC5vcmcvIj48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjYwMCc+TGVhcm4gTW9yZTwv c3Bhbj48L2E+IHwgPGEgaHJlZj0iaHR0cDovL3d3dy5qb3ZhbC5vcmcvZmVhdHVyZXMvIj48c3Bh biBzdHlsZT0nY29sb3I6IzMzNjYwMCc+RmVhdHVyZXM8L3NwYW4+PC9hPiB8IDxhIGhyZWY9Imh0 dHA6Ly93d3cuam92YWwub3JnL2Rvd25sb2FkLyI+PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzY2MDAn PkRvd25sb2FkPC9zcGFuPjwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj5PbiA0LzI3LzIwMTIgODo0 OCBBTSwgdnVsaXN0cyB3cm90ZTogPG86cD48L286cD48L3NwYW4+PC9wPjxwcmU+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5IaSBUaGVyZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+PHBy ZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkknbSBsb29raW5nIGZvciBhIHdheSB0byBhY2Nl c3MgYSBWdWxuZXJhYmlsaXR5IERhdGFiYXNlIHdpdGggSmF2YS48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkF0IHRoZSBtb21lbnQgSSdt IG5vdCAxMDAlIHN1cmUgaWYgaXRzIGdvbm5hIGJlIE9wZW5WQVMgb3Igc29tZXRoaW5nPG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmVsc2UsIGxp a2UgZS5nLiBPVkFMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+SSB3YW50ZWQgdG8gYXNrLCBpZiBzb21lYm9keSBrbm93cyBzb21lIHJl YWR5LXRvLXVzZSBKYXZhIEFQSSB0byBhY2Nlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJl PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+JnF1b3Q7b25lIG9mIHRob3NlJnF1b3Q7IFZ1bG5l cmFiaWxpdHkgRGF0YWJhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+SWYgdGhhdHMgbm90IHRoZSBjYXNlLCBkb2VzIGl0IG1lYW4g SSBoYXZlIHRvIGltcGxlbWVudCBteSBvd24gWE1MPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlBhcnNlciB0byBnZXQgdGhlIHZ1bG5lcmFiaWxp dHkgZGF0YSBpbnRvIG15IGRhdGFiYXNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT48cHJl PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+V2hhdCBhYm91dCBzdGFuZGFyZCBmb3JtYXRzPzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPlRoYW5rcyBhbmQga2luZCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFp bCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkciPkxJ U1RTRVJWQExJU1RTLk1JVFJFLk9SRzwvYT4gd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+aW4g dGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuJm5ic3A7IElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywg d3JpdGUgdG8gPGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNU Uy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8 L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbyB1bnN1YnNjcmliZSwgc2Vu ZCBhbiBlbWFpbCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRS RS5PUkciPkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzwvYT4gd2l0aCBTSUdOT0ZGIE9WQUwtREVW RUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZp Y3VsdGllcywgd3JpdGUgdG8gPGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVx dWVzdEBMSVNUUy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5N SVRSRS5PUkc8L2E+LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPlRvIHVuc3Vic2NyaWJlLCBzZW5kIGFuIGVtYWlsIG1lc3NhZ2UgdG8gPGEgaHJlZj0i bWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRyI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JH PC9hPiB3aXRoIFNJR05PRkYgT1ZBTC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUg bWVzc2FnZS4gSWYgeW91IGhhdmUgZGlmZmljdWx0aWVzLCB3cml0ZSB0byA8YSBocmVmPSJtYWls dG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZF TE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRzwvYT4uIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPi0tIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBzdHlsZT0nbGluZS1oZWlnaHQ6MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMz MzMzJz5qT1ZBTC5vcmc6IE9WQUwgaW1wbGVtZW50ZWQgaW4gSmF2YS48L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojMzMzMzMzJz48YnI+PC9zcGFuPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+U2NhbiBhbnkgbWFj aGluZSBmcm9tIGFueSBtYWNoaW5lLiBGb3IgZnJlZSE8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSdm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMz MzMzMyc+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuam92YWwub3JnIj48c3BhbiBzdHlsZT0nY29s b3I6IzMzNjYwMCc+TGVhcm4gTW9yZTwvc3Bhbj48L2E+IHwgPGEgaHJlZj0iaHR0cDovL3d3dy5q b3ZhbC5vcmcvZmVhdHVyZXMvIj48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjYwMCc+RmVhdHVyZXM8 L3NwYW4+PC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly93d3cuam92YWwub3JnL2Rvd25sb2FkLyI+PHNw YW4gc3R5bGU9J2NvbG9yOiMzMzY2MDAnPkRvd25sb2FkPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byA8YSBocmVmPSJtYWls dG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHIj5MSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc8L2E+ IHdpdGggU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRoZSBtZXNz YWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIDxhIGhyZWY9Im1haWx0bzpP VkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BF Ui1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9hPi4gPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5UbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdlIHRvIDxh IGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkciPkxJU1RTRVJWQExJU1RTLk1J VFJFLk9SRzwvYT4gd2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkg b2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUgdG8gPGEgaHJl Zj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkciPk9W QUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8L2E+LiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxwIGNsYXNzPU1zb05vcm1hbD5U byB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpM SVNUU0VSVkBMSVNUUy5NSVRSRS5PUkciPkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzwvYT4gd2l0 aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2Uu IElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUgdG8gPGEgaHJlZj0ibWFpbHRvOk9WQUwt REVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJ U1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8L2E+LiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930B981E80A5MBCLUSTERxcha_-- From david.waltermire@nist.gov Thu May 3 06:35: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 8EFCA21F8495 for ; Thu, 3 May 2012 06:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.058 X-Spam-Level: X-Spam-Status: No, score=-5.058 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l07-0BdyofMS for ; Thu, 3 May 2012 06:35:41 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D37D021F85AC for ; Thu, 3 May 2012 06:35:40 -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.355.2; Thu, 3 May 2012 09:35:32 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 3 May 2012 09:35:09 -0400 From: "Waltermire, David A." To: David Solin , "sacm@ietf.org" Date: Thu, 3 May 2012 09:35:09 -0400 Thread-Topic: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Thread-Index: Ac0ovzPJkFCzt426Sk6aGaYBW/MxmQAY5b4w Message-ID: References: <00C069FD01E0324C9FFCADF539701DB38A6DAD@EX2K10MB1.corp.yaanatech.com> <4FA1C9B2.3000101@joval.org> In-Reply-To: <4FA1C9B2.3000101@joval.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_D7A0423E5E193F40BE6E94126930C4930B98F8684EMBCLUSTERxcha_" MIME-Version: 1.0 Cc: "OVAL Developer List \(Closed Public Discussion\) \(OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG\)" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java 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, 03 May 2012 13:35:48 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B98F8684EMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Yes. We plan to provide a Java client resolver API and a command line utility similar to DNS. We will also be seeking comments on the service interfaces once we have some running code and documentation. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Solin Sent: Wednesday, May 02, 2012 7:57 PM To: sacm@ietf.org Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Hi David, Will this project include a reference client implementation? Will your team be seeking comments on the REST and SOAP interfaces? Regards, --David Solin On 5/2/2012 6:34 PM, Michael Hammer wrote: David, Is there any IPR associated with this? Mike From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, May 02, 2012 5:34 PM To: OVAL Developer List (Closed Public Discussion); sacm@ietf.org Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java With some of the current email discussion, I'd like to provide a brief update on some projects my team has been working on in this area. We are currently working on the following activities: 1) Prototyping a federated, generalized XML-based content repository approach. The current effort is using a metamodel to describe the key objects (called "entities") in an XML model and the content references (called "relationships") that exist within an XML document. We have developed a shredder that reads in an XML instance, breaking down the entities and relationships. It then persists the XML chunks in an XML database and the entity and relationship information in a non-relational RDF database. We can also request the content back out of the datastore and reconstitute it. The approach we are using does not perturb the underlying XML infoset, so signatures can be verified for content retrieved out of the repository. We are currently working on web service (SOAP and REST) interfaces and a generalized query language. Our current development phase will end in the next couple months. We hope to have a downloadable demo available before Security Automation Developer Days in early July that will support requesting an SCAP datastream or a collection of OVAL/OCIL definitions (and related components) by identifier and version. We are avoiding the registration problem by extracting a DNS name out of the content identifier. For example the content referenced by: oval:org.mitre.oval:def:1 Can be retrieved by the content server "oval.mitre.org". The plan is to use this to lookup a DNS SRV record (RFC 2782) to locate the repository that is responsible for the content identified. This can be used to dynamically retrieve the referenced content. We are just starting to work out an XML format for repository-to-repository information exchange to enable this communication. At this point our current repository code is not far from replacing the data backend that is used for the OVAL repository. The cool thing about the overall approach is that no OVAL specific code is necessary. We have created XML-based shredding rules for SCAP datastream, OVAL 5.10.1 and XCCDF 1.2 formats. It is fairly trivial to create new shredding rules for additional models. You can review the code at: http://code.google.com/p/security-automation-content-repository/ Most of our work is being done in the SVN branch: http://security-automation-content-repository.googlecode.com/svn/branches/new-shredder The documentation is very sparse and the code needs some cleanup. We plan to work on this in the near future. Our long-term goal is to provide a freely available, production capable content repository server that can participate in a federated network of content servers. 2) We have also been working on a content repository specification. The goal for this document is to describe the overall federation approach and to detail the data exchange models, interfaces and transports needed to support interoperability. I plan to have a draft of this specification ready in September. I would be happy to submit this as an individual submission to the IETF when it is more complete. My hope is that this work will address many of the communities challenges in this area. I'd appreciate any thoughts or feedback on this overall approach. Please let me know if you have any questions. I have also requested a session at the Security Automation Developer Days hosted by MITRE in early July to review and discuss this work in greater detail. Sincerely, Dave Waltermire From: Kent Landfield [mailto:Kent_Landfield@MCAFEE.COM] Sent: Saturday, April 28, 2012 6:17 PM To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java ;-) As was properly pointed out to me ...there was a typo in my message... "This is one of the topics I would like to see developed on the SCAM list." Should have been... This is one of the topics I would like to see developed on the SACM list. ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java This has been discussed at the last two ITSAC conference and the Winter Developer Days last year. Discussions have been had around the needs on the SACM list as well. This is an effort to get a standard means for distributing SCAP related content within an organization and as a potentially federated means of managing content developed by guidance authors such as CIS, NIST, other government entities and industry verticals. Couple links to past presentations. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDAQFjAB&url=http%3A%2F%2Fscap.nist.gov%2Fevents%2F2011%2Fsaddsp%2Fpresentations%2FKent_Landfield-Automation_Content_Repositories.pdf&ei=nlOcT-P7L8aWiAKGo6GTAQ&usg=AFQjCNHvTNEztVQmZhkisLkdcB58EpS8Sw&sig2=HY5JjENzc4wMe2tVc4inAA http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf http://scap.nist.gov/events/2011/itsac/presentations/day3/Landfield,%20Chernin,%20Basavanna%20-%20Content%20Repositories.pdf There was also a presentation that Adam Montville prepared for the IETF SACM Side meeting. They are available in the zip file of the presentations located in http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html This is one of the topics I would like to see developed on the SCAM list. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: David Solin > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java We'd certainly be interested in implementing any such standard. Can you point me to who's actively discussing it? Does MITRE intend to support any standard approaches to repository access? Regards, --David On 4/28/2012 6:56 AM, Luis Nunez wrote: You know there is talk of producing a standard spec (sacm) to do something like this. I know we are busy but something to think about. It would be cool to joval be able to directly query and pull down content directly from SecPod and other repositories in a common way. -ln On Apr 27, 2012, at 5:39 PM, David Solin wrote: jOVAL provides a ready-to-use JAXB data model for the OVAL language, various utility classes, and of course, an evaluation engine and scan plug-ins. It does not, however, implement access to any on-line repositories. Feel free to contact me directly if you have any questions. Regards, --David Solin -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download On 4/27/2012 8:48 AM, vulists wrote: Hi There, I'm looking for a way to access a Vulnerability Database with Java. At the moment I'm not 100% sure if its gonna be OpenVAS or something else, like e.g. OVAL. I wanted to ask, if somebody knows some ready-to-use Java API to access "one of those" Vulnerability Databases. If thats not the case, does it mean I have to implement my own XML Parser to get the vulnerability data into my database? What about standard formats? Thanks and kind regards To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download --_000_D7A0423E5E193F40BE6E94126930C4930B98F8684EMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxl LXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVt YWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjY1OTM3MDI0Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjQ0MDY0MDMyIDY3Njk4NzA1IDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFk Pjxib2R5IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxk aXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlllcy4mbmJzcDsgV2UgcGxhbiB0byBwcm92aWRlIGEgSmF2YSBjbGllbnQgcmVzb2x2 ZXIgQVBJIGFuZCBhIGNvbW1hbmQgbGluZSB1dGlsaXR5IHNpbWlsYXIgdG8gRE5TLiZuYnNwOyBX ZSB3aWxsIGFsc28gYmUgc2Vla2luZyBjb21tZW50cyBvbiB0aGUgc2VydmljZSBpbnRlcmZhY2Vz IG9uY2Ugd2UgaGF2ZSBzb21lIHJ1bm5pbmcgY29kZSBhbmQgZG9jdW1lbnRhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+U2luY2VyZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZlPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IHNhY20tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnNhY20tYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5EYXZpZCBTb2xpbjxi cj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMDIsIDIwMTIgNzo1NyBQTTxicj48Yj5Ubzo8 L2I+IHNhY21AaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbc2FjbV0gW09WQUwtREVW RUxPUEVSLUxJU1RdIEFjY2VzcyBWdWxuZXJhYmlsaXR5IERhdGFiYXNlIHdpdGggSmF2YTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkhpIERhdmlkLDxicj48YnI+V2lsbCB0aGlz IHByb2plY3QgaW5jbHVkZSBhIHJlZmVyZW5jZSBjbGllbnQgaW1wbGVtZW50YXRpb24/Jm5ic3A7 IFdpbGwgeW91ciB0ZWFtIGJlIHNlZWtpbmcgY29tbWVudHMgb24gdGhlIFJFU1QgYW5kIFNPQVAg aW50ZXJmYWNlcz88YnI+PGJyPlJlZ2FyZHMsPGJyPi0tRGF2aWQgU29saW48YnI+PGJyPk9uIDUv Mi8yMDEyIDY6MzQgUE0sIE1pY2hhZWwgSGFtbWVyIHdyb3RlOiA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZpZCw8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPklzIHRoZXJlIGFueSBJUFIgYXNzb2NpYXRlZCB3aXRoIHRoaXM/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5NaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5j ZXNAaWV0Zi5vcmciPnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpz YWNtLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8 Yj5PbiBCZWhhbGYgT2YgPC9iPldhbHRlcm1pcmUsIERhdmlkIEEuPGJyPjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIE1heSAwMiwgMjAxMiA1OjM0IFBNPGJyPjxiPlRvOjwvYj4gT1ZBTCBEZXZlbG9w ZXIgTGlzdCAoQ2xvc2VkIFB1YmxpYyBEaXNjdXNzaW9uKTsgPGEgaHJlZj0ibWFpbHRvOnNhY21A aWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhY21d IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBBY2Nlc3MgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3aXRo IEphdmE8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPldpdGggc29tZSBvZiB0aGUgY3VycmVudCBlbWFpbCBkaXNjdXNzaW9uLCBJJiM4MjE3 O2QgbGlrZSB0byBwcm92aWRlIGEgYnJpZWYgdXBkYXRlIG9uIHNvbWUgcHJvamVjdHMgbXkgdGVh bSBoYXMgYmVlbiB3b3JraW5nIG9uIGluIHRoaXMgYXJlYS4mbmJzcDsgV2UgYXJlIGN1cnJlbnRs eSB3b3JraW5nIG9uIHRoZSBmb2xsb3dpbmcgYWN0aXZpdGllczo8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MSk8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UHJvdG90eXBpbmcgYSBmZWRlcmF0ZWQs IGdlbmVyYWxpemVkIFhNTC1iYXNlZCBjb250ZW50IHJlcG9zaXRvcnkgYXBwcm9hY2guJm5ic3A7 IFRoZSBjdXJyZW50IGVmZm9ydCBpcyB1c2luZyBhIG1ldGFtb2RlbCB0byBkZXNjcmliZSB0aGUg a2V5IG9iamVjdHMgKGNhbGxlZCAmIzgyMjA7ZW50aXRpZXMmIzgyMjE7KSBpbiBhbiBYTUwgbW9k ZWwgYW5kIHRoZSBjb250ZW50IHJlZmVyZW5jZXMgKGNhbGxlZCAmIzgyMjA7cmVsYXRpb25zaGlw cyYjODIyMTspIHRoYXQgZXhpc3Qgd2l0aGluIGFuIFhNTCBkb2N1bWVudC4mbmJzcDsgV2UgaGF2 ZSBkZXZlbG9wZWQgYSBzaHJlZGRlciB0aGF0IHJlYWRzIGluIGFuIFhNTCBpbnN0YW5jZSwgYnJl YWtpbmcgZG93biB0aGUgZW50aXRpZXMgYW5kIHJlbGF0aW9uc2hpcHMuJm5ic3A7IEl0IHRoZW4g cGVyc2lzdHMgdGhlIFhNTCBjaHVua3MgaW4gYW4gWE1MIGRhdGFiYXNlIGFuZCB0aGUgZW50aXR5 IGFuZCByZWxhdGlvbnNoaXAgaW5mb3JtYXRpb24gaW4gYSBub24tcmVsYXRpb25hbCBSREYgZGF0 YWJhc2UuJm5ic3A7IFdlIGNhbiBhbHNvIHJlcXVlc3QgdGhlIGNvbnRlbnQgYmFjayBvdXQgb2Yg dGhlIGRhdGFzdG9yZSBhbmQgcmVjb25zdGl0dXRlIGl0LiZuYnNwOyBUaGUgYXBwcm9hY2ggd2Ug YXJlIHVzaW5nIGRvZXMgbm90IHBlcnR1cmIgdGhlIHVuZGVybHlpbmcgWE1MIGluZm9zZXQsIHNv IHNpZ25hdHVyZXMgY2FuIGJlIHZlcmlmaWVkIGZvciBjb250ZW50IHJldHJpZXZlZCBvdXQgb2Yg dGhlIHJlcG9zaXRvcnkuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XZSBhcmUg Y3VycmVudGx5IHdvcmtpbmcgb24gd2ViIHNlcnZpY2UgKFNPQVAgYW5kIFJFU1QpIGludGVyZmFj ZXMgYW5kIGEgZ2VuZXJhbGl6ZWQgcXVlcnkgbGFuZ3VhZ2UuJm5ic3A7IE91ciBjdXJyZW50IGRl dmVsb3BtZW50IHBoYXNlIHdpbGwgZW5kIGluIHRoZSBuZXh0IGNvdXBsZSBtb250aHMuJm5ic3A7 IFdlIGhvcGUgdG8gaGF2ZSBhIGRvd25sb2FkYWJsZSBkZW1vIGF2YWlsYWJsZSBiZWZvcmUgU2Vj dXJpdHkgQXV0b21hdGlvbiBEZXZlbG9wZXIgRGF5cyBpbiBlYXJseSBKdWx5IHRoYXQgd2lsbCBz dXBwb3J0IHJlcXVlc3RpbmcgYW4gU0NBUCBkYXRhc3RyZWFtIG9yIGEgY29sbGVjdGlvbiBvZiBP VkFML09DSUwgZGVmaW5pdGlvbnMgKGFuZCByZWxhdGVkIGNvbXBvbmVudHMpIGJ5IGlkZW50aWZp ZXIgYW5kIHZlcnNpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldlIGFyZSBh dm9pZGluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2JsZW0gYnkgZXh0cmFjdGluZyBhIEROUyBuYW1l IG91dCBvZiB0aGUgY29udGVudCBpZGVudGlmaWVyLiZuYnNwOyA8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Rm9yIGV4YW1wbGUgdGhlIGNvbnRlbnQgcmVmZXJlbmNlZCBieTogPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPm92YWw6b3JnLm1pdHJlLm92YWw6ZGVmOjE8 L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0 UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2FuIGJlIHJldHJpZXZlZCBieSB0aGUg Y29udGVudCBzZXJ2ZXIgJiM4MjIwO292YWwubWl0cmUub3JnJiM4MjIxOy48L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHBsYW4gaXMgdG8gdXNlIHRoaXMgdG8gbG9va3VwIGEg RE5TIFNSViByZWNvcmQgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzI3ODIu dHh0Ij5SRkMgMjc4MjwvYT4pIHRvIGxvY2F0ZSB0aGUgcmVwb3NpdG9yeSB0aGF0IGlzIHJlc3Bv bnNpYmxlIGZvciB0aGUgY29udGVudCBpZGVudGlmaWVkLiZuYnNwOyBUaGlzIGNhbiBiZSB1c2Vk IHRvIGR5bmFtaWNhbGx5IHJldHJpZXZlIHRoZSByZWZlcmVuY2VkIGNvbnRlbnQuJm5ic3A7IFdl IGFyZSBqdXN0IHN0YXJ0aW5nIHRvIHdvcmsgb3V0IGFuIFhNTCBmb3JtYXQgZm9yIHJlcG9zaXRv cnktdG8tcmVwb3NpdG9yeSBpbmZvcm1hdGlvbiBleGNoYW5nZSB0byBlbmFibGUgdGhpcyBjb21t dW5pY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BdCB0aGlzIHBvaW50 IG91ciBjdXJyZW50IHJlcG9zaXRvcnkgY29kZSBpcyBub3QgZmFyIGZyb20gcmVwbGFjaW5nIHRo ZSBkYXRhIGJhY2tlbmQgdGhhdCBpcyB1c2VkIGZvciB0aGUgT1ZBTCByZXBvc2l0b3J5LiZuYnNw OyBUaGUgY29vbCB0aGluZyBhYm91dCB0aGUgb3ZlcmFsbCBhcHByb2FjaCBpcyB0aGF0IG5vIE9W QUwgc3BlY2lmaWMgY29kZSBpcyBuZWNlc3NhcnkuJm5ic3A7IFdlIGhhdmUgY3JlYXRlZCBYTUwt YmFzZWQgc2hyZWRkaW5nIHJ1bGVzIGZvciBTQ0FQIGRhdGFzdHJlYW0sIE9WQUwgNS4xMC4xIGFu ZCBYQ0NERiAxLjIgZm9ybWF0cy4gJm5ic3A7SXQgaXMgZmFpcmx5IHRyaXZpYWwgdG8gY3JlYXRl IG5ldyBzaHJlZGRpbmcgcnVsZXMgZm9yIGFkZGl0aW9uYWwgbW9kZWxzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5Zb3UgY2FuIHJldmlldyB0aGUgY29kZSBhdDogPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFw aD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9jb2RlLmdvb2dsZS5jb20v cC9zZWN1cml0eS1hdXRvbWF0aW9uLWNvbnRlbnQtcmVwb3NpdG9yeS8iPmh0dHA6Ly9jb2RlLmdv b2dsZS5jb20vcC9zZWN1cml0eS1hdXRvbWF0aW9uLWNvbnRlbnQtcmVwb3NpdG9yeS88L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk1vc3Qgb2Ygb3VyIHdvcmsgaXMgYmVpbmcg ZG9uZSBpbiB0aGUgU1ZOIGJyYW5jaDo8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PGEgaHJlZj0iaHR0cDovL3NlY3VyaXR5LWF1dG9tYXRpb24tY29udGVudC1yZXBvc2l0b3J5Lmdv b2dsZWNvZGUuY29tL3N2bi9icmFuY2hlcy9uZXctc2hyZWRkZXIiPmh0dHA6Ly9zZWN1cml0eS1h dXRvbWF0aW9uLWNvbnRlbnQtcmVwb3NpdG9yeS5nb29nbGVjb2RlLmNvbS9zdm4vYnJhbmNoZXMv bmV3LXNocmVkZGVyPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgZG9j dW1lbnRhdGlvbiBpcyB2ZXJ5IHNwYXJzZSBhbmQgdGhlIGNvZGUgbmVlZHMgc29tZSBjbGVhbnVw LiZuYnNwOyBXZSBwbGFuIHRvIHdvcmsgb24gdGhpcyBpbiB0aGUgbmVhciBmdXR1cmUuJm5ic3A7 IE91ciBsb25nLXRlcm0gZ29hbCBpcyB0byBwcm92aWRlIGEgZnJlZWx5IGF2YWlsYWJsZSwgcHJv ZHVjdGlvbiBjYXBhYmxlIGNvbnRlbnQgcmVwb3NpdG9yeSBzZXJ2ZXIgdGhhdCBjYW4gcGFydGlj aXBhdGUgaW4gYSBmZWRlcmF0ZWQgbmV0d29yayBvZiBjb250ZW50IHNlcnZlcnMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFw aCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yKTxzcGFuIHN0 eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XZSBoYXZl IGFsc28gYmVlbiB3b3JraW5nIG9uIGEgY29udGVudCByZXBvc2l0b3J5IHNwZWNpZmljYXRpb24u Jm5ic3A7IFRoZSBnb2FsIGZvciB0aGlzIGRvY3VtZW50IGlzIHRvIGRlc2NyaWJlIHRoZSBvdmVy YWxsIGZlZGVyYXRpb24gYXBwcm9hY2ggYW5kIHRvIGRldGFpbCB0aGUgZGF0YSBleGNoYW5nZSBt b2RlbHMsIGludGVyZmFjZXMgYW5kIHRyYW5zcG9ydHMgbmVlZGVkIHRvIHN1cHBvcnQgaW50ZXJv cGVyYWJpbGl0eS4mbmJzcDsgSSBwbGFuIHRvIGhhdmUgYSBkcmFmdCBvZiB0aGlzIHNwZWNpZmlj YXRpb24gcmVhZHkgaW4gU2VwdGVtYmVyLiZuYnNwOyBJIHdvdWxkIGJlIGhhcHB5IHRvIHN1Ym1p dCB0aGlzIGFzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiB0byB0aGUgSUVURiB3aGVuIGl0IGlz IG1vcmUgY29tcGxldGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NeSBob3BlIGlzIHRoYXQgdGhpcyB3 b3JrIHdpbGwgYWRkcmVzcyBtYW55IG9mIHRoZSBjb21tdW5pdGllcyBjaGFsbGVuZ2VzIGluIHRo aXMgYXJlYS4mbmJzcDsgSSYjODIxNztkIGFwcHJlY2lhdGUgYW55IHRob3VnaHRzIG9yIGZlZWRi YWNrIG9uIHRoaXMgb3ZlcmFsbCBhcHByb2FjaC4mbmJzcDsgUGxlYXNlIGxldCBtZSBrbm93IGlm IHlvdSBoYXZlIGFueSBxdWVzdGlvbnMuJm5ic3A7IEkgaGF2ZSBhbHNvIHJlcXVlc3RlZCBhIHNl c3Npb24gYXQgdGhlIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXMgaG9zdGVkIGJ5 IE1JVFJFIGluIGVhcmx5IEp1bHkgdG8gcmV2aWV3IGFuZCBkaXNjdXNzIHRoaXMgd29yayBpbiBn cmVhdGVyIGRldGFpbC48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U2luY2VyZWx5LDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5E YXZlIFdhbHRlcm1pcmU8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBLZW50IExhbmRmaWVsZCA8YSBocmVmPSJtYWlsdG86 W21haWx0bzpLZW50X0xhbmRmaWVsZEBNQ0FGRUUuQ09NXSI+W21haWx0bzpLZW50X0xhbmRmaWVs ZEBNQ0FGRUUuQ09NXTwvYT4gPGJyPjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXByaWwgMjgsIDIw MTIgNjoxNyBQTTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1M SVNUQExJU1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8 L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09WQUwtREVWRUxPUEVSLUxJU1RdIEFjY2VzcyBW dWxuZXJhYmlsaXR5IERhdGFiYXNlIHdpdGggSmF2YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PGRpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjstKTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkFzIHdhcyBwcm9wZXJseSBwb2ludGVkIG91dCB0byBtZSAmIzgyMzA7dGhlcmUg d2FzIGEgdHlwbyBpbiBteSBtZXNzYWdlJiM4MjMwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPiZxdW90O1RoaXMgaXMgb25lIG9mIHRoZSB0b3BpY3MgSSB3b3VsZCBsaWtl IHRvIHNlZSBkZXZlbG9wZWQgb24gdGhlIFNDQU0gbGlzdC4mcXVvdDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TaG91bGQgaGF2ZSBiZWVuJiM4MjMwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgaXMgb25lIG9mIHRoZSB0b3BpY3MgSSB3 b3VsZCBsaWtlIHRvIHNlZSBkZXZlbG9wZWQgb24gdGhlIDxiPlNBQ008L2I+IGxpc3QuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Oy0pPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+S2VudCBM YW5kZmllbGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjA2QTcxJz48YnI+PHNwYW4gY2xh c3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3RvciBDb250ZW50IFN0cmF0ZWd5LCBBcmNoaXRlY3R1 cmUgYW5kIFN0YW5kYXJkczwvc3Bhbj48YnI+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5NY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55PC9z cGFuPjwvc3Ryb25nPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjUwMDAgSGVhZHF1 YXJ0ZXJzIERyLjwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5QbGFubywg VGV4YXMgNzUwMjQ8L3NwYW4+PGJyPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPkRp cmVjdDogKzEuOTcyLjk2My43MDk2Jm5ic3A7PC9zcGFuPjxicj48c3BhbiBjbGFzcz1hcHBsZS1z dHlsZS1zcGFuPk1vYmlsZTogKzEuODE3LjYzNy44MDI2PC9zcGFuPjxicj48c3Ryb25nPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+V2ViOiZuYnNwOzwvc3Bh bj48L3N0cm9uZz48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxhIGhyZWY9Imh0dHA6Ly93 d3cubWNhZmVlLmNvbS8iPnd3dy5tY2FmZWUuY29tPC9hPjwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZsdDtMYW5k ZmllbGQmZ3Q7LCBLZW50IExhbmRmaWVsZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOktlbnRfTGFuZGZp ZWxkQE1jQWZlZS5jb20iPktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb208L2E+Jmd0Ozxicj48Yj5S ZXBseS1UbzogPC9iPiZxdW90O09WQUwgRGV2ZWxvcGVyIExpc3QgKENsb3NlZCBQdWJsaWMgRGlz Y3Vzc2lvbikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNUQExJ U1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8L2E+Jmd0 Ozxicj48Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNU QExJU1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRS RS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZndDs8YnI+PGI+ U3ViamVjdDogPC9iPlJlOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gQWNjZXNzIFZ1bG5lcmFiaWxp dHkgRGF0YWJhc2Ugd2l0aCBKYXZhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5UaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBhdCB0aGUgbGFzdCB0d28gSVRTQUMgY29uZmVy ZW5jZSBhbmQgdGhlIFdpbnRlciBEZXZlbG9wZXIgRGF5cyBsYXN0IHllYXIuICZuYnNwO0Rpc2N1 c3Npb25zIGhhdmUgYmVlbiBoYWQgYXJvdW5kIHRoZSBuZWVkcyBvbiB0aGUgU0FDTSBsaXN0IGFz IHdlbGwuICZuYnNwOyBUaGlzIGlzIGFuIGVmZm9ydCB0byBnZXQgYSBzdGFuZGFyZCBtZWFucyBm b3IgZGlzdHJpYnV0aW5nIFNDQVAgcmVsYXRlZCBjb250ZW50IHdpdGhpbiBhbiBvcmdhbml6YXRp b24gYW5kIGFzIGEgcG90ZW50aWFsbHkgZmVkZXJhdGVkIG1lYW5zIG9mIG1hbmFnaW5nIGNvbnRl bnQgZGV2ZWxvcGVkIGJ5IGd1aWRhbmNlIGF1dGhvcnMgc3VjaCBhcyBDSVMsIE5JU1QsIG90aGVy IGdvdmVybm1lbnQgZW50aXRpZXMgYW5kIGluZHVzdHJ5IHZlcnRpY2Fscy48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Db3VwbGUgbGlua3MgdG8gcGFzdCBwcmVzZW50YXRp b25zLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHA6 Ly93d3cuZ29vZ2xlLmNvbS91cmw/c2E9dCZhbXA7cmN0PWomYW1wO3E9JmFtcDtlc3JjPXMmYW1w O3NvdXJjZT13ZWImYW1wO2NkPTImYW1wO3ZlZD0wQ0RBUUZqQUImYW1wO3VybD1odHRwJTNBJTJG JTJGc2NhcC5uaXN0LmdvdiUyRmV2ZW50cyUyRjIwMTElMkZzYWRkc3AlMkZwcmVzZW50YXRpb25z JTJGS2VudF9MYW5kZmllbGQtQXV0b21hdGlvbl9Db250ZW50X1JlcG9zaXRvcmllcy5wZGYmYW1w O2VpPW5sT2NULVA3TDhhV2lBS0dvNkdUQVEmYW1wO3VzZz1BRlFqQ05IdlRORXp0VlFtWmhraXNM a2RjQjU4RXBTOFN3JmFtcDtzaWcyPUhZNUpqRU56YzR3TWUydFZjNGluQUEiPmh0dHA6Ly93d3cu Z29vZ2xlLmNvbS91cmw/c2E9dCZhbXA7cmN0PWomYW1wO3E9JmFtcDtlc3JjPXMmYW1wO3NvdXJj ZT13ZWImYW1wO2NkPTImYW1wO3ZlZD0wQ0RBUUZqQUImYW1wO3VybD1odHRwJTNBJTJGJTJGc2Nh cC5uaXN0LmdvdiUyRmV2ZW50cyUyRjIwMTElMkZzYWRkc3AlMkZwcmVzZW50YXRpb25zJTJGS2Vu dF9MYW5kZmllbGQtQXV0b21hdGlvbl9Db250ZW50X1JlcG9zaXRvcmllcy5wZGYmYW1wO2VpPW5s T2NULVA3TDhhV2lBS0dvNkdUQVEmYW1wO3VzZz1BRlFqQ05IdlRORXp0VlFtWmhraXNMa2RjQjU4 RXBTOFN3JmFtcDtzaWcyPUhZNUpqRU56YzR3TWUydFZjNGluQUE8L2E+PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9zY2FwLm5pc3QuZ292L2V2ZW50cy8y MDExL3NhZGRzcC9wcmVzZW50YXRpb25zL1NlY3VyaXR5X0F1dG9tYXRpb25fQ29udGVudF9SZXBv c2l0b3J5X0RlbW8ucGRmIj5odHRwOi8vc2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9zYWRkc3Av cHJlc2VudGF0aW9ucy9TZWN1cml0eV9BdXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yeV9EZW1v LnBkZjwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxhIGhyZWY9Imh0dHA6Ly9zY2FwLm5pc3QuZ292L2V2ZW50cy8yMDExL2l0c2FjL3ByZXNl bnRhdGlvbnMvZGF5My9MYW5kZmllbGQsJTIwQ2hlcm5pbiwlMjBCYXNhdmFubmElMjAtJTIwQ29u dGVudCUyMFJlcG9zaXRvcmllcy5wZGYiPmh0dHA6Ly9zY2FwLm5pc3QuZ292L2V2ZW50cy8yMDEx L2l0c2FjL3ByZXNlbnRhdGlvbnMvZGF5My9MYW5kZmllbGQsJTIwQ2hlcm5pbiwlMjBCYXNhdmFu bmElMjAtJTIwQ29udGVudCUyMFJlcG9zaXRvcmllcy5wZGY8L2E+Jm5ic3A7Jm5ic3A7PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlcmUgd2FzIGFsc28gYSBwcmVzZW50 YXRpb24gdGhhdCBBZGFtIE1vbnR2aWxsZSBwcmVwYXJlZCBmb3IgdGhlIElFVEYgU0FDTSBTaWRl IG1lZXRpbmcuIFRoZXkgYXJlIGF2YWlsYWJsZSBpbiB0aGUgemlwIGZpbGUgb2YgdGhlIHByZXNl bnRhdGlvbnMgbG9jYXRlZCBpbiZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQnPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9zYWNtL2N1cnJlbnQvbXNnMDAxNzguaHRtbCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NhY20vY3VycmVudC9tc2cwMDE3OC5odG1sPC9hPiZu YnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ VGhpcyBpcyBvbmUgb2YgdGhlIHRvcGljcyBJIHdvdWxkIGxpa2UgdG8gc2VlIGRldmVsb3BlZCBv biB0aGUgU0NBTSBsaXN0LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPktlbnQgTGFuZGZpZWxkPC9zcGFuPjwvc3Ry b25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+ RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJlIGFuZCBTdGFuZGFyZHM8L3Nw YW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwvc3Bhbj48L3N0cm9uZz48YnI+PHNw YW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41MDAwIEhlYWRxdWFydGVycyBEci48L3NwYW4+PGJy PjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+UGxhbm8sIFRleGFzIDc1MDI0PC9zcGFuPjxi cj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3Q6ICsxLjk3Mi45NjMuNzA5 NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5Nb2JpbGU6ICsx LjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xh c3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3Lm1jYWZlZS5jb20vIj53d3cu bWNhZmVlLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5EYXZpZCBTb2xpbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmRhdmlkQEpPVkFMLk9SRyI+ZGF2aWRASk9WQUwuT1JHPC9hPiZndDs8YnI+PGI+UmVwbHkt VG86IDwvYj4mcXVvdDtPVkFMIERldmVsb3BlciBMaXN0IChDbG9zZWQgUHVibGljIERpc2N1c3Np b24pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5N SVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZndDs8YnI+ PGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNU Uy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JH Ij5PVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRzwvYT4mZ3Q7PGJyPjxiPlN1Ympl Y3Q6IDwvYj5SZTogW09WQUwtREVWRUxPUEVSLUxJU1RdIEFjY2VzcyBWdWxuZXJhYmlsaXR5IERh dGFiYXNlIHdpdGggSmF2YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9O X0JMT0NLUVVPVEUiPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2UnZCBjZXJ0YWlubHkg YmUgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgYW55IHN1Y2ggc3RhbmRhcmQuJm5ic3A7IENh biB5b3UgcG9pbnQgbWUgdG8gd2hvJ3MgYWN0aXZlbHkgZGlzY3Vzc2luZyBpdD8mbmJzcDsgRG9l cyBNSVRSRSBpbnRlbmQgdG8gc3VwcG9ydCBhbnkgc3RhbmRhcmQgYXBwcm9hY2hlcyB0byByZXBv c2l0b3J5IGFjY2Vzcz88YnI+PGJyPlJlZ2FyZHMsPGJyPi0tRGF2aWQ8YnI+PGJyPk9uIDQvMjgv MjAxMiA2OjU2IEFNLCBMdWlzIE51bmV6IHdyb3RlOiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+WW91IGtub3cgdGhlcmUgaXMgdGFsayBvZiBwcm9kdWNpbmcgYSBzdGFuZGFyZCBz cGVjIChzYWNtKSB0byBkbyBzb21ldGhpbmcgbGlrZSB0aGlzLiAmbmJzcDtJIGtub3cgd2UgYXJl IGJ1c3kgYnV0IHNvbWV0aGluZyB0byB0aGluayBhYm91dC4gPG86cD48L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+SXQgd291bGQgYmUgY29vbCB0byBqb3ZhbCBiZSBhYmxlIHRvIGRpcmVjdGx5 IHF1ZXJ5IGFuZCBwdWxsIGRvd24gY29udGVudCBkaXJlY3RseSBmcm9tIFNlY1BvZCBhbmQgb3Ro ZXIgcmVwb3NpdG9yaWVzIGluIGEgY29tbW9uIHdheS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD4tbG48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gQXByIDI3LCAyMDEy LCBhdCA1OjM5IFBNLCBEYXZpZCBTb2xpbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4mbmJzcDs8bzpwPjwv bzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPmpPVkFMIHByb3ZpZGVzIGEgcmVhZHktdG8tdXNlIEpBWEIgZGF0YSBtb2RlbCBmb3IgdGhl IE9WQUwgbGFuZ3VhZ2UsIHZhcmlvdXMgdXRpbGl0eSBjbGFzc2VzLCBhbmQgb2YgY291cnNlLCBh biBldmFsdWF0aW9uIGVuZ2luZSBhbmQgc2NhbiBwbHVnLWlucy4mbmJzcDsgSXQgZG9lcyBub3Qs IGhvd2V2ZXIsIGltcGxlbWVudCBhY2Nlc3MgdG8gYW55IG9uLWxpbmUgcmVwb3NpdG9yaWVzLjxi cj48YnI+RmVlbCBmcmVlIHRvIGNvbnRhY3QgbWUgZGlyZWN0bHkgaWYgeW91IGhhdmUgYW55IHF1 ZXN0aW9ucy48YnI+PGJyPlJlZ2FyZHMsPGJyPi0tRGF2aWQgU29saW48bzpwPjwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLSA8bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbGluZS1o ZWlnaHQ6MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YSBocmVmPSJodHRwOi8vak9WQUwu b3JnIj5qT1ZBTC5vcmc8L2E+OiBPVkFMIGltcGxlbWVudGVkIGluIEphdmEuPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzMzMzMzMyc+PGJyPjwvc3Bhbj48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPlNjYW4gYW55 IG1hY2hpbmUgZnJvbSBhbnkgbWFjaGluZS4gRm9yIGZyZWUhPC9zcGFuPjwvaT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiMzMzMzMzMnPjxicj48YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy8iPjxzcGFuIHN0eWxl PSdjb2xvcjojMzM2NjAwJz5MZWFybiBNb3JlPC9zcGFuPjwvYT4gfCA8YSBocmVmPSJodHRwOi8v d3d3LmpvdmFsLm9yZy9mZWF0dXJlcy8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5GZWF0 dXJlczwvc3Bhbj48L2E+IHwgPGEgaHJlZj0iaHR0cDovL3d3dy5qb3ZhbC5vcmcvZG93bmxvYWQv Ij48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjYwMCc+RG93bmxvYWQ8L3NwYW4+PC9hPiA8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj5PbiA0LzI3LzIwMTIg ODo0OCBBTSwgdnVsaXN0cyB3cm90ZTogPG86cD48L286cD48L3A+PHByZT5IaSBUaGVyZSw8bzpw PjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT48cHJlPkknbSBsb29raW5n IGZvciBhIHdheSB0byBhY2Nlc3MgYSBWdWxuZXJhYmlsaXR5IERhdGFiYXNlIHdpdGggSmF2YS48 bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT48cHJlPkF0IHRoZSBt b21lbnQgSSdtIG5vdCAxMDAlIHN1cmUgaWYgaXRzIGdvbm5hIGJlIE9wZW5WQVMgb3Igc29tZXRo aW5nPG86cD48L286cD48L3ByZT48cHJlPmVsc2UsIGxpa2UgZS5nLiBPVkFMLjxvOnA+PC9vOnA+ PC9wcmU+PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPjxwcmU+SSB3YW50ZWQgdG8gYXNrLCBp ZiBzb21lYm9keSBrbm93cyBzb21lIHJlYWR5LXRvLXVzZSBKYXZhIEFQSSB0byBhY2Nlc3M8bzpw PjwvbzpwPjwvcHJlPjxwcmU+JnF1b3Q7b25lIG9mIHRob3NlJnF1b3Q7IFZ1bG5lcmFiaWxpdHkg RGF0YWJhc2VzLjxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPjxw cmU+SWYgdGhhdHMgbm90IHRoZSBjYXNlLCBkb2VzIGl0IG1lYW4gSSBoYXZlIHRvIGltcGxlbWVu dCBteSBvd24gWE1MPG86cD48L286cD48L3ByZT48cHJlPlBhcnNlciB0byBnZXQgdGhlIHZ1bG5l cmFiaWxpdHkgZGF0YSBpbnRvIG15IGRhdGFiYXNlPzxvOnA+PC9vOnA+PC9wcmU+PHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPjxwcmU+V2hhdCBhYm91dCBzdGFuZGFyZCBmb3JtYXRzPzxvOnA+ PC9vOnA+PC9wcmU+PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT48cHJlPlRoYW5rcyBhbmQga2luZCByZWdhcmRzPG86cD48L286cD48L3ByZT48 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+PHByZT5UbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBl bWFpbCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkci PkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzwvYT4gd2l0aDxvOnA+PC9vOnA+PC9wcmU+PHByZT5T SUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+aW4gdGhlIEJP RFkgb2YgdGhlIG1lc3NhZ2UuJm5ic3A7IElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUg dG8gPGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRS RS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8L2E+Ljxv OnA+PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNz YWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkciPkxJU1RTRVJW QExJU1RTLk1JVFJFLk9SRzwvYT4gd2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1QgaW4g dGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUg dG8gPGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRS RS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8L2E+LiA8 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvIHVuc3Vic2NyaWJlLCBz ZW5kIGFuIGVtYWlsIG1lc3NhZ2UgdG8gPGEgaHJlZj0ibWFpbHRvOkxJU1RTRVJWQExJU1RTLk1J VFJFLk9SRyI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPC9hPiB3aXRoIFNJR05PRkYgT1ZBTC1E RVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUgbWVzc2FnZS4gSWYgeW91IGhhdmUgZGlm ZmljdWx0aWVzLCB3cml0ZSB0byA8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1y ZXF1ZXN0QExJU1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RT Lk1JVFJFLk9SRzwvYT4uIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPi0tIDxvOnA+PC9vOnA+PC9wPjxwIHN0eWxlPSdsaW5lLWhlaWdodDoxMi4wcHQn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMzMzMzMzMnPmpPVkFMLm9yZzogT1ZBTCBpbXBsZW1lbnRlZCBpbiBKYXZh Ljwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxicj48L3NwYW4+PGk+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMz MzMzJz5TY2FuIGFueSBtYWNoaW5lIGZyb20gYW55IG1hY2hpbmUuIEZvciBmcmVlITwvc3Bhbj48 L2k+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5qb3ZhbC5vcmci PjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5MZWFybiBNb3JlPC9zcGFuPjwvYT4gfCA8YSBo cmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy9mZWF0dXJlcy8iPjxzcGFuIHN0eWxlPSdjb2xvcjoj MzM2NjAwJz5GZWF0dXJlczwvc3Bhbj48L2E+IHwgPGEgaHJlZj0iaHR0cDovL3d3dy5qb3ZhbC5v cmcvZG93bmxvYWQvIj48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjYwMCc+RG93bmxvYWQ8L3NwYW4+ PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VG8gdW5z dWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byA8YSBocmVmPSJtYWlsdG86TElTVFNF UlZATElTVFMuTUlUUkUuT1JHIj5MSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc8L2E+IHdpdGggU0lH Tk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiBJZiB5 b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIDxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVM T1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNULXJl cXVlc3RATElTVFMuTUlUUkUuT1JHPC9hPi4gPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjxwIGNsYXNzPU1zb05vcm1hbD5UbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFp bCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkciPkxJ U1RTRVJWQExJU1RTLk1JVFJFLk9SRzwvYT4gd2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJ U1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywg d3JpdGUgdG8gPGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNU Uy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8 L2E+LiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNv Tm9ybWFsPlRvIHVuc3Vic2NyaWJlLCBzZW5kIGFuIGVtYWlsIG1lc3NhZ2UgdG8gPGEgaHJlZj0i bWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRyI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JH PC9hPiB3aXRoIFNJR05PRkYgT1ZBTC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUg bWVzc2FnZS4gSWYgeW91IGhhdmUgZGlmZmljdWx0aWVzLCB3cml0ZSB0byA8YSBocmVmPSJtYWls dG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZF TE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRzwvYT4uIDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48cHJlPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT48 cHJlPnNhY20gbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Im1haWx0 bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvcHJl PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIDxvOnA+PC9vOnA+PC9wPjxw IHN0eWxlPSdsaW5lLWhlaWdodDoxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPmpPVkFMLm9y ZzogT1ZBTCBpbXBsZW1lbnRlZCBpbiBKYXZhLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxi cj48L3NwYW4+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz5TY2FuIGFueSBtYWNoaW5lIGZyb20gYW55 IG1hY2hpbmUuIEZvciBmcmVlITwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PGEg aHJlZj0iaHR0cDovL3d3dy5qb3ZhbC5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5M ZWFybiBNb3JlPC9zcGFuPjwvYT4gfCA8YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy9mZWF0 dXJlcy8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5GZWF0dXJlczwvc3Bhbj48L2E+IHwg PGEgaHJlZj0iaHR0cDovL3d3dy5qb3ZhbC5vcmcvZG93bmxvYWQvIj48c3BhbiBzdHlsZT0nY29s b3I6IzMzNjYwMCc+RG93bmxvYWQ8L3NwYW4+PC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930B98F8684EMBCLUSTERxcha_-- From david.waltermire@nist.gov Thu May 3 09:43:05 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 6036221F8610 for ; Thu, 3 May 2012 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.29 X-Spam-Level: X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2wi6AzpHw7l for ; Thu, 3 May 2012 09:43:01 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A3E9D21F8601 for ; Thu, 3 May 2012 09:43:00 -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.355.2; Thu, 3 May 2012 12:42:34 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 3 May 2012 12:42:53 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Thu, 3 May 2012 12:42:52 -0400 Thread-Topic: Use Cases Thread-Index: Ac0pMdnNgGvxcIN8RIamBbiNsEWI7g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sacm] Use Cases 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, 03 May 2012 16:43:05 -0000 --_004_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_ Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_" --_000_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Before we move on, I'd like to make one last call for feedback on the use cases before moving forward. Even statements that you are happy with what is there would be welcome. I'd like to allow a few more days for feedback. I have attached the last revision I posted a couple weeks back for convenience. Please send your feedback by CoB 5/7/2012. The next step will be to find volunteers to work on fleshing out the use cases. Anyone interested? Sincerely, Dave --_000_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+ PHAgY2xhc3M9TXNvTm9ybWFsPkJlZm9yZSB3ZSBtb3ZlIG9uLCBJJiM4MjE3O2QgbGlrZSB0byBt YWtlIG9uZSBsYXN0IGNhbGwgZm9yIGZlZWRiYWNrIG9uIHRoZSB1c2UgY2FzZXMgYmVmb3JlIG1v dmluZyBmb3J3YXJkLiZuYnNwOyBFdmVuIHN0YXRlbWVudHMgdGhhdCB5b3UgYXJlIGhhcHB5IHdp dGggd2hhdCBpcyB0aGVyZSB3b3VsZCBiZSB3ZWxjb21lLiZuYnNwOyBJJiM4MjE3O2QgbGlrZSB0 byBhbGxvdyBhIGZldyBtb3JlIGRheXMgZm9yIGZlZWRiYWNrLiZuYnNwOyBJIGhhdmUgYXR0YWNo ZWQgdGhlIGxhc3QgcmV2aXNpb24gSSBwb3N0ZWQgYSBjb3VwbGUgd2Vla3MgYmFjayBmb3IgY29u dmVuaWVuY2UuJm5ic3A7IFBsZWFzZSBzZW5kIHlvdXIgZmVlZGJhY2sgYnkgQ29CIDUvNy8yMDEy LiZuYnNwOyBUaGUgbmV4dCBzdGVwIHdpbGwgYmUgdG8gZmluZCB2b2x1bnRlZXJzIHRvIHdvcmsg b24gZmxlc2hpbmcgb3V0IHRoZSB1c2UgY2FzZXMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5BbnlvbmUgaW50 ZXJlc3RlZD88bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+RGF2ZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_-- --_004_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_ Content-Type: text/plain; name="draft-waltermire-sacm-use-cases-00-v2.txt" Content-Description: draft-waltermire-sacm-use-cases-00-v2.txt Content-Disposition: attachment; filename="draft-waltermire-sacm-use-cases-00-v2.txt"; size=14703; creation-date="Thu, 03 May 2012 12:40:19 GMT"; modification-date="Thu, 03 May 2012 12:40:19 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RC4gV2FsdGVybWlyZSwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTklTVApJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMTQsIDIwMTIKRXhwaXJl czogT2N0b2JlciAxNiwgMjAxMgoKCiAgQW5hbHlzaXMgb2YgU2VjdXJpdHkgQXV0b21hdGlvbiBh bmQgQ29udGludW91cyBNb25pdG9yaW5nIChTQUNNKSBVc2UKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2FzZXMKICAgICAgICAgICAgICAgICAgIGRyYWZ0LXdhbHRlcm1pcmUtc2Fj bS11c2UtY2FzZXMtMDAKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgZm91 bmRhdGlvbmFsIHVzZSBjYXNlcywgZGVyaXZlZCBmdW5jdGlvbmFsCiAgIGNhcGFiaWxpdGllcyBh bmQgcmVxdWlyZW1lbnRzLCBhcmNoaXRlY3R1cmFsIGNvbXBvbmVudHMsIGFuZCB0aGUKICAgc3Vw cG9ydGluZyBzdGFuZGFyZHMgbmVlZGVkIHRvIGRlZmluZSBhbiBpbnRlcm9wZXJhYmxlLCBhdXRv bWF0aW9uCiAgIGluZnJhc3RydWN0dXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGltZWx5LCBhY2N1 cmF0ZSBhbmQgYWN0aW9uYWJsZQogICBzaXR1YXRpb25hbCBhd2FyZW5lc3Mgb3ZlciBhbiBvcmdh bml6YXRpb24ncyBJVCBzeXN0ZW1zLiAgQXV0b21hdGlvbgogICB0b29scyBpbXBsZW1lbnRpbmcg YSBjb250aW51b3VzIG1vbml0b3JpbmcgYXBwcm9hY2ggd2lsbCB1dGlsaXplIHRoaXMKICAgaW5m cmFzdHJ1Y3R1cmUgdG9nZXRoZXIgd2l0aCBleGlzdGluZyBhbmQgZW1lcmdpbmcgZXZlbnQsIGlu Y2lkZW50CiAgIGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQgc3RhbmRhcmRzIHRvIHByb3ZpZGUgdmlz aWJpbGl0eSBpbnRvIHRoZSBzdGF0ZQogICBvZiBhc3NldHMsIHVzZXIgYWN0aXZpdGllcyBhbmQg bmV0d29yayBiZWhhdmlvci4gIFN0YWtlaG9sZGVycyB3aWxsCiAgIGJlIGFibGUgdG8gdXNlIHRo ZXNlIHRvb2xzIHRvIGFnZ3JlZ2F0ZSBhbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eQogICBh bmQgb3BlcmF0aW9uYWwgZGF0YSB0byB1bmRlcnN0YW5kIHRoZSBvcmdhbml6YXRpb25zIHNlY3Vy aXR5CiAgIHBvc3R1cmUsIHF1YW50aWZ5IGJ1c2luZXNzIHJpc2ssIGFuZCBtYWtlIGluZm9ybWVk IGRlY2lzaW9ucyB0aGF0CiAgIHN1cHBvcnQgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGls ZSBwcm90ZWN0aW5nIGNyaXRpY2FsCiAgIGluZm9ybWF0aW9uLiAgT3JnYW5pemF0aW9ucyB3aWxs IGJlIGFibGUgdG8gdXNlIHRoZXNlIHRvb2xzIHRvCiAgIGF1Z21lbnQgYW5kIGF1dG9tYXRlIGlu Zm9ybWF0aW9uIHNoYXJpbmcgYWN0aXZpdGllcyB0byBjb2xsYWJvcmF0ZQogICB3aXRoIHBhcnRu ZXJzIHRvIGlkZW50aWZ5IGFuZCBtaXRpZ2F0ZSB0aHJlYXRzLiAgT3RoZXIgYXV0b21hdGlvbgog ICB0b29scyB3aWxsIGJlIGFibGUgdG8gaW50ZWdyYXRlIHdpdGggdGhlc2UgY2FwYWJpbGl0aWVz IHRvIGVuZm9yY2UKICAgcG9saWNpZXMgYmFzZWQgb24gaHVtYW4gZGVjaXNpb25zIHRvIGhhcmRl biBzeXN0ZW1zLCBwcmV2ZW50IG1pc3VzZQogICBhbmQgcmVkdWNlIHRoZSBvdmVyYWxsIGF0dGFj ayBzdXJmYWNlLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgQnkgc3VibWl0dGluZyB0aGlzIElu dGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55CiAgIGFwcGxpY2Fi bGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJl CiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBv ciBzaGUgYmVjb21lcwogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3 aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRG KS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9j dXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgoK CldhbHRlcm1pcmUgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxNiwgMjAxMiAgICAgICAg ICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU0FDTSBVc2Ug Q2FzZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMgoKCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAxNiwgMjAxMi4KCgpUYWJsZSBvZiBDb250ZW50cwoK ICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAzCiAgICAgMS4xLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNAogICAyLiAgS2V5IENvbmNlcHRzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgMy4gIFVz ZSBDYXNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA0CiAgICAgMy4xLiAgVUMxOiBBc3Nlc3NtZW50IGFuZCBFbmZvcmNlbWVudCBvZiBBY2Nl cHRhYmxlIFN0YXRlIC4gLiAuIC4gNAogICAgIDMuMi4gIFVDMjogQmVoYXZpb3JhbCBNb25pdG9y aW5nIGFuZCBFbmZvcmNlbWVudCAgLiAuIC4gLiAuIC4gLiAuIDQKICAgICAzLjMuICBVQzM6IFNl Y3VyaXR5IENvbnRyb2wgVmVyaWZpY2F0aW9uIGFuZCBNb25pdG9yaW5nIC4gLiAuIC4gLiA0CiAg ICAgMy40LiAgVUM0OiBTZWN1cmUgRXhjaGFuZ2Ugb2YgR292ZXJuYW5jZSwgUmlzayBhbmQKICAg ICAgICAgICBDb21wbGlhbmNlIChHUkMpIEluZm9ybWF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA0CiAgICAgMy41LiAgVUM1OiBBdXRvbWF0ZWQgRm9yZW5zaWNzIEludmVzdGln YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICA0LiAgRnVuY3Rpb25hbCBDYXBhYmlsbGl0 aWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKICAgICA0LjEuICBG dW5jdGlvbmFsIENhcGFiaWxpdHkgMSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA1CiAgICAgNC4yLiAgRnVuY3Rpb25hbCBDYXBhYmlsaXR5IG4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNQogICA1LiAgRnVuY3Rpb25hbCBDb21wb25lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKICAgNi4gIERhdGEgRXhjaGFuZ2Ug TW9kZWxzIGFuZCBDb21tdW5pY2F0aW9ucyBQcm90b2NvbHMgLiAuIC4gLiAuIC4gLiA2CiAgIDcu ICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNgogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYKICAgOS4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgICAgOS4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NgogICAgIDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDYKICAgQXBwZW5kaXggQS4gIEFkZGl0aW9uYWwgU3R1ZmYgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgIEF1dGhvcidzIEFkZHJlc3MgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICBJbnRl bGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzICAuIC4gLiAuIC4gLiAu IC4gLiAuIDgKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpXYWx0ZXJtaXJlICAgICAgICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMTYsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIFNBQ00gVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFw cmlsIDIwMTIKCgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyBm b3VuZGF0aW9uYWwgdXNlIGNhc2VzIHRvIGJlIGNvbnNpZGVyZWQgd2hlbgogICBlc3RhYmxpc2hp bmcgYSBjaGFydGVyIGZvciB0aGUgU2VjdXJpdHkgQXV0b21hdGlvbiBhbmQgQ29udGludW91cwog ICBNb25pdG9yaW5nIChTQUNNKSB3b3JraW5nIGdyb3VwIHdpdGhpbiB0aGUgSUVURi4gIFRoaXMg d29ya2luZyBncm91cAogICB3aWxsIGFkZHJlc3MgYSBwb3J0aW9uIG9mIHRoZSBzdGFuZGFyZHMg bmVlZGVkIHRvIGRlZmluZSBhbgogICBpbnRlcm9wZXJhYmxlLCBhdXRvbWF0aW9uIGluZnJhc3Ry dWN0dXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGltZWx5LAogICBhY2N1cmF0ZSBhbmQgYWN0aW9u YWJsZSBzaXR1YXRpb25hbCBhd2FyZW5lc3Mgb3ZlciBhbiBvcmdhbml6YXRpb24ncwogICBJVCBz eXN0ZW1zLiAgVGhpcyBkb2N1bWVudCB3aWxsIGVudW1lcmF0ZSB1c2UgY2FzZXMgYW5kIGJyZWFr IGRvd24KICAgcmVsYXRlZCBjb25jZXB0cyB0aGF0IGNyb3NzIG1hbnkgSVQgc2VjdXJpdHkgaW5m b3JtYXRpb24gZG9tYWlucy4KCiAgIFNlY3Rpb25zIFsuLi5dIG9mIHRoaXMgZG9jdW1lbnQgZm9j dXMgb246CgogICAgICBEZWZpbmluZyB0aGUga2V5IGNvbmNlcHRzIGFuZCB0ZXJtaW5vbG9neSB1 c2VkIHdpdGhpbiB0aGUgZG9jdW1lbnQKICAgICAgcHJvdmlkaW5nIGEgY29tbW9uIGZyYW1lIG9m IHJlZmVyZW5jZTsKCiAgICAgIElkZW50aWZ5aW5nIGZvdW5kYXRpb25hbCB1c2UgY2FzZXMgdGhh dCByZXByZXNlbnQgY2xhc3NlcyBvZgogICAgICBzdGFrZWhvbGRlcnMsIGdvYWxzLCBhbmQgdXNh Z2Ugc2NlbmFyaW9zOwoKICAgICAgQSBzZXQgb2YgZGVyaXZlZCBmdW5jdGlvbmFsIGNhcGFiaWxp dGllcyBhbmQgYXNzb2NpYXRlZAogICAgICByZXF1aXJlbWVudHMgdGhhdCBhcmUgbmVlZGVkIHRv IHN1cHBvcnQgdGhlIHVzZSBjYXNlczsKCiAgICAgIEEgYnJlYWsgZG93biBvZiBhcmNoaXRlY3R1 cmFsIGNvbXBvbmVudHMgdGhhdCBhZGRyZXNzIG9uZSBvciBtb3JlCiAgICAgIGZ1bmN0aW9uYWwg Y2FwYWJpbGl0aWVzIHRoYXQgY2FuIGJlIHVzZWQgaW4gdmFyaW91cyBjb21iaW5hdGlvbnMKICAg ICAgdG8gc3VwcG9ydCB0aGUgdXNlIGNhc2VzOyBhbmQKCiAgICAgIEFuIGludmVudG9yeSBvZiBl eGlzdGluZywgZW1lcmdpbmcsIGFuZCBuZWVkZWQgZGF0YSBleGNoYW5nZQogICAgICBtb2RlbHMg YW5kIGNvbW11bmljYXRpb25zIHByb3RvY29scyB0aGF0IGFyZSByZXF1aXJlZCB0byBzdXBwb3J0 CiAgICAgIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBhcmNoaXRlY3R1cmFsIGNvbXBvbmVudHMu CgogICBUaGUgc3RhbmRhcmRzIGlkZW50aWZpZWQgaW4gdGhpcyBkb2N1bWVudCBwcm92aWRlIGEg Zm91bmRhdGlvbiBmb3IKICAgY3JlYXRpbmcgaW50ZXJvcGVyYWJsZSBhdXRvbWF0aW9uIHRvb2xz IGFuZCBjb250aW51b3VzIG1vbml0b3JpbmcKICAgc29sdXRpb25zIHRoYXQgcHJvdmlkZSB2aXNp YmlsaXR5IGludG8gdGhlIHN0YXRlIG9mIGFzc2V0cywgdXNlcgogICBhY3Rpdml0aWVzLCBhbmQg bmV0d29yayBiZWhhdmlvci4gIFN0YWtlaG9sZGVycyB3aWxsIGJlIGFibGUgdG8gdXNlCiAgIHRo ZXNlIHRvb2xzIHRvIGFnZ3JlZ2F0ZSBhbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eSBhbmQK ICAgb3BlcmF0aW9uYWwgZGF0YSB0byB1bmRlcnN0YW5kIHRoZSBvcmdhbml6YXRpb25zIHNlY3Vy aXR5IHBvc3R1cmUsCiAgIHF1YW50aWZ5IGJ1c2luZXNzIHJpc2ssIGFuZCBtYWtlIGluZm9ybWVk IGRlY2lzaW9ucyB0aGF0IHN1cHBvcnQKICAgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGls ZSBwcm90ZWN0aW5nIGNyaXRpY2FsIGluZm9ybWF0aW9uLgogICBPcmdhbml6YXRpb25zIHdpbGwg YmUgYWJsZSB0byB1c2UgdGhlc2UgdG9vbHMgdG8gYXVnbWVudCBhbmQgYXV0b21hdGUKICAgaW5m b3JtYXRpb24gc2hhcmluZyBhY3Rpdml0aWVzIHRvIGNvbGxhYm9yYXRlIHdpdGggcGFydG5lcnMg dG8KICAgaWRlbnRpZnkgYW5kIG1pdGlnYXRlIHRocmVhdHMuICBPdGhlciBhdXRvbWF0aW9uIHRv b2xzIHdpbGwgYmUgYWJsZQogICB0byBpbnRlZ3JhdGUgd2l0aCB0aGVzZSBjYXBhYmlsaXRpZXMg dG8gZW5mb3JjZSBwb2xpY2llcyBiYXNlZCBvbgogICBodW1hbiBkZWNpc2lvbnMgdG8gaGFyZGVu IHN5c3RlbXMsIHByZXZlbnQgbWlzdXNlIGFuZCByZWR1Y2UgdGhlCiAgIG92ZXJhbGwgYXR0YWNr IHN1cmZhY2UuCgoKCgoKCgpXYWx0ZXJtaXJlICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MTYsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgIFNBQ00gVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTIKCgoxLjEu ICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAg ZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBb UkZDMjExOV0uCgoKMi4gIEtleSBDb25jZXB0cwoKICAgRGVmaW5lL3JlZmVyZW5jZSB0aGUgbWFq b3IgY29uY2VwdHMgaW5jbHVkZWQgaW4gdGhpcyBkb2N1bWVudC4KCgozLiAgVXNlIENhc2VzCgog ICBEZXNjcmliZSB1c2UgY2FzZXMsIG9uZSBwZXIgc3ViLXNlY3Rpb24uCgogICBUaGluZ3MgdG8g Y29uc2lkZXIgaW5jbHVkaW5nIChidXQgbm90IGxpbWl0ZWQgdG8pOgoKICAgbyAgVXNhZ2Ugc2Nl bmFyaW9zIChlLmcuICBTZWN1cml0eSBDb250cm9sIFZlcmlmaWNhdGlvbiwgRW5kcG9pbnQKICAg ICAgRW5mb3JjZW1lbnQsIEluY2lkZW50IERldGVjdGlvbiwgRm9yZW5zaWMgSW52ZXN0aWdhdGlv biwgZXRjLikKCiAgIG8gIEluZm9ybWF0aW9uIERvbWFpbnMgKGUuZy4gY29uZmlndXJhdGlvbiwg dnVsbmVyYWJpbGl0eSwgZGlnaXRhbAogICAgICBldmVudHMsIGV0Yy4pCgozLjEuICBVQzE6IEFz c2Vzc21lbnQgYW5kIEVuZm9yY2VtZW50IG9mIEFjY2VwdGFibGUgU3RhdGUKCiAgIENvbnRyb2xs aW5nIGFjY2VzcyB0byBuZXR3b3JrcyBhbmQgc2VydmljZXMgYmFzZWQgb24gdGhlIGFzc2Vzc21l bnQKICAgYW5kIGFuYWx5c2lzIG9mIGhvc3QgYW5kL29yIG5ldHdvcmsgc3RhdGUgYmFzZWQgb24g bWFjaGluZQogICBwcm9jZXNzYWJsZSBjb250ZW50LgoKMy4yLiAgVUMyOiBCZWhhdmlvcmFsIE1v bml0b3JpbmcgYW5kIEVuZm9yY2VtZW50CgogICBDb250cm9sbGluZyBhY2Nlc3MgdG8gbmV0d29y a3MgYW5kIHNlcnZpY2VzIGJhc2VkIG9uIHRoZSBkZXRlY3Rpb24KICAgYW5kIGFuYWx5c2lzIG9m IGhvc3QgYW5kL29yIHVzZXIgYmVoYXZpb3IgdXNpbmcgYXV0b21hdGFibGUKICAgaW5mb3JtYXRp b24gZnJvbSB2YXJpb3VzIHNvdXJjZXMuCgozLjMuICBVQzM6IFNlY3VyaXR5IENvbnRyb2wgVmVy aWZpY2F0aW9uIGFuZCBNb25pdG9yaW5nCgogICBDb250aW51b3VzIGFzc2Vzc21lbnQgb2YgdGhl IGltcGxlbWVudGF0aW9uIGFuZCBlZmZlY3RpdmVuZXNzIG9mCiAgIHNlY3VyaXR5IGNvbnRyb2xz IGJhc2VkIG9uIG1hY2hpbmUgcHJvY2Vzc2FibGUgY29udGVudC4KCjMuNC4gIFVDNDogU2VjdXJl IEV4Y2hhbmdlIG9mIEdvdmVybmFuY2UsIFJpc2sgYW5kIENvbXBsaWFuY2UgKEdSQykKICAgICAg SW5mb3JtYXRpb24KCiAgIFNoYXJpbmcgc2VjdXJpdHkgYW5kL29yIG9wZXJhdGlvbmFsbHkgcmVs ZXZhbnQgaW5mb3JtYXRpb24gd2l0aGluIGFuZAogICBhY3Jvc3MgdHJ1c3QgYm91bmRhcmllcyB1 c2luZyBzZWN1cmUsIGF1dG9tYXRlZCBjb21tdW5pY2F0aW9uCiAgIGNoYW5uZWxzIGFuZCBmb3Jt YXRzLgoKCgoKV2FsdGVybWlyZSAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDE2LCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBT QUNNIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEyCgoKMy41LiAgVUM1OiBB dXRvbWF0ZWQgRm9yZW5zaWNzIEludmVzdGlnYXRpb24KCiAgIFJlbW90ZSBhbmQvb3IgbG9jYWwg Y29sbGVjdGlvbiBvZiBvcmdhbml6YXRpb25hbCwgbmV0d29yaywgYW5kL29yCiAgIGhvc3QgaW5m b3JtYXRpb24gZm9yIHRoZSBwdXJwb3NlIG9mIGluY2lkZW50IGludmVzdGlnYXRpb24gYW5kCiAg IHJlc3BvbnNlLgoKCjQuICBGdW5jdGlvbmFsIENhcGFiaWxsaXRpZXMKCiAgIERlY29tcG9zZSB0 aGUgZnVuY3Rpb25hbCBjYXBhYmlsaXRpZXMgbmVlZGVkIHRvIHN1cHBvcnQgdGhlIHVzZQogICBj YXNlcywgb25lIHBlciBzdWItc2VjdGlvbi4gIENyb3NzIHJlZmVyZW5jZSB0aGUgdXNlIGNhc2UK ICAgZGVwZW5kZW5jaWVzIHdoZXJlIHRoZXkgZXhpc3QuCgogICBUaGluZ3MgdG8gY29uc2lkZXIg aW5jbHVkaW5nIChidXQgbm90IGxpbWl0ZWQgdG8pOgoKICAgbyAgSW5mb3JtYXRpb24gVmlld3Mv UmVwb3J0cyAoZS5nLiBzZWN1cml0eSBwb3N0dXJlLCBjb21wbGlhbmNlLAogICAgICBjb250cm9s IGVmZmVjdGl2ZW5lc3MpCgogICBvICBEYXRhIENvbGxlY3Rpb24gKGUuZy4gY29uZmlndXJhdGlv biBzdGF0ZSwgc29mdHdhcmUgaW52ZW50b3J5LAogICAgICB1c2VyIGFuZCBuZXR3b3JrIGJlaGF2 aW9yKQoKICAgbyAgUmVmZXJlbmNlIEluZm9ybWF0aW9uIEZvcm1hdHMgKGUuZy4gY29udHJvbCBj YXRhbG9ncywKICAgICAgY29uZmlndXJhdGlvbiBiYXNlbGluZXMsIG1hbHdhcmUgY2hhcmFjdGVy aXN0aWNzLCB2dWxuZXJhYmlsaXR5CiAgICAgIGRhdGEpCgo0LjEuICBGdW5jdGlvbmFsIENhcGFi aWxpdHkgMQoKICAgRGVzY3JpYmUgdGhlIGZpcnN0IGNhcGFiaWxpdHkuCgo0LjIuICBGdW5jdGlv bmFsIENhcGFiaWxpdHkgbgoKICAgRGVzY3JpYmUgdGhlIG4gY2FwYWJpbGl0eS4KCgo1LiAgRnVu Y3Rpb25hbCBDb21wb25lbnRzCgogICBEZXNjcmliZSB0aGUgYWJzdHJhY3QgZnVuY3Rpb25hbCBj b21wb25lbnRzIG5lZWRlZCB0byBwcm92aWRlIHRoZQogICBjYXBhYmlsaXRpZXMgZGVzY3JpYmVk IGluIHRoZSBwcmV2aW91cyBzZWN0aW9uLiAgRGVzY3JpYmUgYW55CiAgIHJlbGF0aW9uc2hpcHMg YmV0d2VlbiB0aGUgY29tcG9uZW50cyBhbmQgaG93IHRoZXkgY2FuIGJlIGNvbXBvc2VkIHRvCiAg IGFkZHJlc3MgZnVuY3Rpb25hbCBjYXBhYmlsaXRpZXMuICh0aGlzIG1pZ2h0IGJlIGJldHRlciBk ZWZpbmVkIGluIHRoZQogICBwcmV2aW91cyBzZWN0aW9uLikKCiAgIFRoaW5ncyB0byBjb25zaWRl ciBpbmNsdWRpbmcgKGJ1dCBub3QgbGltaXRlZCB0byk6CgogICBvICBUb3BvbG9naWVzCgogICBv ICBGZWRlcmF0aW9uIFN0cmF0ZWd5CgoKCgpXYWx0ZXJtaXJlICAgICAgICAgICAgICBFeHBpcmVz IE9jdG9iZXIgMTYsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIFNBQ00gVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIw MTIKCgo2LiAgRGF0YSBFeGNoYW5nZSBNb2RlbHMgYW5kIENvbW11bmljYXRpb25zIFByb3RvY29s cwoKICAgRG9jdW1lbnQgd2hlcmUgZXhpc3Rpbmcgd29yayBleGlzdHMsIHdoYXQgaXMgY3VycmVu dGx5IGRlZmluZWQgYnkKICAgU0RPcywgYW5kIGFueSBnYXBzIHRoYXQgc2hvdWxkIGJlIGFkZHJl c3NlZC4gIFBvaW50IHRvIGV4aXN0aW5nCiAgIGV2ZW50LCBpbmNpZGVudCBhbmQgbmV0d29yayBt YW5hZ2VtZW50IHN0YW5kYXJkcyB3aGVuIGF2YWlsYWJsZS4KICAgRGVzY3JpYmUgZW1lcmdpbmcg ZWZmb3J0cyB0aGF0IG1heSBiZSB1c2VkIGZvciB0aGUgY3JlYXRpb24gb2YgbmV3CiAgIHN0YW5k YXJkcy4gIEZvciBnYXBzIHByb3ZpZGUgaW5zaWdodCBpbnRvIHdoYXQgd291bGQgYmUgYSBnb29k IGZpdAogICBmb3IgU0FDTSBvciBhbm90aGVyIElFVEYgd29ya2luZyBncm91cHMuCgoKNy4gIElB TkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgbWVtbyBpbmNsdWRlcyBubyByZXF1ZXN0IHRvIElB TkEuCgogICBBbGwgZHJhZnRzIGFyZSByZXF1aXJlZCB0byBoYXZlIGFuIElBTkEgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiAoc2VlCiAgIHRoZSB1cGRhdGUgb2YgUkZDIDI0MzQgW0ktRC5uYXJ0ZW4t aWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzXQogICBmb3IgYSBndWlkZSkuICBJZiB0aGUg ZHJhZnQgZG9lcyBub3QgcmVxdWlyZSBJQU5BIHRvIGRvIGFueXRoaW5nLCB0aGUKICAgc2VjdGlv biBjb250YWlucyBhbiBleHBsaWNpdCBzdGF0ZW1lbnQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlIChh cwogICBhYm92ZSkuICBJZiB0aGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGZvciBJQU5BLCB0aGUg c2VjdGlvbiB3aWxsIGJlCiAgIHJlbW92ZWQgZHVyaW5nIGNvbnZlcnNpb24gaW50byBhbiBSRkMg YnkgdGhlIFJGQyBFZGl0b3IuCgoKOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBBbGwg ZHJhZnRzIGFyZSByZXF1aXJlZCB0byBoYXZlIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbi4KICAgU2VlIFJGQyAzNTUyIFtSRkMzNTUyXSBmb3IgYSBndWlkZS4KCgo5LiAgUmVmZXJl bmNlcwoKOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAg UmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtt aW5fcmVmXSAgYXV0aFN1ck5hbWUsIGF1dGhJbml0aWFscy4sICJNaW5pbWFsIFJlZmVyZW5jZSIs IDIwMDYuCgo5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELm5hcnRlbi1pYW5h LWNvbnNpZGVyYXRpb25zLXJmYzI0MzRiaXNdCiAgICAgICAgICAgICAgTmFydGVuLCBULiBhbmQg SC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4KICAgICAgICAgICAgICBJ QU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsCiAgICAgICAgICAgICAgZHJhZnQt bmFydGVuLWlhbmEtY29uc2lkZXJhdGlvbnMtcmZjMjQzNGJpcy0wOSAod29yayBpbgogICAgICAg ICAgICAgIHByb2dyZXNzKSwgTWFyY2ggMjAwOC4KCiAgIFtSRkMzNTUyXSAgUmVzY29ybGEsIEUu IGFuZCBCLiBLb3J2ZXIsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIFJGQwogICAgICAgICAgICAg IFRleHQgb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLCBCQ1AgNzIsIFJGQyAzNTUyLAogICAg ICAgICAgICAgIEp1bHkgMjAwMy4KCgoKV2FsdGVybWlyZSAgICAgICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDE2LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICBTQUNNIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEy CgoKQXBwZW5kaXggQS4gIEFkZGl0aW9uYWwgU3R1ZmYKCiAgIFRoaXMgYmVjb21lcyBhbiBBcHBl bmRpeCBpZiBuZWVkZWQuCgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgRGF2aWQgV2FsdGVybWlyZSAo ZWRpdG9yKQogICBOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5 CiAgIDEwMCBCdXJlYXUgRHJpdmUKICAgR2FpdGhlcnNidXJnLCBNYXJ5bGFuZCAgMjA4NzcKICAg VVNBCgogICBQaG9uZToKICAgRW1haWw6IGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3YKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKV2FsdGVybWlyZSAgICAgICAgICAgICAgRXhw aXJlcyBPY3RvYmVyIDE2LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICBTQUNNIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJp bCAyMDEyCgoKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJ RVRGIFRydXN0ICgyMDEyKS4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmln aHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFu ZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzCiAgIHJldGFpbiBhbGwg dGhlaXIgcmlnaHRzLgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBD T05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUwogICBPUiBJUyBT UE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUgSUVURiBUUlVT VCBBTkQKICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxM IFdBUlJBTlRJRVMsIEVYUFJFU1MKICAgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElN SVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GCiAgIFRIRSBJTkZPUk1BVElPTiBI RVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRAogICBXQVJS QU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4KCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkKCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0 aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55CiAgIEludGVsbGVjdHVh bCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0 bwogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xv Z3kgZGVzY3JpYmVkIGluCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBh bnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cwogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZh aWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMKICAgbWFkZSBhbnkgaW5k ZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9u CiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3Vt ZW50cyBjYW4gYmUKICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBDb3BpZXMgb2Yg SVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQogICBh c3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0 IG9mIGFuCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVy bWlzc2lvbiBmb3IgdGhlIHVzZSBvZgogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBs ZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5l ZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQKICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pcHIuCgogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRv IGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0 ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgcmlnaHRzIHRoYXQgbWF5 IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50CiAgIHRo aXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYg YXQKICAgaWV0Zi1pcHJAaWV0Zi5vcmcuCgoKCgoKCgoKCgoKV2FsdGVybWlyZSAgICAgICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDE2LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwK --_004_D7A0423E5E193F40BE6E94126930C4930B98F86A97MBCLUSTERxcha_-- From lnunez@c3isecurity.com Thu May 3 09:56: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 A1E3621F8600 for ; Thu, 3 May 2012 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3B1ha+wnYJR for ; Thu, 3 May 2012 09:56:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A27C21F85BD for ; Thu, 3 May 2012 09:56:41 -0700 (PDT) Received: by yhq56 with SMTP id 56so2356986yhq.31 for ; Thu, 03 May 2012 09:56:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=jOaHFS2GkbinT4bdSo4TZA8tDvgJlBD3y/JyJLiG0tc=; b=DAir+hF+j6Ruo/Ve/4AThH+n0RxGXg9aQpx+8quvrQyRmkmi4vOOHEcs1/R3CPe9Zq csNI6II1RYyA2CCn5X298EZwAJcQ9MhpbjB4CR5w1QMh+kKZT2tfGIXTb2kbF18hRL88 42gzZEAIFYFHZioo1Xj53N9RbluxkP8VExMwjl/orDg7SZWCcbrZ7Fu+iboIv+B2pDx/ /neujfYRBIxZKeFZE1ps1J7lZdE5GRLp6JMAqzxAy+5Y5ecsWMCrHmMKIJd6tD5qk4nP ooAaMDY8hqIIlGVSWeM0GakjgZQbixa3HCkYyePxdWwb77enikjBQW9cptNsDxfScSuT DFJQ== Received: by 10.236.184.202 with SMTP id s50mr3820886yhm.84.1336064200708; Thu, 03 May 2012 09:56:40 -0700 (PDT) Received: from [172.16.1.100] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id r5sm8912836ani.19.2012.05.03.09.56.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 09:56:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_06E40C8F-A2DE-4643-BF12-19FE583DA014" From: Luis Nunez In-Reply-To: Date: Thu, 3 May 2012 12:56:37 -0400 Message-Id: References: <00C069FD01E0324C9FFCADF539701DB38A6DAD@EX2K10MB1.corp.yaanatech.com> <4FA1C9B2.3000101@joval.org> To: "Waltermire, David A." X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnscRVnCfDTEgHo0BImJUZoIhu+MuK1WMdlAMDUb8sqx+4fe7mjE/PpUA6wAidFpLvZD2lg Cc: "OVAL Developer List \(Closed Public Discussion\) \(OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG\)" , David Solin , "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java 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, 03 May 2012 16:56:43 -0000 --Apple-Mail=_06E40C8F-A2DE-4643-BF12-19FE583DA014 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dave, Thanks for the update on the prototype repository. Does this effort = fall into the use case: "3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) = Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats." I see this prototype as a building block in achieving this use case. =20 What do others think. -ln On May 3, 2012, at 9:35 AM, Waltermire, David A. wrote: > Yes. We plan to provide a Java client resolver API and a command line = utility similar to DNS. We will also be seeking comments on the service = interfaces once we have some running code and documentation. > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of David Solin > Sent: Wednesday, May 02, 2012 7:57 PM > To: sacm@ietf.org > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability = Database with Java > =20 > Hi David, >=20 > Will this project include a reference client implementation? Will = your team be seeking comments on the REST and SOAP interfaces? >=20 > Regards, > --David Solin >=20 > On 5/2/2012 6:34 PM, Michael Hammer wrote: > David, > =20 > Is there any IPR associated with this? > =20 > Mike > =20 > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Waltermire, David A. > Sent: Wednesday, May 02, 2012 5:34 PM > To: OVAL Developer List (Closed Public Discussion); sacm@ietf.org > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability = Database with Java > =20 > With some of the current email discussion, I=92d like to provide a = brief update on some projects my team has been working on in this area. = We are currently working on the following activities: > =20 > 1) Prototyping a federated, generalized XML-based content = repository approach. The current effort is using a metamodel to = describe the key objects (called =93entities=94) in an XML model and the = content references (called =93relationships=94) that exist within an XML = document. We have developed a shredder that reads in an XML instance, = breaking down the entities and relationships. It then persists the XML = chunks in an XML database and the entity and relationship information in = a non-relational RDF database. We can also request the content back out = of the datastore and reconstitute it. The approach we are using does = not perturb the underlying XML infoset, so signatures can be verified = for content retrieved out of the repository. > =20 > We are currently working on web service (SOAP and REST) interfaces and = a generalized query language. Our current development phase will end in = the next couple months. We hope to have a downloadable demo available = before Security Automation Developer Days in early July that will = support requesting an SCAP datastream or a collection of OVAL/OCIL = definitions (and related components) by identifier and version. > =20 > We are avoiding the registration problem by extracting a DNS name out = of the content identifier.=20 > =20 > For example the content referenced by: > =20 > oval:org.mitre.oval:def:1 > =20 > Can be retrieved by the content server =93oval.mitre.org=94. > =20 > The plan is to use this to lookup a DNS SRV record (RFC 2782) to = locate the repository that is responsible for the content identified. = This can be used to dynamically retrieve the referenced content. We are = just starting to work out an XML format for repository-to-repository = information exchange to enable this communication. > =20 > At this point our current repository code is not far from replacing = the data backend that is used for the OVAL repository. The cool thing = about the overall approach is that no OVAL specific code is necessary. = We have created XML-based shredding rules for SCAP datastream, OVAL = 5.10.1 and XCCDF 1.2 formats. It is fairly trivial to create new = shredding rules for additional models. > =20 > You can review the code at: > =20 > http://code.google.com/p/security-automation-content-repository/ > =20 > Most of our work is being done in the SVN branch: > =20 > = http://security-automation-content-repository.googlecode.com/svn/branches/= new-shredder > =20 > The documentation is very sparse and the code needs some cleanup. We = plan to work on this in the near future. Our long-term goal is to = provide a freely available, production capable content repository server = that can participate in a federated network of content servers. > =20 > 2) We have also been working on a content repository = specification. The goal for this document is to describe the overall = federation approach and to detail the data exchange models, interfaces = and transports needed to support interoperability. I plan to have a = draft of this specification ready in September. I would be happy to = submit this as an individual submission to the IETF when it is more = complete. > =20 > My hope is that this work will address many of the communities = challenges in this area. I=92d appreciate any thoughts or feedback on = this overall approach. Please let me know if you have any questions. I = have also requested a session at the Security Automation Developer Days = hosted by MITRE in early July to review and discuss this work in greater = detail. > =20 > Sincerely, > Dave Waltermire > =20 > From: Kent Landfield [mailto:Kent_Landfield@MCAFEE.COM]=20 > Sent: Saturday, April 28, 2012 6:17 PM > To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with = Java > =20 > ;-) > =20 > As was properly pointed out to me =85there was a typo in my message=85 > =20 > "This is one of the topics I would like to see developed on the SCAM = list." > =20 > Should have been=85 > =20 > This is one of the topics I would like to see developed on the SACM = list. > =20 > ;-) > =20 > Kent Landfield > Director Content Strategy, Architecture and Standards >=20 > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 >=20 > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: , Kent Landfield > Reply-To: "OVAL Developer List (Closed Public Discussion)" = > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" = > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with = Java > =20 > This has been discussed at the last two ITSAC conference and the = Winter Developer Days last year. Discussions have been had around the = needs on the SACM list as well. This is an effort to get a standard = means for distributing SCAP related content within an organization and = as a potentially federated means of managing content developed by = guidance authors such as CIS, NIST, other government entities and = industry verticals. > =20 > Couple links to past presentations. > =20 > = http://www.google.com/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&source=3Dweb&cd=3D2= &ved=3D0CDAQFjAB&url=3Dhttp%3A%2F%2Fscap.nist.gov%2Fevents%2F2011%2Fsaddsp= %2Fpresentations%2FKent_Landfield-Automation_Content_Repositories.pdf&ei=3D= nlOcT-P7L8aWiAKGo6GTAQ&usg=3DAFQjCNHvTNEztVQmZhkisLkdcB58EpS8Sw&sig2=3DHY5= JjENzc4wMe2tVc4inAA > =20 > = http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_= Content_Repository_Demo.pdf > =20 > = http://scap.nist.gov/events/2011/itsac/presentations/day3/Landfield,%20Che= rnin,%20Basavanna%20-%20Content%20Repositories.pdf =20 > =20 > There was also a presentation that Adam Montville prepared for the = IETF SACM Side meeting. They are available in the zip file of the = presentations located in = http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html=20 > =20 > This is one of the topics I would like to see developed on the SCAM = list. > =20 > Kent Landfield > Director Content Strategy, Architecture and Standards >=20 > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 >=20 > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: David Solin > Reply-To: "OVAL Developer List (Closed Public Discussion)" = > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" = > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with = Java > =20 > We'd certainly be interested in implementing any such standard. Can = you point me to who's actively discussing it? Does MITRE intend to = support any standard approaches to repository access? >=20 > Regards, > --David >=20 > On 4/28/2012 6:56 AM, Luis Nunez wrote: > You know there is talk of producing a standard spec (sacm) to do = something like this. I know we are busy but something to think about. > =20 > It would be cool to joval be able to directly query and pull down = content directly from SecPod and other repositories in a common way. > =20 > -ln > =20 > =20 > =20 > On Apr 27, 2012, at 5:39 PM, David Solin wrote: > =20 >=20 > jOVAL provides a ready-to-use JAXB data model for the OVAL language, = various utility classes, and of course, an evaluation engine and scan = plug-ins. It does not, however, implement access to any on-line = repositories. >=20 > Feel free to contact me directly if you have any questions. >=20 > Regards, > --David Solin >=20 > -- > jOVAL.org: OVAL implemented in Java. > Scan any machine from any machine. For free! > Learn More | Features | Download >=20 >=20 > On 4/27/2012 8:48 AM, vulists wrote: > Hi There, > =20 > I'm looking for a way to access a Vulnerability Database with Java. > =20 > At the moment I'm not 100% sure if its gonna be OpenVAS or something > else, like e.g. OVAL. > =20 > I wanted to ask, if somebody knows some ready-to-use Java API to = access > "one of those" Vulnerability Databases. > =20 > If thats not the case, does it mean I have to implement my own XML > Parser to get the vulnerability data into my database? > =20 > What about standard formats? > =20 > =20 > Thanks and kind regards > =20 > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST > in the BODY of the message. If you have difficulties, write to = OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. > =20 > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. > =20 > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. > =20 >=20 > -- > jOVAL.org: OVAL implemented in Java. > Scan any machine from any machine. For free! > Learn More | Features | Download >=20 > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. > To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 >=20 > -- > jOVAL.org: OVAL implemented in Java. > Scan any machine from any machine. For free! > Learn More | Features | Download >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_06E40C8F-A2DE-4643-BF12-19FE583DA014 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Dave,
Thanks for the update on the prototype = repository.  Does this effort fall into the use = case:
 "3.4.  UC4: Secure Exchange of Governance, = Risk and Compliance = (GRC) Information

   Sharing = security and/or operationally relevant information within = and
   across trust boundaries using secure, = automated communication
   channels and = formats."

I see this prototype as a building = block in achieving this use case.  

What = do others = think.


-ln

On May 3, 2012, at 9:35 AM, Waltermire, David A. wrote:

Yes.  We plan to = provide a Java client resolver API and a command line utility similar to = DNS.  We will also be seeking comments on the service interfaces = once we have some running code and = documentation.
 
Dave
 sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of David = Solin
Sent: Wednesday, May 02, 2012 = 7:57 PM
To: sacm@ietf.org
Subject: Re: [sacm] = [OVAL-DEVELOPER-LIST] Access Vulnerability Database with = Java
Hi David,

Will = this project include a reference client implementation?  Will your = team be seeking comments on the REST and SOAP = interfaces?

Regards,
--David Solin

On 5/2/2012 6:34 PM, = Michael Hammer wrote:
David,
Is there any IPR associated with = this?
 
 
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David = A.
Sent: Wednesday, May 02, 2012 = 5:34 PM
To: OVAL Developer List (Closed = Public Discussion); sacm@ietf.org
Subject: Re: [sacm] = [OVAL-DEVELOPER-LIST] Access Vulnerability Database with = Java
With some of the current email discussion, I=92d = like to provide a brief update on some projects my team has been working = on in this area.  We are currently working on the following = activities:
 
1) Prototyping a federated, generalized XML-based = content repository approach.  The current effort is using a = metamodel to describe the key objects (called =93entities=94) in an XML = model and the content references (called =93relationships=94) that exist = within an XML document.  We have developed a shredder that reads in = an XML instance, breaking down the entities and relationships.  It = then persists the XML chunks in an XML database and the entity and = relationship information in a non-relational RDF database.  We can = also request the content back out of the datastore and reconstitute = it.  The approach we are using does not perturb the underlying XML = infoset, so signatures can be verified for content retrieved out of the = repository.
 
We are currently working = on web service (SOAP and REST) interfaces and a generalized query = language.  Our current development phase will end in the next = couple months.  We hope to have a downloadable demo available = before Security Automation Developer Days in early July that will = support requesting an SCAP datastream or a collection of OVAL/OCIL = definitions (and related components) by identifier and = version.
 
We are avoiding the = registration problem by extracting a DNS name out of the content = identifier. 
 
For example the content = referenced by:
 
Can be retrieved by the content server = =93oval.mitre.org=94.
 
The plan is to use this = to lookup a DNS SRV record (RFC 2782) to locate the repository = that is responsible for the content identified.  This can be used = to dynamically retrieve the referenced content.  We are just = starting to work out an XML format for repository-to-repository = information exchange to enable this = communication.
 
At this point our = current repository code is not far from replacing the data backend that = is used for the OVAL repository.  The cool thing about the overall = approach is that no OVAL specific code is necessary.  We have = created XML-based shredding rules for SCAP datastream, OVAL 5.10.1 and = XCCDF 1.2 formats.  It is fairly trivial to create new shredding = rules for additional models.
You can review the code = at:
 
<= div>
 
;-)
 

 

jOVAL provides a ready-to-use = JAXB data model for the OVAL language, various utility classes, and of = course, an evaluation engine and scan plug-ins.  It does not, = however, implement access to any on-line repositories.

Feel free = to contact me directly if you have any = questions.

Regards,
--David Solin

jOVAL.org: OVAL implemented in Java.
Scan any = machine from any machine. For free!
Learn = More |  | 
On 4/27/2012 8:48 AM, vulists = wrote:

Hi There,
 
I'm looking for a way =
to access a Vulnerability Database with Java.
 
At the moment I'm not =
100% sure if its gonna be OpenVAS or something
else, like e.g. OVAL.
 
I wanted to ask, if =
somebody knows some ready-to-use Java API to access
"one of those" Vulnerability =
Databases.
 
If thats not the case, does it mean I have to implement =
my own XML
Parser to get the =
vulnerability data into my database?
 
What about standard =
formats?
 
 
Thanks and kind =
regards
 
To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG =
with
SIGNOFF =
OVAL-DEVELOPER-LIST
in the BODY of the =
message.  If you have difficulties, write to  
To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to  
To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to  

--

jOVAL.org: OVAL implemented in = Java.
Scan any machine from any machine. For free!
Learn More |  | To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to To unsubscribe, send an = email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to To unsubscribe, send an = email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to 


sacm mailing list
sacm@ietf.org
 
--
jOVAL.org: OVAL implemented in =
Java.
Scan any machine from any machine. For free!
Learn More |  | sacm@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/sacm

= --Apple-Mail=_06E40C8F-A2DE-4643-BF12-19FE583DA014-- From david.waltermire@nist.gov Thu May 3 10:53: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 E36B621F85C4 for ; Thu, 3 May 2012 10:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFmkmttwF1xR for ; Thu, 3 May 2012 10:53:05 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A2DC421F8646 for ; Thu, 3 May 2012 10:53:04 -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.355.2; Thu, 3 May 2012 13:52:56 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 3 May 2012 13:53:03 -0400 From: "Waltermire, David A." To: Luis Nunez Date: Thu, 3 May 2012 13:53:02 -0400 Thread-Topic: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Thread-Index: Ac0pTalyejPo94aeR+uj5+rgrnkq2wAAChkw Message-ID: References: <00C069FD01E0324C9FFCADF539701DB38A6DAD@EX2K10MB1.corp.yaanatech.com> <4FA1C9B2.3000101@joval.org> 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_D7A0423E5E193F40BE6E94126930C4930B98F86BA8MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "OVAL Developer List \(Closed Public Discussion\) \(OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG\)" , David Solin , "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java 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, 03 May 2012 17:53:13 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B98F86BA8MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Yes. It can store and exchange any XML based information. Our approach works well for querying information that changes fairly infrequently and has associated persistent identifiers (e.g. security automation content). For more dynamic information like reports, the methodology used by the content repository might not be well suited. I see content repositories less as a silver bullet for this use case, but more as another tool in our tool belt for dealing with this use case. Sincerely, Dave From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, May 03, 2012 12:57 PM To: Waltermire, David A. Cc: David Solin; sacm@ietf.org; OVAL Developer List (Closed Public Discussion) (OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG) Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Hi Dave, Thanks for the update on the prototype repository. Does this effort fall into the use case: "3.4. UC4: Secure Exchange of Governance, Risk and Compliance (GRC) Information Sharing security and/or operationally relevant information within and across trust boundaries using secure, automated communication channels and formats." I see this prototype as a building block in achieving this use case. What do others think. -ln On May 3, 2012, at 9:35 AM, Waltermire, David A. wrote: Yes. We plan to provide a Java client resolver API and a command line utility similar to DNS. We will also be seeking comments on the service interfaces once we have some running code and documentation. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Solin Sent: Wednesday, May 02, 2012 7:57 PM To: sacm@ietf.org Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java Hi David, Will this project include a reference client implementation? Will your team be seeking comments on the REST and SOAP interfaces? Regards, --David Solin On 5/2/2012 6:34 PM, Michael Hammer wrote: David, Is there any IPR associated with this? Mike From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, May 02, 2012 5:34 PM To: OVAL Developer List (Closed Public Discussion); sacm@ietf.org Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java With some of the current email discussion, I'd like to provide a brief update on some projects my team has been working on in this area. We are currently working on the following activities: 1) Prototyping a federated, generalized XML-based content repository approach. The current effort is using a metamodel to describe the key objects (called "entities") in an XML model and the content references (called "relationships") that exist within an XML document. We have developed a shredder that reads in an XML instance, breaking down the entities and relationships. It then persists the XML chunks in an XML database and the entity and relationship information in a non-relational RDF database. We can also request the content back out of the datastore and reconstitute it. The approach we are using does not perturb the underlying XML infoset, so signatures can be verified for content retrieved out of the repository. We are currently working on web service (SOAP and REST) interfaces and a generalized query language. Our current development phase will end in the next couple months. We hope to have a downloadable demo available before Security Automation Developer Days in early July that will support requesting an SCAP datastream or a collection of OVAL/OCIL definitions (and related components) by identifier and version. We are avoiding the registration problem by extracting a DNS name out of the content identifier. For example the content referenced by: oval:org.mitre.oval:def:1 Can be retrieved by the content server "oval.mitre.org". The plan is to use this to lookup a DNS SRV record (RFC 2782) to locate the repository that is responsible for the content identified. This can be used to dynamically retrieve the referenced content. We are just starting to work out an XML format for repository-to-repository information exchange to enable this communication. At this point our current repository code is not far from replacing the data backend that is used for the OVAL repository. The cool thing about the overall approach is that no OVAL specific code is necessary. We have created XML-based shredding rules for SCAP datastream, OVAL 5.10.1 and XCCDF 1.2 formats. It is fairly trivial to create new shredding rules for additional models. You can review the code at: http://code.google.com/p/security-automation-content-repository/ Most of our work is being done in the SVN branch: http://security-automation-content-repository.googlecode.com/svn/branches/new-shredder The documentation is very sparse and the code needs some cleanup. We plan to work on this in the near future. Our long-term goal is to provide a freely available, production capable content repository server that can participate in a federated network of content servers. 2) We have also been working on a content repository specification. The goal for this document is to describe the overall federation approach and to detail the data exchange models, interfaces and transports needed to support interoperability. I plan to have a draft of this specification ready in September. I would be happy to submit this as an individual submission to the IETF when it is more complete. My hope is that this work will address many of the communities challenges in this area. I'd appreciate any thoughts or feedback on this overall approach. Please let me know if you have any questions. I have also requested a session at the Security Automation Developer Days hosted by MITRE in early July to review and discuss this work in greater detail. Sincerely, Dave Waltermire From: Kent Landfield [mailto:Kent_Landfield@MCAFEE.COM] Sent: Saturday, April 28, 2012 6:17 PM To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java ;-) As was properly pointed out to me ...there was a typo in my message... "This is one of the topics I would like to see developed on the SCAM list." Should have been... This is one of the topics I would like to see developed on the SACM list. ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java This has been discussed at the last two ITSAC conference and the Winter Developer Days last year. Discussions have been had around the needs on the SACM list as well. This is an effort to get a standard means for distributing SCAP related content within an organization and as a potentially federated means of managing content developed by guidance authors such as CIS, NIST, other government entities and industry verticals. Couple links to past presentations. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDAQFjAB&url=http%3A%2F%2Fscap.nist.gov%2Fevents%2F2011%2Fsaddsp%2Fpresentations%2FKent_Landfield-Automation_Content_Repositories.pdf&ei=nlOcT-P7L8aWiAKGo6GTAQ&usg=AFQjCNHvTNEztVQmZhkisLkdcB58EpS8Sw&sig2=HY5JjENzc4wMe2tVc4inAA http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf http://scap.nist.gov/events/2011/itsac/presentations/day3/Landfield,%20Chernin,%20Basavanna%20-%20Content%20Repositories.pdf There was also a presentation that Adam Montville prepared for the IETF SACM Side meeting. They are available in the zip file of the presentations located in http://www.ietf.org/mail-archive/web/sacm/current/msg00178.html This is one of the topics I would like to see developed on the SCAM list. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: David Solin > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Access Vulnerability Database with Java We'd certainly be interested in implementing any such standard. Can you point me to who's actively discussing it? Does MITRE intend to support any standard approaches to repository access? Regards, --David On 4/28/2012 6:56 AM, Luis Nunez wrote: You know there is talk of producing a standard spec (sacm) to do something like this. I know we are busy but something to think about. It would be cool to joval be able to directly query and pull down content directly from SecPod and other repositories in a common way. -ln On Apr 27, 2012, at 5:39 PM, David Solin wrote: jOVAL provides a ready-to-use JAXB data model for the OVAL language, various utility classes, and of course, an evaluation engine and scan plug-ins. It does not, however, implement access to any on-line repositories. Feel free to contact me directly if you have any questions. Regards, --David Solin -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download On 4/27/2012 8:48 AM, vulists wrote: Hi There, I'm looking for a way to access a Vulnerability Database with Java. At the moment I'm not 100% sure if its gonna be OpenVAS or something else, like e.g. OVAL. I wanted to ask, if somebody knows some ready-to-use Java API to access "one of those" Vulnerability Databases. If thats not the case, does it mean I have to implement my own XML Parser to get the vulnerability data into my database? What about standard formats? Thanks and kind regards To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_D7A0423E5E193F40BE6E94126930C4930B98F86BA8MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1t c2c6Ly8zMDk2LyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFw cGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxl LXNwYW47fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFk Pjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRT ZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5ZZXMuJm5i c3A7IEl0IGNhbiBzdG9yZSBhbmQgZXhjaGFuZ2UgYW55IFhNTCBiYXNlZCBpbmZvcm1hdGlvbi4m bmJzcDsgT3VyIGFwcHJvYWNoIHdvcmtzIHdlbGwgZm9yIHF1ZXJ5aW5nIGluZm9ybWF0aW9uIHRo YXQgY2hhbmdlcyBmYWlybHkgaW5mcmVxdWVudGx5IGFuZCBoYXMgYXNzb2NpYXRlZCBwZXJzaXN0 ZW50IGlkZW50aWZpZXJzIChlLmcuIHNlY3VyaXR5IGF1dG9tYXRpb24gY29udGVudCkuJm5ic3A7 IEZvciBtb3JlIGR5bmFtaWMgaW5mb3JtYXRpb24gbGlrZSByZXBvcnRzLCB0aGUgbWV0aG9kb2xv Z3kgdXNlZCBieSB0aGUgY29udGVudCByZXBvc2l0b3J5IG1pZ2h0IG5vdCBiZSB3ZWxsIHN1aXRl ZC4gJm5ic3A7SSBzZWUgY29udGVudCByZXBvc2l0b3JpZXMgbGVzcyBhcyBhIHNpbHZlciBidWxs ZXQgZm9yIHRoaXMgdXNlIGNhc2UsIGJ1dCBtb3JlIGFzIGFub3RoZXIgdG9vbCBpbiBvdXIgdG9v bCBiZWx0IGZvciBkZWFsaW5nIHdpdGggdGhpcyB1c2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+U2luY2VyZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gTHVpcyBOdW5leiBbbWFpbHRv OmxudW5lekBjM2lzZWN1cml0eS5jb21dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAw MywgMjAxMiAxMjo1NyBQTTxicj48Yj5Ubzo8L2I+IFdhbHRlcm1pcmUsIERhdmlkIEEuPGJyPjxi PkNjOjwvYj4gRGF2aWQgU29saW47IHNhY21AaWV0Zi5vcmc7IE9WQUwgRGV2ZWxvcGVyIExpc3Qg KENsb3NlZCBQdWJsaWMgRGlzY3Vzc2lvbikgKE9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlU UkUuT1JHKTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBbT1ZBTC1ERVZFTE9QRVItTElT VF0gQWNjZXNzIFZ1bG5lcmFiaWxpdHkgRGF0YWJhc2Ugd2l0aCBKYXZhPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+SGkgRGF2ZSw8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5UaGFua3MgZm9yIHRoZSB1cGRhdGUgb24gdGhlIHByb3RvdHlwZSByZXBvc2l0 b3J5LiAmbmJzcDtEb2VzIHRoaXMgZWZmb3J0IGZhbGwgaW50byB0aGUgdXNlIGNhc2U6PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7JnF1b3Q7My40LiAm bmJzcDtVQzQ6IFNlY3VyZSBFeGNoYW5nZSBvZiBHb3Zlcm5hbmNlLCBSaXNrIGFuZCBDb21wbGlh bmNlIChHUkMpJm5ic3A7SW5mb3JtYXRpb248bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD4mbmJzcDsgJm5ic3A7U2hhcmluZyBzZWN1cml0eSBhbmQvb3Igb3BlcmF0aW9uYWxs eSByZWxldmFudCBpbmZvcm1hdGlvbiB3aXRoaW4gYW5kPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7ICZuYnNwO2Fjcm9zcyB0cnVzdCBib3VuZGFyaWVz IHVzaW5nIHNlY3VyZSwgYXV0b21hdGVkIGNvbW11bmljYXRpb248bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsgJm5ic3A7Y2hhbm5lbHMgYW5kIGZvcm1h dHMuJnF1b3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBzZWUgdGhp cyBwcm90b3R5cGUgYXMgYSBidWlsZGluZyBibG9jayBpbiBhY2hpZXZpbmcgdGhpcyB1c2UgY2Fz ZS4gJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2hhdCBkbyBv dGhlcnMgdGhpbmsuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LWxuPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBNYXkgMywgMjAxMiwgYXQgOTozNSBBTSwg V2FsdGVybWlyZSwgRGF2aWQgQS4gd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj48YnI+PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlllcy4mbmJzcDsgV2UgcGxhbiB0byBwcm92aWRl IGEgSmF2YSBjbGllbnQgcmVzb2x2ZXIgQVBJIGFuZCBhIGNvbW1hbmQgbGluZSB1dGlsaXR5IHNp bWlsYXIgdG8gRE5TLiZuYnNwOyBXZSB3aWxsIGFsc28gYmUgc2Vla2luZyBjb21tZW50cyBvbiB0 aGUgc2VydmljZSBpbnRlcmZhY2VzIG9uY2Ugd2UgaGF2ZSBzb21lIHJ1bm5pbmcgY29kZSBhbmQg ZG9jdW1lbnRhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlNpbmNlcmVseSw8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5EYXZlPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW47Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwnPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPWFwcGxl LWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz48YSBo cmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10iPlttYWls dG86c2FjbS1ib3VuY2VzQGlldGYub3JnXTwvYT48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt c3BhY2U+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZl cnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9iPkRhdmlkIFNvbGluPGJyPjxiPlNlbnQ6PC9iPjxz cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5LCBN YXkgMDIsIDIwMTIgNzo1NyBQTTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2Fj bUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5SZTogW3NhY21dIFtPVkFMLURFVkVMT1BFUi1MSVNUXSBB Y2Nlc3MgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3aXRoIEphdmE8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5IaSBEYXZpZCw8YnI+PGJyPldpbGwgdGhpcyBwcm9qZWN0IGluY2x1 ZGUgYSByZWZlcmVuY2UgY2xpZW50IGltcGxlbWVudGF0aW9uPyZuYnNwOyBXaWxsIHlvdXIgdGVh bSBiZSBzZWVraW5nIGNvbW1lbnRzIG9uIHRoZSBSRVNUIGFuZCBTT0FQIGludGVyZmFjZXM/PGJy Pjxicj5SZWdhcmRzLDxicj4tLURhdmlkIFNvbGluPGJyPjxicj5PbiA1LzIvMjAxMiA2OjM0IFBN LCBNaWNoYWVsIEhhbW1lciB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZpZCw8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JcyB0aGVyZSBhbnkgSVBS IGFzc29jaWF0ZWQgd2l0aCB0aGlzPzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPk1pa2U8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3Jk ZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29sb3I6aW5pdGlhbCc+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9 YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0 Zi5vcmciPnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPls8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPWFw cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9iPldhbHRlcm1pcmUsIERhdmlkIEEu PGJyPjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8 L3NwYW4+V2VkbmVzZGF5LCBNYXkgMDIsIDIwMTIgNTozNCBQTTxicj48Yj5Ubzo8L2I+PHNwYW4g Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5PVkFMIERldmVsb3BlciBM aXN0IChDbG9zZWQgUHVibGljIERpc2N1c3Npb24pOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21A aWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+UmU6IFtzYWNtXSBbT1ZBTC1ERVZFTE9QRVItTElTVF0gQWNj ZXNzIFZ1bG5lcmFiaWxpdHkgRGF0YWJhc2Ugd2l0aCBKYXZhPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+V2l0aCBzb21lIG9mIHRoZSBjdXJyZW50IGVtYWlsIGRpc2N1c3Npb24sIEkm IzgyMTc7ZCBsaWtlIHRvIHByb3ZpZGUgYSBicmllZiB1cGRhdGUgb24gc29tZSBwcm9qZWN0cyBt eSB0ZWFtIGhhcyBiZWVuIHdvcmtpbmcgb24gaW4gdGhpcyBhcmVhLiZuYnNwOyBXZSBhcmUgY3Vy cmVudGx5IHdvcmtpbmcgb24gdGhlIGZvbGxvd2luZyBhY3Rpdml0aWVzOjwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50 Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4xKTwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlByb3RvdHlwaW5nIGEgZmVkZXJhdGVkLCBnZW5lcmFsaXplZCBYTUwt YmFzZWQgY29udGVudCByZXBvc2l0b3J5IGFwcHJvYWNoLiZuYnNwOyBUaGUgY3VycmVudCBlZmZv cnQgaXMgdXNpbmcgYSBtZXRhbW9kZWwgdG8gZGVzY3JpYmUgdGhlIGtleSBvYmplY3RzIChjYWxs ZWQgJiM4MjIwO2VudGl0aWVzJiM4MjIxOykgaW4gYW4gWE1MIG1vZGVsIGFuZCB0aGUgY29udGVu dCByZWZlcmVuY2VzIChjYWxsZWQgJiM4MjIwO3JlbGF0aW9uc2hpcHMmIzgyMjE7KSB0aGF0IGV4 aXN0IHdpdGhpbiBhbiBYTUwgZG9jdW1lbnQuJm5ic3A7IFdlIGhhdmUgZGV2ZWxvcGVkIGEgc2hy ZWRkZXIgdGhhdCByZWFkcyBpbiBhbiBYTUwgaW5zdGFuY2UsIGJyZWFraW5nIGRvd24gdGhlIGVu dGl0aWVzIGFuZCByZWxhdGlvbnNoaXBzLiZuYnNwOyBJdCB0aGVuIHBlcnNpc3RzIHRoZSBYTUwg Y2h1bmtzIGluIGFuIFhNTCBkYXRhYmFzZSBhbmQgdGhlIGVudGl0eSBhbmQgcmVsYXRpb25zaGlw IGluZm9ybWF0aW9uIGluIGEgbm9uLXJlbGF0aW9uYWwgUkRGIGRhdGFiYXNlLiZuYnNwOyBXZSBj YW4gYWxzbyByZXF1ZXN0IHRoZSBjb250ZW50IGJhY2sgb3V0IG9mIHRoZSBkYXRhc3RvcmUgYW5k IHJlY29uc3RpdHV0ZSBpdC4mbmJzcDsgVGhlIGFwcHJvYWNoIHdlIGFyZSB1c2luZyBkb2VzIG5v dCBwZXJ0dXJiIHRoZSB1bmRlcmx5aW5nIFhNTCBpbmZvc2V0LCBzbyBzaWduYXR1cmVzIGNhbiBi ZSB2ZXJpZmllZCBmb3IgY29udGVudCByZXRyaWV2ZWQgb3V0IG9mIHRoZSByZXBvc2l0b3J5Ljwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgYXJlIGN1cnJlbnRs eSB3b3JraW5nIG9uIHdlYiBzZXJ2aWNlIChTT0FQIGFuZCBSRVNUKSBpbnRlcmZhY2VzIGFuZCBh IGdlbmVyYWxpemVkIHF1ZXJ5IGxhbmd1YWdlLiZuYnNwOyBPdXIgY3VycmVudCBkZXZlbG9wbWVu dCBwaGFzZSB3aWxsIGVuZCBpbiB0aGUgbmV4dCBjb3VwbGUgbW9udGhzLiZuYnNwOyBXZSBob3Bl IHRvIGhhdmUgYSBkb3dubG9hZGFibGUgZGVtbyBhdmFpbGFibGUgYmVmb3JlIFNlY3VyaXR5IEF1 dG9tYXRpb24gRGV2ZWxvcGVyIERheXMgaW4gZWFybHkgSnVseSB0aGF0IHdpbGwgc3VwcG9ydCBy ZXF1ZXN0aW5nIGFuIFNDQVAgZGF0YXN0cmVhbSBvciBhIGNvbGxlY3Rpb24gb2YgT1ZBTC9PQ0lM IGRlZmluaXRpb25zIChhbmQgcmVsYXRlZCBjb21wb25lbnRzKSBieSBpZGVudGlmaWVyIGFuZCB2 ZXJzaW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgYXJl IGF2b2lkaW5nIHRoZSByZWdpc3RyYXRpb24gcHJvYmxlbSBieSBleHRyYWN0aW5nIGEgRE5TIG5h bWUgb3V0IG9mIHRoZSBjb250ZW50IGlkZW50aWZpZXIuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Gb3IgZXhhbXBsZSB0aGUgY29udGVudCByZWZlcmVu Y2VkIGJ5Ojwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+b3ZhbDpv cmcubWl0cmUub3ZhbDpkZWY6MTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHls ZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Q2FuIGJlIHJldHJpZXZlZCBieSB0aGUgY29udGVudCBzZXJ2ZXIgJiM4MjIwO292YWwu bWl0cmUub3JnJiM4MjIxOy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPlRoZSBwbGFuIGlzIHRvIHVzZSB0aGlzIHRvIGxvb2t1cCBhIEROUyBTUlYgcmVjb3JkICg8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmMyNzgyLnR4dCI+UkZDIDI3ODI8L2E+ KSB0byBsb2NhdGUgdGhlIHJlcG9zaXRvcnkgdGhhdCBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGNv bnRlbnQgaWRlbnRpZmllZC4mbmJzcDsgVGhpcyBjYW4gYmUgdXNlZCB0byBkeW5hbWljYWxseSBy ZXRyaWV2ZSB0aGUgcmVmZXJlbmNlZCBjb250ZW50LiZuYnNwOyBXZSBhcmUganVzdCBzdGFydGlu ZyB0byB3b3JrIG91dCBhbiBYTUwgZm9ybWF0IGZvciByZXBvc2l0b3J5LXRvLXJlcG9zaXRvcnkg aW5mb3JtYXRpb24gZXhjaGFuZ2UgdG8gZW5hYmxlIHRoaXMgY29tbXVuaWNhdGlvbi48L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp diBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkF0IHRoaXMgcG9pbnQgb3VyIGN1 cnJlbnQgcmVwb3NpdG9yeSBjb2RlIGlzIG5vdCBmYXIgZnJvbSByZXBsYWNpbmcgdGhlIGRhdGEg YmFja2VuZCB0aGF0IGlzIHVzZWQgZm9yIHRoZSBPVkFMIHJlcG9zaXRvcnkuJm5ic3A7IFRoZSBj b29sIHRoaW5nIGFib3V0IHRoZSBvdmVyYWxsIGFwcHJvYWNoIGlzIHRoYXQgbm8gT1ZBTCBzcGVj aWZpYyBjb2RlIGlzIG5lY2Vzc2FyeS4mbmJzcDsgV2UgaGF2ZSBjcmVhdGVkIFhNTC1iYXNlZCBz aHJlZGRpbmcgcnVsZXMgZm9yIFNDQVAgZGF0YXN0cmVhbSwgT1ZBTCA1LjEwLjEgYW5kIFhDQ0RG IDEuMiBmb3JtYXRzLiAmbmJzcDtJdCBpcyBmYWlybHkgdHJpdmlhbCB0byBjcmVhdGUgbmV3IHNo cmVkZGluZyBydWxlcyBmb3IgYWRkaXRpb25hbCBtb2RlbHMuPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdp bi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Zb3UgY2FuIHJldmlldyB0aGUgY29kZSBhdDo8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp diBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9jb2Rl Lmdvb2dsZS5jb20vcC9zZWN1cml0eS1hdXRvbWF0aW9uLWNvbnRlbnQtcmVwb3NpdG9yeS8iPmh0 dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9zZWN1cml0eS1hdXRvbWF0aW9uLWNvbnRlbnQtcmVwb3Np dG9yeS88L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Nb3N0 IG9mIG91ciB3b3JrIGlzIGJlaW5nIGRvbmUgaW4gdGhlIFNWTiBicmFuY2g6PC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vc2VjdXJpdHkt YXV0b21hdGlvbi1jb250ZW50LXJlcG9zaXRvcnkuZ29vZ2xlY29kZS5jb20vc3ZuL2JyYW5jaGVz L25ldy1zaHJlZGRlciI+aHR0cDovL3NlY3VyaXR5LWF1dG9tYXRpb24tY29udGVudC1yZXBvc2l0 b3J5Lmdvb2dsZWNvZGUuY29tL3N2bi9icmFuY2hlcy9uZXctc2hyZWRkZXI8L2E+PC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgZG9jdW1lbnRhdGlvbiBpcyB2 ZXJ5IHNwYXJzZSBhbmQgdGhlIGNvZGUgbmVlZHMgc29tZSBjbGVhbnVwLiZuYnNwOyBXZSBwbGFu IHRvIHdvcmsgb24gdGhpcyBpbiB0aGUgbmVhciBmdXR1cmUuJm5ic3A7IE91ciBsb25nLXRlcm0g Z29hbCBpcyB0byBwcm92aWRlIGEgZnJlZWx5IGF2YWlsYWJsZSwgcHJvZHVjdGlvbiBjYXBhYmxl IGNvbnRlbnQgcmVwb3NpdG9yeSBzZXJ2ZXIgdGhhdCBjYW4gcGFydGljaXBhdGUgaW4gYSBmZWRl cmF0ZWQgbmV0d29yayBvZiBjb250ZW50IHNlcnZlcnMuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4yKTwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldlIGhhdmUgYWxzbyBiZWVuIHdvcmtpbmcg b24gYSBjb250ZW50IHJlcG9zaXRvcnkgc3BlY2lmaWNhdGlvbi4mbmJzcDsgVGhlIGdvYWwgZm9y IHRoaXMgZG9jdW1lbnQgaXMgdG8gZGVzY3JpYmUgdGhlIG92ZXJhbGwgZmVkZXJhdGlvbiBhcHBy b2FjaCBhbmQgdG8gZGV0YWlsIHRoZSBkYXRhIGV4Y2hhbmdlIG1vZGVscywgaW50ZXJmYWNlcyBh bmQgdHJhbnNwb3J0cyBuZWVkZWQgdG8gc3VwcG9ydCBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBJ IHBsYW4gdG8gaGF2ZSBhIGRyYWZ0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiByZWFkeSBpbiBTZXB0 ZW1iZXIuJm5ic3A7IEkgd291bGQgYmUgaGFwcHkgdG8gc3VibWl0IHRoaXMgYXMgYW4gaW5kaXZp ZHVhbCBzdWJtaXNzaW9uIHRvIHRoZSBJRVRGIHdoZW4gaXQgaXMgbW9yZSBjb21wbGV0ZS48L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NeSBob3BlIGlz IHRoYXQgdGhpcyB3b3JrIHdpbGwgYWRkcmVzcyBtYW55IG9mIHRoZSBjb21tdW5pdGllcyBjaGFs bGVuZ2VzIGluIHRoaXMgYXJlYS4mbmJzcDsgSSYjODIxNztkIGFwcHJlY2lhdGUgYW55IHRob3Vn aHRzIG9yIGZlZWRiYWNrIG9uIHRoaXMgb3ZlcmFsbCBhcHByb2FjaC4mbmJzcDsgUGxlYXNlIGxl dCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMuJm5ic3A7IEkgaGF2ZSBhbHNvIHJl cXVlc3RlZCBhIHNlc3Npb24gYXQgdGhlIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERh eXMgaG9zdGVkIGJ5IE1JVFJFIGluIGVhcmx5IEp1bHkgdG8gcmV2aWV3IGFuZCBkaXNjdXNzIHRo aXMgd29yayBpbiBncmVhdGVyIGRldGFpbC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNpbmNlcmVseSw8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZlIFdhbHRlcm1pcmU8L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29s b3I6aW5pdGlhbCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPktl bnQgTGFuZGZpZWxkPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86W21haWx0bzpLZW50X0xhbmRmaWVsZEBNQ0FGRUUuQ09NXSI+W21h aWx0bzpLZW50X0xhbmRmaWVsZEBNQ0FGRUUuQ09NXTwvYT48c3BhbiBjbGFzcz1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj48Yj5TZW50OjwvYj48c3BhbiBjbGFzcz1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPlNhdHVyZGF5LCBBcHJpbCAyOCwgMjAxMiA2 OjE3IFBNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJF Lk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8L2E+PGJyPjxiPlN1Ympl Y3Q6PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+UmU6 IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBBY2Nlc3MgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3aXRo IEphdmE8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz47 LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+QXMgd2FzIHByb3Blcmx5IHBvaW50ZWQgb3V0IHRvIG1lICYjODIzMDt0 aGVyZSB3YXMgYSB0eXBvIGluIG15IG1lc3NhZ2UmIzgyMzA7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZxdW90O1Ro aXMgaXMgb25lIG9mIHRoZSB0b3BpY3MgSSB3b3VsZCBsaWtlIHRvIHNlZSBkZXZlbG9wZWQgb24g dGhlIFNDQU0gbGlzdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U2hvdWxkIGhhdmUgYmVlbiYjODIzMDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+VGhpcyBpcyBvbmUgb2YgdGhlIHRvcGljcyBJIHdvdWxkIGxpa2UgdG8gc2Vl IGRldmVsb3BlZCBvbiB0aGU8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7 PC9zcGFuPjxiPlNBQ008L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj5saXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz47LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPktlbnQgTGFu ZGZpZWxkPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJyPjxzcGFuIGNsYXNz PWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJl IGFuZCBTdGFuZGFyZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwvc3Bh bj48L3N0cm9uZz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41MDAwIEhlYWRxdWFy dGVycyBEci48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+UGxhbm8sIFRl eGFzIDc1MDI0PC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJl Y3Q6ICsxLjk3Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5 bGUtc3Bhbj5Nb2JpbGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8L3NwYW4+ PC9zdHJvbmc+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3 Lm1jYWZlZS5jb20vIj53d3cubWNhZmVlLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW47Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwn PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PHNw YW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPiZsdDtMYW5kZmllbGQmZ3Q7LCBLZW50IExhbmRmaWVsZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb20iPktlbnRfTGFuZGZpZWxk QE1jQWZlZS5jb208L2E+Jmd0Ozxicj48Yj5SZXBseS1Ubzo8c3BhbiBjbGFzcz1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvYj4mcXVvdDtPVkFMIERldmVsb3BlciBMaXN0IChD bG9zZWQgUHVibGljIERpc2N1c3Npb24pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86T1ZBTC1E RVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMu TUlUUkUuT1JHPC9hPiZndDs8YnI+PGI+VG86PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNw YWNlPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVS LUxJU1RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9S RzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RT Lk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8L2E+Jmd0Ozxi cj48Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3Nw YW4+PC9iPlJlOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gQWNjZXNzIFZ1bG5lcmFiaWxpdHkgRGF0 YWJhc2Ugd2l0aCBKYXZhPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNC NUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9y ZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwnIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGlzIGhhcyBiZWVuIGRp c2N1c3NlZCBhdCB0aGUgbGFzdCB0d28gSVRTQUMgY29uZmVyZW5jZSBhbmQgdGhlIFdpbnRlciBE ZXZlbG9wZXIgRGF5cyBsYXN0IHllYXIuICZuYnNwO0Rpc2N1c3Npb25zIGhhdmUgYmVlbiBoYWQg YXJvdW5kIHRoZSBuZWVkcyBvbiB0aGUgU0FDTSBsaXN0IGFzIHdlbGwuICZuYnNwOyBUaGlzIGlz IGFuIGVmZm9ydCB0byBnZXQgYSBzdGFuZGFyZCBtZWFucyBmb3IgZGlzdHJpYnV0aW5nIFNDQVAg cmVsYXRlZCBjb250ZW50IHdpdGhpbiBhbiBvcmdhbml6YXRpb24gYW5kIGFzIGEgcG90ZW50aWFs bHkgZmVkZXJhdGVkIG1lYW5zIG9mIG1hbmFnaW5nIGNvbnRlbnQgZGV2ZWxvcGVkIGJ5IGd1aWRh bmNlIGF1dGhvcnMgc3VjaCBhcyBDSVMsIE5JU1QsIG90aGVyIGdvdmVybm1lbnQgZW50aXRpZXMg YW5kIGluZHVzdHJ5IHZlcnRpY2Fscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Q291cGxlIGxpbmtzIHRvIHBhc3Qg cHJlc2VudGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGEgaHJlZj0iaHR0cDovL3d3dy5nb29nbGUuY29t L3VybD9zYT10JmFtcDtyY3Q9aiZhbXA7cT0mYW1wO2VzcmM9cyZhbXA7c291cmNlPXdlYiZhbXA7 Y2Q9MiZhbXA7dmVkPTBDREFRRmpBQiZhbXA7dXJsPWh0dHAlM0ElMkYlMkZzY2FwLm5pc3QuZ292 JTJGZXZlbnRzJTJGMjAxMSUyRnNhZGRzcCUyRnByZXNlbnRhdGlvbnMlMkZLZW50X0xhbmRmaWVs ZC1BdXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yaWVzLnBkZiZhbXA7ZWk9bmxPY1QtUDdMOGFX aUFLR282R1RBUSZhbXA7dXNnPUFGUWpDTkh2VE5FenRWUW1aaGtpc0xrZGNCNThFcFM4U3cmYW1w O3NpZzI9SFk1SmpFTnpjNHdNZTJ0VmM0aW5BQSI+aHR0cDovL3d3dy5nb29nbGUuY29tL3VybD9z YT10JmFtcDtyY3Q9aiZhbXA7cT0mYW1wO2VzcmM9cyZhbXA7c291cmNlPXdlYiZhbXA7Y2Q9MiZh bXA7dmVkPTBDREFRRmpBQiZhbXA7dXJsPWh0dHAlM0ElMkYlMkZzY2FwLm5pc3QuZ292JTJGZXZl bnRzJTJGMjAxMSUyRnNhZGRzcCUyRnByZXNlbnRhdGlvbnMlMkZLZW50X0xhbmRmaWVsZC1BdXRv bWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yaWVzLnBkZiZhbXA7ZWk9bmxPY1QtUDdMOGFXaUFLR282 R1RBUSZhbXA7dXNnPUFGUWpDTkh2VE5FenRWUW1aaGtpc0xrZGNCNThFcFM4U3cmYW1wO3NpZzI9 SFk1SmpFTnpjNHdNZTJ0VmM0aW5BQTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48YSBocmVmPSJodHRwOi8vc2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9zYWRkc3Av cHJlc2VudGF0aW9ucy9TZWN1cml0eV9BdXRvbWF0aW9uX0NvbnRlbnRfUmVwb3NpdG9yeV9EZW1v LnBkZiI+aHR0cDovL3NjYXAubmlzdC5nb3YvZXZlbnRzLzIwMTEvc2FkZHNwL3ByZXNlbnRhdGlv bnMvU2VjdXJpdHlfQXV0b21hdGlvbl9Db250ZW50X1JlcG9zaXRvcnlfRGVtby5wZGY8L2E+PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YSBocmVm PSJodHRwOi8vc2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9pdHNhYy9wcmVzZW50YXRpb25zL2Rh eTMvTGFuZGZpZWxkLCUyMENoZXJuaW4sJTIwQmFzYXZhbm5hJTIwLSUyMENvbnRlbnQlMjBSZXBv c2l0b3JpZXMucGRmIj5odHRwOi8vc2NhcC5uaXN0Lmdvdi9ldmVudHMvMjAxMS9pdHNhYy9wcmVz ZW50YXRpb25zL2RheTMvTGFuZGZpZWxkLCUyMENoZXJuaW4sJTIwQmFzYXZhbm5hJTIwLSUyMENv bnRlbnQlMjBSZXBvc2l0b3JpZXMucGRmPC9hPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGVy ZSB3YXMgYWxzbyBhIHByZXNlbnRhdGlvbiB0aGF0IEFkYW0gTW9udHZpbGxlIHByZXBhcmVkIGZv ciB0aGUgSUVURiBTQUNNIFNpZGUgbWVldGluZy4gVGhleSBhcmUgYXZhaWxhYmxlIGluIHRoZSB6 aXAgZmlsZSBvZiB0aGUgcHJlc2VudGF0aW9ucyBsb2NhdGVkIGluJm5ic3A7PC9zcGFuPjxzcGFu IGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Y29s b3I6YmxhY2snPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9z YWNtL2N1cnJlbnQvbXNnMDAxNzguaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NhY20vY3VycmVudC9tc2cwMDE3OC5odG1sPC9hPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhpcyBpcyBvbmUgb2YgdGhl IHRvcGljcyBJIHdvdWxkIGxpa2UgdG8gc2VlIGRldmVsb3BlZCBvbiB0aGUgU0NBTSBsaXN0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzYwNkE3MSc+S2VudCBMYW5kZmllbGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojNjA2QTcxJz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3RvciBDb250 ZW50IFN0cmF0ZWd5LCBBcmNoaXRlY3R1cmUgYW5kIFN0YW5kYXJkczwvc3Bhbj48YnI+PGJyPjxz dHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5NY0Fm ZWUgfCBBbiBJbnRlbCBDb21wYW55PC9zcGFuPjwvc3Ryb25nPjxicj48c3BhbiBjbGFzcz1hcHBs ZS1zdHlsZS1zcGFuPjUwMDAgSGVhZHF1YXJ0ZXJzIERyLjwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9 YXBwbGUtc3R5bGUtc3Bhbj5QbGFubywgVGV4YXMgNzUwMjQ8L3NwYW4+PGJyPjxicj48c3BhbiBj bGFzcz1hcHBsZS1zdHlsZS1zcGFuPkRpcmVjdDogKzEuOTcyLjk2My43MDk2Jm5ic3A7PC9zcGFu Pjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPk1vYmlsZTogKzEuODE3LjYzNy44MDI2 PC9zcGFuPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+V2ViOiZuYnNwOzwvc3Bhbj48L3N0cm9uZz48c3BhbiBjbGFzcz1hcHBsZS1zdHls ZS1zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cubWNhZmVlLmNvbS8iPnd3dy5tY2FmZWUuY29tPC9h Pjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItd2lkdGg6aW5p dGlhbDtib3JkZXItY29sb3I6aW5pdGlhbCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+RnJvbTo8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RGF2aWQgU29saW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZEBKT1ZBTC5PUkciPmRhdmlkQEpPVkFMLk9SRzwvYT4m Z3Q7PGJyPjxiPlJlcGx5LVRvOjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJz cDs8L3NwYW4+PC9iPiZxdW90O09WQUwgRGV2ZWxvcGVyIExpc3QgKENsb3NlZCBQdWJsaWMgRGlz Y3Vzc2lvbikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNUQExJ U1RTLk1JVFJFLk9SRyI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8L2E+Jmd0 Ozxicj48Yj5Ubzo8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFu PjwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRS RS5PUkciPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHIj5PVkFM LURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRzwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6PHNw YW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtPVkFM LURFVkVMT1BFUi1MSVNUXSBBY2Nlc3MgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3aXRoIEphdmE8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48YmxvY2txdW90 ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItd2lkdGg6aW5pdGlh bDtib3JkZXItY29sb3I6aW5pdGlhbCcgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NL UVVPVEUiPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPldlJ2QgY2VydGFpbmx5IGJlIGludGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIGFu eSBzdWNoIHN0YW5kYXJkLiZuYnNwOyBDYW4geW91IHBvaW50IG1lIHRvIHdobydzIGFjdGl2ZWx5 IGRpc2N1c3NpbmcgaXQ/Jm5ic3A7IERvZXMgTUlUUkUgaW50ZW5kIHRvIHN1cHBvcnQgYW55IHN0 YW5kYXJkIGFwcHJvYWNoZXMgdG8gcmVwb3NpdG9yeSBhY2Nlc3M/PGJyPjxicj5SZWdhcmRzLDxi cj4tLURhdmlkPGJyPjxicj5PbiA0LzI4LzIwMTIgNjo1NiBBTSwgTHVpcyBOdW5leiB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5Zb3Uga25vdyB0aGVyZSBpcyB0YWxrIG9mIHByb2R1Y2luZyBh IHN0YW5kYXJkIHNwZWMgKHNhY20pIHRvIGRvIHNvbWV0aGluZyBsaWtlIHRoaXMuICZuYnNwO0kg a25vdyB3ZSBhcmUgYnVzeSBidXQgc29tZXRoaW5nIHRvIHRoaW5rIGFib3V0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JdCB3 b3VsZCBiZSBjb29sIHRvIGpvdmFsIGJlIGFibGUgdG8gZGlyZWN0bHkgcXVlcnkgYW5kIHB1bGwg ZG93biBjb250ZW50IGRpcmVjdGx5IGZyb20gU2VjUG9kIGFuZCBvdGhlciByZXBvc2l0b3JpZXMg aW4gYSBjb21tb24gd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4tbG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5PbiBBcHIgMjcsIDIwMTIsIGF0IDU6MzkgUE0sIERhdmlkIFNvbGluIHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ak9WQUwgcHJvdmlkZXMgYSBy ZWFkeS10by11c2UgSkFYQiBkYXRhIG1vZGVsIGZvciB0aGUgT1ZBTCBsYW5ndWFnZSwgdmFyaW91 cyB1dGlsaXR5IGNsYXNzZXMsIGFuZCBvZiBjb3Vyc2UsIGFuIGV2YWx1YXRpb24gZW5naW5lIGFu ZCBzY2FuIHBsdWctaW5zLiZuYnNwOyBJdCBkb2VzIG5vdCwgaG93ZXZlciwgaW1wbGVtZW50IGFj Y2VzcyB0byBhbnkgb24tbGluZSByZXBvc2l0b3JpZXMuPGJyPjxicj5GZWVsIGZyZWUgdG8gY29u dGFjdCBtZSBkaXJlY3RseSBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLjxicj48YnI+UmVnYXJk cyw8YnI+LS1EYXZpZCBTb2xpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PHAgc3R5bGU9J2xpbmUtaGVpZ2h0OjEyLjBwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMz MzMzMyc+PGEgaHJlZj0iaHR0cDovL2pPVkFMLm9yZyI+ak9WQUwub3JnPC9hPjogT1ZBTCBpbXBs ZW1lbnRlZCBpbiBKYXZhLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxicj48L3NwYW4+PGk+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojMzMzMzMzJz5TY2FuIGFueSBtYWNoaW5lIGZyb20gYW55IG1hY2hpbmUuIEZv ciBmcmVlITwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PGEgaHJlZj0iaHR0cDov L3d3dy5qb3ZhbC5vcmcvIj48c3BhbiBzdHlsZT0nY29sb3I6IzMzNjYwMCc+TGVhcm4gTW9yZTwv c3Bhbj48L2E+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj58 PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJo dHRwOi8vd3d3LmpvdmFsLm9yZy9mZWF0dXJlcy8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAw Jz5GZWF0dXJlczwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj58PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy9kb3dubG9hZC8iPjxzcGFuIHN0eWxlPSdj b2xvcjojMzM2NjAwJz5Eb3dubG9hZDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGJyPk9uIDQvMjcvMjAxMiA4OjQ4IEFNLCB2 dWxpc3RzIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cHJlPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+SGkgVGhlcmUsPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JJ20gbG9va2luZyBmb3IgYSB3YXkgdG8gYWNjZXNz IGEgVnVsbmVyYWJpbGl0eSBEYXRhYmFzZSB3aXRoIEphdmEuPG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5BdCB0aGUgbW9tZW50IEknbSBu b3QgMTAwJSBzdXJlIGlmIGl0cyBnb25uYSBiZSBPcGVuVkFTIG9yIHNvbWV0aGluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5lbHNlLCBsaWtl IGUuZy4gT1ZBTC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPkkgd2FudGVkIHRvIGFzaywgaWYgc29tZWJvZHkga25vd3Mgc29tZSByZWFk eS10by11c2UgSmF2YSBBUEkgdG8gYWNjZXNzPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZxdW90O29uZSBvZiB0aG9zZSZxdW90OyBWdWxuZXJh YmlsaXR5IERhdGFiYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPklmIHRoYXRzIG5vdCB0aGUgY2FzZSwgZG9lcyBpdCBtZWFuIEkg aGF2ZSB0byBpbXBsZW1lbnQgbXkgb3duIFhNTDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5QYXJzZXIgdG8gZ2V0IHRoZSB2dWxuZXJhYmlsaXR5 IGRhdGEgaW50byBteSBkYXRhYmFzZT88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPldoYXQgYWJvdXQgc3RhbmRhcmQgZm9ybWF0cz88bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5UaGFua3MgYW5kIGtpbmQgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJl PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwg bWVzc2FnZSB0byA8YSBocmVmPSJtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHIj5MSVNU U0VSVkBMSVNUUy5NSVRSRS5PUkc8L2E+IHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJl PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUPG86 cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmluIHRo ZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiZuYnNwOyBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdy aXRlIHRvIDxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMu TUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9h Pi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRvIHVu c3Vic2NyaWJlLCBzZW5kIGFuIGVtYWlsIG1lc3NhZ2UgdG88c3BhbiBjbGFzcz1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5N SVRSRS5PUkciPkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzwvYT48c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPndpdGggU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1M SVNUIGluIHRoZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMs IHdyaXRlIHRvPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9S RyI+T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRzwvYT4uPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0bzxzcGFuIGNs YXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkxJ U1RTRVJWQExJU1RTLk1JVFJFLk9SRyI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPC9hPjxzcGFu IGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+d2l0aCBTSUdOT0ZGIE9W QUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZl IGRpZmZpY3VsdGllcywgd3JpdGUgdG88c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RA TElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUu T1JHPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPi0tPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIHN0 eWxlPSdsaW5lLWhlaWdodDoxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxhIGhyZWY9Imh0 dHA6Ly9qT1ZBTC5vcmciPmpPVkFMLm9yZzwvYT46IE9WQUwgaW1wbGVtZW50ZWQgaW4gSmF2YS48 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PC9zcGFuPjxpPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMz Myc+U2NhbiBhbnkgbWFjaGluZSBmcm9tIGFueSBtYWNoaW5lLiBGb3IgZnJlZSE8L3NwYW4+PC9p PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzMzMzMzMyc+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuam92YWwub3JnIj48 c3BhbiBzdHlsZT0nY29sb3I6IzMzNjYwMCc+TGVhcm4gTW9yZTwvc3Bhbj48L2E+PHNwYW4gY2xh c3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj58PHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9y Zy9mZWF0dXJlcy8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5GZWF0dXJlczwvc3Bhbj48 L2E+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj58PHNwYW4g Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8v d3d3LmpvdmFsLm9yZy9kb3dubG9hZC8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5Eb3du bG9hZDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0bzxzcGFu IGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRyI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPC9hPjxz cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+d2l0aCBTSUdOT0ZG IE9WQUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBo YXZlIGRpZmZpY3VsdGllcywgd3JpdGUgdG88c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVl c3RATElTVFMuTUlUUkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlU UkUuT1JHPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9j a3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0bzxzcGFuIGNsYXNzPWFwcGxl LWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkxJU1RTRVJWQExJ U1RTLk1JVFJFLk9SRyI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPC9hPjxzcGFuIGNsYXNzPWFw cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+d2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxP UEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3Vs dGllcywgd3JpdGUgdG88c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlU UkUuT1JHIj5PVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9hPi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VG8gdW5zdWJzY3Jp YmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0bzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z cGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9S RyI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPC9hPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+d2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1QgaW4g dGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUg dG88c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIj5PVkFM LURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9hPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48YnI+PGJyPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwcmU+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5zYWNtIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9y ZyI+c2FjbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zYWNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208 L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPi0tPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIHN0eWxlPSdsaW5l LWhlaWdodDoxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxhIGhyZWY9Imh0dHA6Ly9qT1ZB TC5vcmciPmpPVkFMLm9yZzwvYT46IE9WQUwgaW1wbGVtZW50ZWQgaW4gSmF2YS48L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMzMzMzMzJz48YnI+PC9zcGFuPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+U2NhbiBh bnkgbWFjaGluZSBmcm9tIGFueSBtYWNoaW5lLiBGb3IgZnJlZSE8L3NwYW4+PC9pPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzMzMzMzMyc+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuam92YWwub3JnIj48c3BhbiBzdHls ZT0nY29sb3I6IzMzNjYwMCc+TGVhcm4gTW9yZTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj58PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVk LXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy9mZWF0dXJl cy8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5GZWF0dXJlczwvc3Bhbj48L2E+PHNwYW4g Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj58PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmpvdmFs Lm9yZy9kb3dubG9hZC8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5Eb3dubG9hZDwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj5zYWNtIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWls dG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930B98F86BA8MBCLUSTERxcha_-- From amontville@tripwire.com Thu May 3 11:58: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 8504F21F867A for ; Thu, 3 May 2012 11:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvgZvrwl3AyC for ; Thu, 3 May 2012 11:58:25 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id D90E421F8675 for ; Thu, 3 May 2012 11:58:24 -0700 (PDT) Received: from mail163-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 May 2012 18:58:14 +0000 Received: from mail163-tx2 (localhost [127.0.0.1]) by mail163-tx2-R.bigfish.com (Postfix) with ESMTP id B936640041A; Thu, 3 May 2012 18:58:14 +0000 (UTC) X-SpamScore: -24 X-BigFish: VPS-24(zz9371I1469Kzz1202hzz1033IL8275dhz2dh2a8h668h839h946he5bh) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail163-tx2 (localhost.localdomain [127.0.0.1]) by mail163-tx2 (MessageSwitch) id 1336071493789696_25119; Thu, 3 May 2012 18:58:13 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.250]) by mail163-tx2.bigfish.com (Postfix) with ESMTP id BA5E120050; Thu, 3 May 2012 18:58:13 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 3 May 2012 18:58:13 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 3 May 2012 12:08:27 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 3 May 2012 11:58:21 -0700 From: Adam Montville To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] Use Cases Thread-Index: Ac0pMdnNgGvxcIN8RIamBbiNsEWI7gALNr0A Date: Thu, 3 May 2012 18:58:19 +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.1.120420 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Use Cases 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, 03 May 2012 18:58:25 -0000 Once we get some more feedback, I'm interested in helping out with this eff= ort. Adam From: , "David A." > Date: Thursday, May 3, 2012 9:42 AM To: "sacm@ietf.org" > Subject: [sacm] Use Cases Before we move on, I=92d like to make one last call for feedback on the use= cases before moving forward. Even statements that you are happy with what= is there would be welcome. I=92d like to allow a few more days for feedba= ck. I have attached the last revision I posted a couple weeks back for con= venience. Please send your feedback by CoB 5/7/2012. The next step will b= e to find volunteers to work on fleshing out the use cases. Anyone interested? Sincerely, Dave From cmschmidt@mitre.org Thu May 3 13:12:04 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 ACCBC21F861D for ; Thu, 3 May 2012 13:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgfTqncn0QsM for ; Thu, 3 May 2012 13:12:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D25E121F861C for ; Thu, 3 May 2012 13:12:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 19D7021B1BEA; Thu, 3 May 2012 16:12:03 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 28D6E21B148F; Thu, 3 May 2012 16:12:02 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.183]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Thu, 3 May 2012 16:12:02 -0400 From: "Schmidt, Charles M." To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: Use Cases Thread-Index: Ac0pMdnNgGvxcIN8RIamBbiNsEWI7gANdTmw Date: Thu, 3 May 2012 20:12:00 +0000 Message-ID: <80B432C0A0D105468E74A98942733F771AA68AD6@IMCMBX04.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.53] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010E_01CD293F.14073EB0" MIME-Version: 1.0 Subject: Re: [sacm] Use Cases 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, 03 May 2012 20:12:04 -0000 ------=_NextPart_000_010E_01CD293F.14073EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, A small nit in UC1 and UC2: 3.1. UC1: Assessment and Enforcement of Acceptable State Controlling access to networks and services based on the assessment and analysis of host and/or network state based on machine processable content. 3.2. UC2: Behavioral Monitoring and Enforcement Controlling access to networks and services based on the detection and analysis of host and/or user behavior using automatable information from various sources. Both of these imply to me that SACM standards are used to control networks and services. This seems outside the scope of the current set of standards, although there may be interest in creating device control standards. If not, maybe the use cases could be reworded as follows: 3.1. UC1: Assessment and Enforcement of Acceptable State Assessment and analysis of host and/or network state based on machine processable content, which can be used in access control decisions for networks and services. 3.2. UC2: Behavioral Monitoring and Enforcement Detection and analysis of host and/or user behavior using automatable information from various sources, which can be used in access control decisions for networks and services. The original version implies, to me, that SACM contains standards for controlling access to resources. The latter version implies that SACM standards collect data, which can then be used (possibly by mechanisms outside the scope of SACM) to control access to resources. Charles >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Waltermire, David A. >Sent: Thursday, May 03, 2012 11:43 AM >To: sacm@ietf.org >Subject: [sacm] Use Cases > >Before we move on, I'd like to make one last call for feedback on the use >cases before moving forward. Even statements that you are happy with what >is there would be welcome. I'd like to allow a few more days for feedback. I >have attached the last revision I posted a couple weeks back for convenience. >Please send your feedback by CoB 5/7/2012. The next step will be to find >volunteers to work on fleshing out the use cases. > > > >Anyone interested? > > > >Sincerely, > >Dave > > ------=_NextPart_000_010E_01CD293F.14073EB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhwwggQEoAMCAQICCjXQ+u0AAgAAHHUwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDIwODE4MjYzN1oXDTE1MDIwNzE4MjYzN1owTjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxHjAcBgNVBAMTFVNj aG1pZHQuQ2hhcmxlcy4yNTY1ODCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMrfqe4f m+ZeRZvWO7aYp89KmWSTnFKgZjWprxFQ8zmAlth3LKEVdNn4wZgdUz54uHZvi5uCvcQU0trt2iDw F/hQ6jdn3VZhZsmA7TnRHRocBYIWdhvTEjOXpsKj51kz6uizhseb3lGubSj2DwN6A6C4f5SQt5yw CkpwX0pz9WqaSrT2aGoHgWx9MOBww1+v5DS5VNhHIyCVw0eFoSJ8aZxcWMIRBDdoFOCFR33KKfU9 P+/vYaG7OiNQlko5d0vvCBApYGURyaBKde1Krd0wRTP9FCc5GD+5OYxZx4XAhBMgQuh2Hv7E8EM+ ORpRQ2fW1Pno5dTl/92Sl1RITgxcyvkCAwEAAaOCAfgwggH0MCgGA1UdJQQhMB8GCCsGAQUFBwME BgkrBgEEAXMCAQcGCCsGAQUFBwMCMB0GA1UdDgQWBBTYG13f8BosUG6c5VDRxlP6AJYFezAOBgNV HQ8BAf8EBAMCBsAwHgYDVR0RBBcwFYETY21zY2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRp ZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9y Zy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYI KwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUy MENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQC AQcwFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDAL BgkrBgEEAXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBALqulox86p0q7Ry3fzT8 GOIMzBtv2HfzWXNciUVnvEtYtqfeSL+SmDU6JnVX2Mga7yzUdHnZ5J8+VfSARUpIIxoe56EI0Zc5 DJx1C4Uu5RErFCDf6Ye+YjZQHx6PI9jajX3b0Z1yyHDs5pfaDHZHLR7H5POdhJuna2SCk+d35/0g ciyUfa+yuwSZvpxsUSz6X/RnNe07w4K8631cShm3aAFE2ZQNndk+qqVDQ10MuDM/hLJMQFKCe+KV V2qqtrU879aF4nUh6aoq/i5pjHmV1c2uPx+LVX9uwaOQPOxIgbEuSC8dP6W5FAquGgLNI0bxCn5q eMza1rOXVQcpI5TCVzBtWfqPp0ipzWe/+PCl/T/aFbTeygC/JY/KjSpD+PMzOFjf7lhGjIx/bQUp pgbrcaUU2YX3ueygXDn9MyZZdS58hu49tC1Juq2TmhG8q/HAgD631tqRde6a2fuKfQX6cE0L6T2/ +bU39U+EExPz00bBzc2aMKMgayCFoqU2xH/nl2r8I9FiZbjcBwl02kvumOYcRTftIzesoj59LgGR y6iS728LHv1SJw11FE2yCVYb4Q1xtlKc8d9qp8p5UcCIu+zKFYqFRqSbdPBav7ZI169fR19tZWwy CzmXDYACGX6X38coRpdaTStwYC9Ed/2oB1bsr8iw57EAwD25hKX8RcbdMIIGYjCCBEqgAwIBAgIK FJcW0gAAAAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQ RSBSb290IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPy LGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0 aW9uIFBFIENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRk RMs/EOuF0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOf xHkRv1ho/fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NY RfsaetdhnBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0O fBz8DU8GiGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUm bojyVSJukhhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa 1mqolBiyDTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuv oWvdEXOozFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9k jEI+vEoyp/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+ fc7Jyzh9LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8w EAYJKwYBBAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0G A1UdDgQWBBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQl LJ84LzBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBv cmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAC hj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIw Q0EtMS5jcnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c 6GkGoEdFrmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7R BH9e437Nw3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJ yCze6rHQTFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/ 1C10bgc2tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9y YsNUN9LEVIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY 2ga1d7GIQ0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW95 7xAmaO6QdGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq71 2DVQHYuDXmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/ DBtjaw4JU6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGhTCCBG2gAwIBAgIKNdD96gACAAAcdjANBgkq hkiG9w0BAQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUx IjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMjA4MTgyNjM4WhcNMTUw MjA3MTgyNjM4WjBOMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3Bs ZTEeMBwGA1UEAxMVU2NobWlkdC5DaGFybGVzLjI1NjU4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAorGFoUP/zIAgRw12Ip6aDMZvkFCAOAQaWFer+PdAqnFNTH1v758Y3SaoCVYV8A+l 4FQryRUFLooFo4iGAGIom2pJ+gOO0McZdIZV77mzpaKIGavG2ER4nNcR6Hmo/iN/SxxK8yCskq9/ gUU/M+OjsQlCihw/6eEDZLyMwH9ugtPbtlt64xKSXQMDAarayTWs6mnW52RQdHukS2Z2PknWnug2 fg1oujCHFhr7ozY8+ACo6A5efGv8mbHupUlKmldD0HImJXSPinWG7eNzhIYG1/TArbMIfngiImIf iHpJM+xUSWDd5Uj1d6BphpdKRjaqr45xpTrdA4epQNj2WP8v7QIDAQABo4ICYTCCAl0wEwYDVR0l BAwwCgYIKwYBBQUHAwQwgZQGCSqGSIb3DQEJDwSBhjCBgzAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0w CwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBGTALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMB0GA1Ud DgQWBBQoJcp1KJQWbg6AC0wyjvYg3JaECDAOBgNVHQ8BAf8EBAMCBSAwHgYDVR0RBBcwFYETY21z Y2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8E QjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUl MjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUu b3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpo dHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwj ho6WV4GNiT2CpKsShb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgw GwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAHKX0H9OV/dwo Z9iKg2gM3SWDeGQ2fxCS3LW4Bp865NB2wlv8CP74O1xfFXIWqrKtqJZKStZ3D516vwhe6hP9AllS qyoAc6m7gqrpZlcbwyurBXXFhvZ3ZpEyasgyFhVSPqCIn4IOeAeHZSiMIh/rIUspSVW/DsYhpNpd CoiL3R3br1oAfJ+ijTxtTFvo/LLp/xnNONtpObqQylxO0HIU/3boqmFWy+w5P/GooxPwfwczLjks Cdo8RSUh/qZmYOaSRQPlgLMkqIrYwa2TGVWm00K2uIs7V5r3qlulobOccKjM649dORGnJnwCygsd zUbFutDHYSPEpmfY7Bj0oZo2qsJNstpAPqXSX4WvjVroYtV6P2fJ0PsYiTWwQtzBg9gQJfVUSVi6 MvExmrGJLI5kHUtuFGxkyq4arl2nvTGsi6D+75qXktGXaMHC2pPoUa2NXkJ2ogDw/7QPF60DuHJ3 RZ1XYebDKV/JURT6feN5LJvqxxd0KhvEyPZaxPZlkXvbToRWMGUthfYkhaZMvO7TV0nU4+gEjyWG z2AVh9G7nf5D+w/KlQSHrMCxGbwAVgUUIzcQhpD061hCYHisOpsyW/Th0lFgFFcFZeanVsyaLHkq 6cwnCQyPAdBqsKpArS11BP5zt36v7m8M/bm/OYPgNnqNXMU7PqRFVvbXRWV/qlsxggMjMIIDHwIB ATBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UE AxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKNdD67QACAAAcdTAJBgUrDgMCGgUAoIIBmjAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1MDMyMDExNTVaMCMG CSqGSIb3DQEJBDEWBBT6sBpwItcueNO0YLP0rZK7oo6U5zBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTAT BgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIK NdD96gACAAAcdjBvBgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMG CgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgo1 0P3qAAIAABx2MA0GCSqGSIb3DQEBAQUABIIBALZFxxRCVY0lZE3GUU0pal3pGl7y9X3r/ywN9bQK vS2h6JN/gURL5Kx4yoA3MIlwG7cFOKTQX9yV0BwTi3OnZuoP/j3MpQq6LlK0nxdJeQZsTjuYECPi Y77L2aPQuIrZ5D2IizMXnNqLuyG1ErB0VFwMlQ4vOnKuPoJpPZCbkp5hGcDdq5A48dzYjqp6HMxH L0307+0CGOpVKl2m6jlnoiB7gDbYYfdYyYfuN3VwY1vvUUWh5tIneUeQrVeWNQ+lR4vJeQjoeW+Y bkDPjtuuoTgnF5LbCdhRk7CSL7ZQtDTwvDVEORZzCSqUoFsvZ4OR/UL7sC59ViH9dyWsVTj7wxoA AAAAAAA= ------=_NextPart_000_010E_01CD293F.14073EB0-- From lnunez@c3isecurity.com Thu May 3 13:27: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 378AB21F8549 for ; Thu, 3 May 2012 13:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4iKhU-0OmBj for ; Thu, 3 May 2012 13:27:00 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC3B21F853E for ; Thu, 3 May 2012 13:27:00 -0700 (PDT) Received: by yhq56 with SMTP id 56so2617481yhq.31 for ; Thu, 03 May 2012 13:26:59 -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=1npIVhbfqOhCdILrr/3gcy9UzWmAtx7uK5dKhQmvcPo=; b=nXCFEpmSAXBf3/XsSsjCn85OsrvYVbPQReAcFZsqANSrEbUvoEPyETOfVTXpPEarTB dXT9ciN3m51hxvlkgG7ByERahRoHXvMYWakKswAaRMEPKzeP06FAPoZSJUkHhNGxcMKY ZJKZwywmD+pJaIY/M+d4lmCtiuPkPEBjhwHrD+sMRzd3ci08OGi1PUbakQtrXAN3lAb+ i2MKLY7Hn0w0OvNxNZiFmBlZOwsrDmQfn3EYcy1QCNHZ5/Ht0hWU8BWV9OCukTOzSBWA dwbiq8OS55XIrQy/FYTrk5cMUvn7P8VSL4yEbfqLWNJk/dq/CeELjOOOagD2qiooiJQQ xXog== Received: by 10.236.173.199 with SMTP id v47mr1227017yhl.42.1336076819092; Thu, 03 May 2012 13:26:59 -0700 (PDT) Received: from [172.16.1.100] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id b4sm9829229anb.22.2012.05.03.13.26.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 13:26:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: <80B432C0A0D105468E74A98942733F771AA68AD6@IMCMBX04.MITRE.ORG> Date: Thu, 3 May 2012 16:26:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <620E0C49-8320-416A-85A4-366908AA926F@c3isecurity.com> References: <80B432C0A0D105468E74A98942733F771AA68AD6@IMCMBX04.MITRE.ORG> To: "Schmidt, Charles M." X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkmccwsp8fN4rcwYCGOe6Mjz2EUBMG54OBnD8TjFaBnB+SQ/yPl7WziROUvFr8d33n4PBiP Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 03 May 2012 20:27:01 -0000 Some thoughts and connections with SACM and other working groups. 3.1. UC1: Assessment and Enforcement of Acceptable State - can be = related to Network Endpoint Assessment (nea) working group. 3.2. UC2: Behavioral Monitoring and Enforcement - could potentially be = related to the IP Flow Information Export (ipfix) working group. = Basically leveraging Netflow to detect network behavior. This = information could be received from what the MILE WG is doing with = incident response.=20 -ln On May 3, 2012, at 4:12 PM, Schmidt, Charles M. wrote: > Hello, >=20 > A small nit in UC1 and UC2: >=20 > 3.1. UC1: Assessment and Enforcement of Acceptable State >=20 > Controlling access to networks and services based on the assessment > and analysis of host and/or network state based on machine > processable content. >=20 > 3.2. UC2: Behavioral Monitoring and Enforcement >=20 > Controlling access to networks and services based on the detection > and analysis of host and/or user behavior using automatable > information from various sources. >=20 > Both of these imply to me that SACM standards are used to control = networks > and services. This seems outside the scope of the current set of = standards, > although there may be interest in creating device control standards. = If not, > maybe the use cases could be reworded as follows: >=20 > 3.1. UC1: Assessment and Enforcement of Acceptable State >=20 > Assessment and analysis of host and/or network state based on = machine > processable content, which can be used in access control decisions for > networks and services. > =09 > 3.2. UC2: Behavioral Monitoring and Enforcement >=20 > Detection and analysis of host and/or user behavior using = automatable > information from various sources, which can be used in access control > decisions for networks and services. >=20 > The original version implies, to me, that SACM contains standards for > controlling access to resources. The latter version implies that SACM > standards collect data, which can then be used (possibly by mechanisms > outside the scope of SACM) to control access to resources. >=20 > Charles > =09 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of >> Waltermire, David A. >> Sent: Thursday, May 03, 2012 11:43 AM >> To: sacm@ietf.org >> Subject: [sacm] Use Cases >>=20 >> Before we move on, I'd like to make one last call for feedback on the = use >> cases before moving forward. Even statements that you are happy with = what >> is there would be welcome. I'd like to allow a few more days for = feedback. > I >> have attached the last revision I posted a couple weeks back for > convenience. >> Please send your feedback by CoB 5/7/2012. The next step will be to = find >> volunteers to work on fleshing out the use cases. >>=20 >>=20 >>=20 >> Anyone interested? >>=20 >>=20 >>=20 >> Sincerely, >>=20 >> Dave >>=20 >>=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Thu May 3 14:32: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 B0F5C21F86EA for ; Thu, 3 May 2012 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqkRq6WgCvRN for ; Thu, 3 May 2012 14:32:35 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.159.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAB4C21F86E4 for ; Thu, 3 May 2012 14:32:35 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 1EDB854269A6F; Thu, 3 May 2012 16:32:35 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 1426754269A43 for ; Thu, 3 May 2012 16:32:35 -0500 (CDT) Received: from [198.180.150.230] (port=57847 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SQ3da-0002cz-NN; Thu, 03 May 2012 16:32:34 -0500 Message-ID: <4FA2F972.5030100@ieca.com> Date: Thu, 03 May 2012 17:32:34 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Waltermire, David A." 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: v230.vpn.iad.rg.net (thunderfish.local) [198.180.150.230]:57847 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 03 May 2012 21:32:40 -0000 Any reason to not just submit this and then add/remove authors later? spt On 5/3/12 12:42 PM, Waltermire, David A. wrote: > Before we move on, I’d like to make one last call for feedback on the > use cases before moving forward. Even statements that you are happy with > what is there would be welcome. I’d like to allow a few more days for > feedback. I have attached the last revision I posted a couple weeks back > for convenience. Please send your feedback by CoB 5/7/2012. The next > step will be to find volunteers to work on fleshing out the use cases. > > Anyone interested? > > Sincerely, > > Dave > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From pkampana@cisco.com Thu May 3 15:29: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 AD8E021F8720 for ; Thu, 3 May 2012 15:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xpAAhSvP7O5 for ; Thu, 3 May 2012 15:29:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 02BCC21F86F5 for ; Thu, 3 May 2012 15:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=3682; q=dns/txt; s=iport; t=1336084165; x=1337293765; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=A8ttHUrYsG/vHaZ5N1mPWlOxqAE2S6minC9lpLJTtZo=; b=YPbQ86kj3mNeGbLB5TdVlkUmb0et8Ls04PVT9SzNTT22Hh4umsv1D6RG WEycqqgjfz82OPiLYiZOc8Cya9IMMb+8wi4p4D+HmQXpsDDWAooXXYsc8 TBD06VYpq/ZFieoK4QKhRL2OaFASrVTSiiES9dSo8DEvBqYp+jOjXAasE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOUFo0+tJXG//2dsb2JhbABFojuQQoEHggkBAQEDAQEBAQUKAQoNEDQFBgUHAQMCCQ8CBAEBKAcZDh8JCAEBBBMLF4VvgXcFC5pCoBQEkQgEjXqWXYFpgwSBQA X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="80218252" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 03 May 2012 22:29:24 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q43MTOFN027732; Thu, 3 May 2012 22:29:24 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 17:29:23 -0500 Received: from WIN-ICH1QO6NCS6 ([64.102.220.145]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 17:29:23 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Thu, 03 May 2012 18:28:28 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Thu, 03 May 2012 18:28:28 -0500 From: "Panos Kampanakis" To: "Waltermire, David A." References: <80B432C0A0D105468E74A98942733F771AA68AD6@IMCMBX04.MITRE.ORG> <620E0C49-8320-416A-85A4-366908AA926F@c3isecurity.com> In-Reply-To: <620E0C49-8320-416A-85A4-366908AA926F@c3isecurity.com> Date: Thu, 3 May 2012 18:28:26 -0400 Organization: Cisco Systems Inc. Message-ID: <064801cd297c$0f082d10$2d188730$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0paxoPinEkAg2/Tbu9xpIKcXqlJQAEFK2w Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 03 May 2012 22:29:23.0676 (UTC) FILETIME=[30E749C0:01CD297C] Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases 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, 03 May 2012 22:29:25 -0000 Looking good. Could MILE's work also apply to Section 3.4? A suggestion: Should 3.4 incorporate Incident/Security Event Exchange? Or is it including it anyway already? Panos -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Thursday, May 03, 2012 4:27 PM To: Schmidt, Charles M. Cc: Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] Use Cases Some thoughts and connections with SACM and other working groups. 3.1. UC1: Assessment and Enforcement of Acceptable State - can be related to Network Endpoint Assessment (nea) working group. 3.2. UC2: Behavioral Monitoring and Enforcement - could potentially be related to the IP Flow Information Export (ipfix) working group. Basically leveraging Netflow to detect network behavior. This information could be received from what the MILE WG is doing with incident response. -ln On May 3, 2012, at 4:12 PM, Schmidt, Charles M. wrote: > Hello, > > A small nit in UC1 and UC2: > > 3.1. UC1: Assessment and Enforcement of Acceptable State > > Controlling access to networks and services based on the assessment > and analysis of host and/or network state based on machine > processable content. > > 3.2. UC2: Behavioral Monitoring and Enforcement > > Controlling access to networks and services based on the detection > and analysis of host and/or user behavior using automatable > information from various sources. > > Both of these imply to me that SACM standards are used to control > networks and services. This seems outside the scope of the current set > of standards, although there may be interest in creating device > control standards. If not, maybe the use cases could be reworded as follows: > > 3.1. UC1: Assessment and Enforcement of Acceptable State > > Assessment and analysis of host and/or network state based on > machine processable content, which can be used in access control > decisions for networks and services. > > 3.2. UC2: Behavioral Monitoring and Enforcement > > Detection and analysis of host and/or user behavior using > automatable information from various sources, which can be used in > access control decisions for networks and services. > > The original version implies, to me, that SACM contains standards for > controlling access to resources. The latter version implies that SACM > standards collect data, which can then be used (possibly by mechanisms > outside the scope of SACM) to control access to resources. > > Charles > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of Waltermire, David A. >> Sent: Thursday, May 03, 2012 11:43 AM >> To: sacm@ietf.org >> Subject: [sacm] Use Cases >> >> Before we move on, I'd like to make one last call for feedback on the >> use cases before moving forward. Even statements that you are happy >> with what is there would be welcome. I'd like to allow a few more days for feedback. > I >> have attached the last revision I posted a couple weeks back for > convenience. >> Please send your feedback by CoB 5/7/2012. The next step will be to >> find volunteers to work on fleshing out the use cases. >> >> >> >> Anyone interested? >> >> >> >> Sincerely, >> >> Dave >> >> > > _______________________________________________ > 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 david.waltermire@nist.gov Fri May 4 07:09:29 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 0D92621F87A8 for ; Fri, 4 May 2012 07:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDksDKQgdUgD for ; Fri, 4 May 2012 07:09:28 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 50C6C21F87AA for ; Fri, 4 May 2012 07:09:28 -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.355.2; Fri, 4 May 2012 10:09:18 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 4 May 2012 10:08:53 -0400 From: "Waltermire, David A." To: Adam Montville , "sacm@ietf.org" Date: Fri, 4 May 2012 10:09:25 -0400 Thread-Topic: [sacm] Use Cases Thread-Index: Ac0pMdnNgGvxcIN8RIamBbiNsEWI7gALNr0AACgyFZA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] Use Cases 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, 04 May 2012 14:09:29 -0000 Thanks Adam. Dave -----Original Message----- From: Adam Montville [mailto:amontville@tripwire.com] Sent: Thursday, May 03, 2012 2:58 PM To: Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] Use Cases Once we get some more feedback, I'm interested in helping out with this effort. Adam From: , "David A." > Date: Thursday, May 3, 2012 9:42 AM To: "sacm@ietf.org" > Subject: [sacm] Use Cases Before we move on, I'd like to make one last call for feedback on the use cases before moving forward. Even statements that you are happy with what is there would be welcome. I'd like to allow a few more days for feedback. I have attached the last revision I posted a couple weeks back for convenience. Please send your feedback by CoB 5/7/2012. The next step will be to find volunteers to work on fleshing out the use cases. Anyone interested? Sincerely, Dave From kathleen.moriarty@emc.com Fri May 4 08:07: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 3A5B021F8717 for ; Fri, 4 May 2012 08:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zeFXjARmsTN for ; Fri, 4 May 2012 08:07:08 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3207F21F85AC for ; Fri, 4 May 2012 08:07:07 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q44F72e5029308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 11:07:06 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 4 May 2012 11:06:50 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q44F6obk003243; Fri, 4 May 2012 11:06:50 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Fri, 4 May 2012 11:06:49 -0400 From: To: , Date: Fri, 4 May 2012 11:06:48 -0400 Thread-Topic: [sacm] Use Cases Thread-Index: Ac0paxoPinEkAg2/Tbu9xpIKcXqlJQAEFK2wACLECwA= Message-ID: References: <80B432C0A0D105468E74A98942733F771AA68AD6@IMCMBX04.MITRE.ORG> <620E0C49-8320-416A-85A4-366908AA926F@c3isecurity.com> <064801cd297c$0f082d10$2d188730$@com> In-Reply-To: <064801cd297c$0f082d10$2d188730$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases 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, 04 May 2012 15:07:09 -0000 I agree with all of the associations listed from other reviewers. Thank yo= u for shaping up the use case document, Dave! Should 3.4 also include the methods to combine data sets to generate report= s that would be shared between parties so that we have this use case refere= nce the MILE work for GRC-Exchange, but establish the use cases for the exc= hange and additional work that may be needed to tie these pieces together? Also, in addition to calling out the specific IETF work, I think it would b= e helpful to reference any Security Automation work so that we start to und= erstand the possible relationships. This will help us to identify what is = needed for SACM to be successful. We may also be able to determine which o= f the specifications we need can be normatively referenced and possibly pul= led into the IETF and where we may run into trouble. This should help us d= etermine any protocol or guidance documentation we will need to generate to= support the described use cases. Maybe this is already intended for secti= on 5? I am also happy to assist in further development of the use cases. Thank you very much for your work on this Dave! Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Pan= os Kampanakis Sent: Thursday, May 03, 2012 6:28 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases Looking good. Could MILE's work also apply to Section 3.4?=20 A suggestion: Should 3.4 incorporate Incident/Security Event Exchange? Or i= s it including it anyway already? Panos -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Lui= s Nunez Sent: Thursday, May 03, 2012 4:27 PM To: Schmidt, Charles M. Cc: Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] Use Cases Some thoughts and connections with SACM and other working groups. 3.1. UC1: Assessment and Enforcement of Acceptable State - can be related to Network Endpoint Assessment (nea) working group. 3.2. UC2: Behavioral Monitoring and Enforcement - could potentially be related to the IP Flow Information Export (ipfix) working group. Basically leveraging Netflow to detect network behavior. This information could be received from what the MILE WG is doing with incident response.=20 -ln On May 3, 2012, at 4:12 PM, Schmidt, Charles M. wrote: > Hello, >=20 > A small nit in UC1 and UC2: >=20 > 3.1. UC1: Assessment and Enforcement of Acceptable State >=20 > Controlling access to networks and services based on the assessment > and analysis of host and/or network state based on machine > processable content. >=20 > 3.2. UC2: Behavioral Monitoring and Enforcement >=20 > Controlling access to networks and services based on the detection > and analysis of host and/or user behavior using automatable > information from various sources. >=20 > Both of these imply to me that SACM standards are used to control=20 > networks and services. This seems outside the scope of the current set=20 > of standards, although there may be interest in creating device=20 > control standards. If not, maybe the use cases could be reworded as follows: >=20 > 3.1. UC1: Assessment and Enforcement of Acceptable State >=20 > Assessment and analysis of host and/or network state based on=20 > machine processable content, which can be used in access control=20 > decisions for networks and services. > =09 > 3.2. UC2: Behavioral Monitoring and Enforcement >=20 > Detection and analysis of host and/or user behavior using=20 > automatable information from various sources, which can be used in=20 > access control decisions for networks and services. >=20 > The original version implies, to me, that SACM contains standards for=20 > controlling access to resources. The latter version implies that SACM=20 > standards collect data, which can then be used (possibly by mechanisms=20 > outside the scope of SACM) to control access to resources. >=20 > Charles > =09 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf=20 >> Of Waltermire, David A. >> Sent: Thursday, May 03, 2012 11:43 AM >> To: sacm@ietf.org >> Subject: [sacm] Use Cases >>=20 >> Before we move on, I'd like to make one last call for feedback on the=20 >> use cases before moving forward. Even statements that you are happy=20 >> with what is there would be welcome. I'd like to allow a few more days for feedback. > I >> have attached the last revision I posted a couple weeks back for > convenience. >> Please send your feedback by CoB 5/7/2012. The next step will be to=20 >> find volunteers to work on fleshing out the use cases. >>=20 >>=20 >>=20 >> Anyone interested? >>=20 >>=20 >>=20 >> Sincerely, >>=20 >> Dave >>=20 >>=20 >=20 > _______________________________________________ > 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 david.waltermire@nist.gov Fri May 4 09:33:21 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 4614D21E8045 for ; Fri, 4 May 2012 09:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.875 X-Spam-Level: X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnFl5d-Lv9qn for ; Fri, 4 May 2012 09:33:20 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 337B121E800F for ; Fri, 4 May 2012 09:33:20 -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.355.2; Fri, 4 May 2012 12:33:10 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 4 May 2012 12:33:19 -0400 From: "Waltermire, David A." To: "kathleen.moriarty@emc.com" , "pkampana@cisco.com" Date: Fri, 4 May 2012 12:33:18 -0400 Thread-Topic: [sacm] Use Cases Thread-Index: Ac0paxoPinEkAg2/Tbu9xpIKcXqlJQAEFK2wACLECwAAAxtkAA== Message-ID: References: <80B432C0A0D105468E74A98942733F771AA68AD6@IMCMBX04.MITRE.ORG> <620E0C49-8320-416A-85A4-366908AA926F@c3isecurity.com> <064801cd297c$0f082d10$2d188730$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 04 May 2012 16:33:21 -0000 The associations look good. I will note them in the document. Thanks for also pointing out the GRC-Exchange work. To reiterate your point, I see that internet draft providing the generalized data flow and envelope that can be used to exchange many different types of information related to the use case in section 3.4. We do need to capture the relationships; that is the plan for section 5. I will note relationships as we discuss them in that section to be fleshed out later. Sincerely, Dave -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] Sent: Friday, May 04, 2012 11:07 AM To: pkampana@cisco.com; Waltermire, David A. Cc: sacm@ietf.org Subject: RE: [sacm] Use Cases I agree with all of the associations listed from other reviewers. Thank you for shaping up the use case document, Dave! Should 3.4 also include the methods to combine data sets to generate reports that would be shared between parties so that we have this use case reference the MILE work for GRC-Exchange, but establish the use cases for the exchange and additional work that may be needed to tie these pieces together? Also, in addition to calling out the specific IETF work, I think it would be helpful to reference any Security Automation work so that we start to understand the possible relationships. This will help us to identify what is needed for SACM to be successful. We may also be able to determine which of the specifications we need can be normatively referenced and possibly pulled into the IETF and where we may run into trouble. This should help us determine any protocol or guidance documentation we will need to generate to support the described use cases. Maybe this is already intended for section 5? I am also happy to assist in further development of the use cases. Thank you very much for your work on this Dave! Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Panos Kampanakis Sent: Thursday, May 03, 2012 6:28 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases Looking good. Could MILE's work also apply to Section 3.4? A suggestion: Should 3.4 incorporate Incident/Security Event Exchange? Or is it including it anyway already? Panos -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Thursday, May 03, 2012 4:27 PM To: Schmidt, Charles M. Cc: Waltermire, David A.; sacm@ietf.org Subject: Re: [sacm] Use Cases Some thoughts and connections with SACM and other working groups. 3.1. UC1: Assessment and Enforcement of Acceptable State - can be related to Network Endpoint Assessment (nea) working group. 3.2. UC2: Behavioral Monitoring and Enforcement - could potentially be related to the IP Flow Information Export (ipfix) working group. Basically leveraging Netflow to detect network behavior. This information could be received from what the MILE WG is doing with incident response. -ln On May 3, 2012, at 4:12 PM, Schmidt, Charles M. wrote: > Hello, > > A small nit in UC1 and UC2: > > 3.1. UC1: Assessment and Enforcement of Acceptable State > > Controlling access to networks and services based on the assessment > and analysis of host and/or network state based on machine > processable content. > > 3.2. UC2: Behavioral Monitoring and Enforcement > > Controlling access to networks and services based on the detection > and analysis of host and/or user behavior using automatable > information from various sources. > > Both of these imply to me that SACM standards are used to control > networks and services. This seems outside the scope of the current set > of standards, although there may be interest in creating device > control standards. If not, maybe the use cases could be reworded as follows: > > 3.1. UC1: Assessment and Enforcement of Acceptable State > > Assessment and analysis of host and/or network state based on > machine processable content, which can be used in access control > decisions for networks and services. > > 3.2. UC2: Behavioral Monitoring and Enforcement > > Detection and analysis of host and/or user behavior using > automatable information from various sources, which can be used in > access control decisions for networks and services. > > The original version implies, to me, that SACM contains standards for > controlling access to resources. The latter version implies that SACM > standards collect data, which can then be used (possibly by mechanisms > outside the scope of SACM) to control access to resources. > > Charles > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of Waltermire, David A. >> Sent: Thursday, May 03, 2012 11:43 AM >> To: sacm@ietf.org >> Subject: [sacm] Use Cases >> >> Before we move on, I'd like to make one last call for feedback on the >> use cases before moving forward. Even statements that you are happy >> with what is there would be welcome. I'd like to allow a few more >> days for feedback. > I >> have attached the last revision I posted a couple weeks back for > convenience. >> Please send your feedback by CoB 5/7/2012. The next step will be to >> find volunteers to work on fleshing out the use cases. >> >> >> >> Anyone interested? >> >> >> >> Sincerely, >> >> Dave >> >> > > _______________________________________________ > 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 anton.chuvakin@gmail.com Fri May 4 09:46: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 27A6B21F862F for ; Fri, 4 May 2012 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDoxIxcihjWw for ; Fri, 4 May 2012 09:46:17 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC521F861A for ; Fri, 4 May 2012 09:46:16 -0700 (PDT) Received: by bkty8 with SMTP id y8so2859201bkt.31 for ; Fri, 04 May 2012 09:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=6b2OlDagQ/LregLEMz8nOlAnIzdFgTsbIF0W5syJ3OI=; b=wOb++IVROS0Sl/Yhh5dW/xyMwFXWLAf/FILxNiwYmwQacGMOhKMsm9ttm1H2N8WjUq f5BOq/j7bOOzdW7IJRGkGKVODwh8WX9U7vu65nvamCgtrS6DPOtKOxD43Wd/1fn53H7W NgT6geMRY1jfygTUOhtkKM5YNt2JZCVgyI93bSIK74yJDhh32CLxQAqh0AMEYw0eJvqH T99LVuLnRmcmhx7Zfp4/cky8rAHujSabsbqIWW5op5dyFTLq4eLf21gC8+2S4XOtW/5t 9tf3pcePq3J+tHvnlD4XmOaf4gHTE4VU0j0EWbb0OhZLotN8MmcIUXGHlXYitXCatxus wb0g== Received: by 10.204.128.88 with SMTP id j24mr2383065bks.89.1336149975625; Fri, 04 May 2012 09:46:15 -0700 (PDT) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.204.119.9 with HTTP; Fri, 4 May 2012 09:45:45 -0700 (PDT) In-Reply-To: References: From: Anton Chuvakin Date: Fri, 4 May 2012 09:45:45 -0700 X-Google-Sender-Auth: gs7w0JG7rSvoQZWjlHMbI8gVks0 Message-ID: To: "Waltermire, David A." Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 04 May 2012 16:46:18 -0000 > cases before moving forward.=A0 Even statements that you are happy with w= hat > is there would be welcome.=A0 I=92d like to allow a few more days for fee= dback. I think these is a mix of monitoring (activity, behavior, events) and assessment (controls, settings, configurations) use cases, is this intentional? --=20 Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From david.waltermire@nist.gov Fri May 4 10:08:04 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 DAFFB21E801A for ; Fri, 4 May 2012 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYiKeRRkYW8a for ; Fri, 4 May 2012 10:08:04 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2719E21E8018 for ; Fri, 4 May 2012 10:08:04 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 4 May 2012 13:07:38 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 4 May 2012 13:07:26 -0400 From: "Waltermire, David A." To: Anton Chuvakin Date: Fri, 4 May 2012 13:07:58 -0400 Thread-Topic: [sacm] Use Cases Thread-Index: Ac0qFVqiv9N5XSqiSh2JlsOsKw4MTQAApBLw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 04 May 2012 17:08:05 -0000 Yes. To some extent there is a compositional relationship between the use = cases. UC 1 & 2 provide data collection (assessment) that can be used for = UC 3 and UC 5 which focus on monitoring. UC 4 provides reporting capabilit= ies based on UC 3 and 5. Sincerely, Dave -----Original Message----- From: anton.chuvakin@gmail.com [mailto:anton.chuvakin@gmail.com] On Behalf = Of Anton Chuvakin Sent: Friday, May 04, 2012 12:46 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases > cases before moving forward.=A0 Even statements that you are happy with=20 > what is there would be welcome.=A0 I'd like to allow a few more days for = feedback. I think these is a mix of monitoring (activity, behavior, events) and asses= sment (controls, settings, configurations) use cases, is this intentional? -- Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From david.waltermire@nist.gov Fri May 4 10:17: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 42B0D21F8620 for ; Fri, 4 May 2012 10:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AITKZ1uX3Fnz for ; Fri, 4 May 2012 10:17:11 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A601321F861F for ; Fri, 4 May 2012 10:17:11 -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.355.2; Fri, 4 May 2012 13:17:02 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 4 May 2012 13:17:10 -0400 From: "Waltermire, David A." To: Sean Turner Date: Fri, 4 May 2012 13:17:09 -0400 Thread-Topic: [sacm] Use Cases Thread-Index: Ac0pdDAigN0ZHOWgQWCoOlALLOJcrQApV3ZA Message-ID: References: <4FA2F972.5030100@ieca.com> In-Reply-To: <4FA2F972.5030100@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 Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 04 May 2012 17:17:12 -0000 Sean, I would like to submit the document at regular milestones, essentially once we are able to complete each section. Will this work for you? Sincerely, Dave -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Thursday, May 03, 2012 5:33 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases Any reason to not just submit this and then add/remove authors later? spt On 5/3/12 12:42 PM, Waltermire, David A. wrote: > Before we move on, I'd like to make one last call for feedback on the > use cases before moving forward. Even statements that you are happy > with what is there would be welcome. I'd like to allow a few more days > for feedback. I have attached the last revision I posted a couple > weeks back for convenience. Please send your feedback by CoB 5/7/2012. > The next step will be to find volunteers to work on fleshing out the use cases. > > Anyone interested? > > Sincerely, > > Dave > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Fri May 4 10:26:49 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 6535521F85C3 for ; Fri, 4 May 2012 10:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wbCO7uM9EnG for ; Fri, 4 May 2012 10:26:49 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.7.5]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB321F85AC for ; Fri, 4 May 2012 10:26:48 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 8DE3851069CBC; Fri, 4 May 2012 12:26:48 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 8036851069C9C for ; Fri, 4 May 2012 12:26:48 -0500 (CDT) Received: from [198.180.150.230] (port=50364 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SQMHI-0001Yd-B2; Fri, 04 May 2012 12:26:48 -0500 Message-ID: <4FA41157.8010703@ieca.com> Date: Fri, 04 May 2012 13:26:47 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Waltermire, David A." References: <4FA2F972.5030100@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: v230.vpn.iad.rg.net (thunderfish.local) [198.180.150.230]:50364 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 04 May 2012 17:26:49 -0000 Dave, That sounds like a plan, but by submit I mean get it in to the datatracker so we can use the tools to see what's changed and publication announcements will be sent to the appropriate places. Use this page to submit drafts: https://datatracker.ietf.org/submit/ Thanks, spt On 5/4/12 1:17 PM, Waltermire, David A. wrote: > Sean, > > I would like to submit the document at regular milestones, essentially once we are able to complete each section. Will this work for you? > > Sincerely, > Dave > > > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Thursday, May 03, 2012 5:33 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [sacm] Use Cases > > Any reason to not just submit this and then add/remove authors later? > > spt > > On 5/3/12 12:42 PM, Waltermire, David A. wrote: >> Before we move on, I'd like to make one last call for feedback on the >> use cases before moving forward. Even statements that you are happy >> with what is there would be welcome. I'd like to allow a few more days >> for feedback. I have attached the last revision I posted a couple >> weeks back for convenience. Please send your feedback by CoB 5/7/2012. >> The next step will be to find volunteers to work on fleshing out the use cases. >> >> Anyone interested? >> >> Sincerely, >> >> Dave >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > From david.waltermire@nist.gov Fri May 4 10:44: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 ED2EB21E801E for ; Fri, 4 May 2012 10:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTC5ka1+xZTe for ; Fri, 4 May 2012 10:44:42 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9621E801C for ; Fri, 4 May 2012 10:44:40 -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.355.2; Fri, 4 May 2012 13:44:29 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 4 May 2012 13:44:38 -0400 From: "Waltermire, David A." To: Sean Turner Date: Fri, 4 May 2012 13:44:37 -0400 Thread-Topic: [sacm] Use Cases Thread-Index: Ac0qGwMg6HPmH8yEQiObbQkzKGc4DAAAnl7g Message-ID: References: <4FA2F972.5030100@ieca.com> <4FA41157.8010703@ieca.com> In-Reply-To: <4FA41157.8010703@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 Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 04 May 2012 17:44:44 -0000 That is also what I intended to do. ;-) Sincerely, Dave -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Friday, May 04, 2012 1:27 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases Dave, That sounds like a plan, but by submit I mean get it in to the datatracker so we can use the tools to see what's changed and publication announcements will be sent to the appropriate places. Use this page to submit drafts: https://datatracker.ietf.org/submit/ Thanks, spt On 5/4/12 1:17 PM, Waltermire, David A. wrote: > Sean, > > I would like to submit the document at regular milestones, essentially once we are able to complete each section. Will this work for you? > > Sincerely, > Dave > > > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Thursday, May 03, 2012 5:33 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [sacm] Use Cases > > Any reason to not just submit this and then add/remove authors later? > > spt > > On 5/3/12 12:42 PM, Waltermire, David A. wrote: >> Before we move on, I'd like to make one last call for feedback on the >> use cases before moving forward. Even statements that you are happy >> with what is there would be welcome. I'd like to allow a few more >> days for feedback. I have attached the last revision I posted a >> couple weeks back for convenience. Please send your feedback by CoB 5/7/2012. >> The next step will be to find volunteers to work on fleshing out the use cases. >> >> Anyone interested? >> >> Sincerely, >> >> Dave >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > From anton.chuvakin@gmail.com Fri May 4 10:48: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 A712A21E801C for ; Fri, 4 May 2012 10:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f9d7-jSpgoN for ; Fri, 4 May 2012 10:48:12 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE0A321F8567 for ; Fri, 4 May 2012 10:48:11 -0700 (PDT) Received: by bkty8 with SMTP id y8so2908152bkt.31 for ; Fri, 04 May 2012 10:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=3yZKbNvsrWWx3M6IN1mROJQINoftZBsgoXyfg39KyHI=; b=vGVlJntmlUqHm1vkf2bxSpUyC+eciAh8DDaby59cyGj1xAn1M5+2zU7anexLAqkf1E YmSJ7I+HPeSmlyyw/iSHXLIyOk0NIt3zJbvYwXm0u5NgNJjS1V0B+Lhoe4bQ4ZquiUYU P/QtJVv5TICMUGn+fRBHoz9GqtQmROfC/EzIhIYR52pr4FjRURMjrJe4GgzfXOv8QRBk G+QtAnIaEJ1ELSV9IJt7o8B2zJZH2YqB710ogdMetTiTei9S2/0MUpKT1gUOIzXH2fLS mE1yra9xZdrcSeiDsAQwJ5uqaAHTUzIvo+rm5vFG4iXRpaPeoiAJSolCqTgHuurnJlIs xf3w== Received: by 10.204.130.89 with SMTP id r25mr2424277bks.48.1336153690695; Fri, 04 May 2012 10:48:10 -0700 (PDT) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.204.119.9 with HTTP; Fri, 4 May 2012 10:47:40 -0700 (PDT) In-Reply-To: References: From: Anton Chuvakin Date: Fri, 4 May 2012 10:47:40 -0700 X-Google-Sender-Auth: 77aPGBe5DsOn9hF0JluOFvAufJA Message-ID: To: "Waltermire, David A." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 04 May 2012 17:48:12 -0000 >> I think these is a mix of monitoring (activity, behavior, events) and as= sessment (controls, settings, configurations) use cases, is this intentiona= l? > Yes. =A0To some extent there is a compositional relationship between the = use cases. =A0UC 1 & 2 provide data collection (assessment) that can be use= d for UC 3 and UC 5 which focus on monitoring. =A0UC 4 provides reporting c= apabilities based on UC 3 and 5. That makes sense - in general, I'd feel more comfortable is state/control/configuration/assessment/non-timed data is more logically separated from activity/event/behavior/logs/timed data. --=20 Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From amontville@tripwire.com Mon May 7 14:43: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 250C521F8700 for ; Mon, 7 May 2012 14:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHocEKwwX-xv for ; Mon, 7 May 2012 14:43:22 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8C03E21F86FF for ; Mon, 7 May 2012 14:43:19 -0700 (PDT) Received: from mail188-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 May 2012 21:43:05 +0000 Received: from mail188-tx2 (localhost [127.0.0.1]) by mail188-tx2-R.bigfish.com (Postfix) with ESMTP id 8F153380345; Mon, 7 May 2012 21:43:05 +0000 (UTC) X-SpamScore: -22 X-BigFish: VPS-22(zz9371I9f17R1452I604T4015I9a6kzz1202hzz8275bh8275dhz2dh2a8h668h839h946he5bh) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail188-tx2 (localhost.localdomain [127.0.0.1]) by mail188-tx2 (MessageSwitch) id 1336426983163341_27659; Mon, 7 May 2012 21:43:03 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.237]) by mail188-tx2.bigfish.com (Postfix) with ESMTP id 219D93400CE; Mon, 7 May 2012 21:43:03 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 7 May 2012 21:43:02 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 7 May 2012 14:53: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.0355.002; Mon, 7 May 2012 14:43:14 -0700 From: Adam Montville To: "Kent_Landfield@mcafee.com" , Multiple recipients of list Thread-Topic: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Thread-Index: AQHNBtsGcoxLd5y7LUSetiAZDPBln5a1pU6AgANruACABnG9gP//pFMA Date: Mon, 7 May 2012 21:43:14 +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.1.120420 x-originating-ip: [172.16.97.25] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: <7469AB30FC2E2844B25A098C5061C2D5@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA 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, 07 May 2012 21:43:24 -0000 Kent, Thank you for sending this out. I like many of the suggestions you have ma= de, especially about sending presentations/documentation ahead of time and = time boxing based on subject. The more work we can get done, the more valu= e these sessions have, and the better our justification for attending so we= can help create safer computing environments. I agree with your points about what is/is not included in the original list= , but would also like to add something: SACM. I haven't seen too much acti= vity on the SACM list, and I know that some of the listed topic areas are u= nder consideration (in one way or another) for the SACM effort. If Bedford= attendees represent a significant portion of what we expect to constitute = the initial SACM community, I would like to see us take some time to discus= s and evaluate that effort =96 especially as IETF 84 will be later that mon= th. Regards, Adam From: kent_landfield > Reply-To: kent_landfield > Date: Monday, May 7, 2012 1:22 PM To: Multiple recipients of list > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation being sent out in advance, a webinar if it is felt there will be = questions and answers from those that are new to the efforts. We have a li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in a= dvance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas th= at need real work by the community 4. Efforts to be discussed should be based on needs of the security auto= mation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d with. There are going to be things we need to do as a security automation= community to be able to accomplish what is listed in the CAESARS FE. Ther= e are interfaces that need to be worked and established. That is one area = that is not listed below. CM will have a major impact on all of us in the = next couple years and it is being ignored. We can't keep trying to solve w= hat has already been solved. We need to address the needed interface devel= opment now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +=85) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e they are such a pain to manage from a content perspective. It is easier = to buy from one vendor that has a single means for distributing content tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that = is being underutilized and under implemented because of the limitations of = how it addresses uses in an enterprise environment. People don't need secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. Scheduling and tracking are key to it's success. We need to make that= happen. This too needs a focused brainstorming time box to discuss option= s. I am really disappointed that Remediation is not on the list below=85 Yes,= last Summer Dev Days, the time spent on Remediation was wasted time but th= at does not mean we should ignore it and not try to make some real progress= . As far as I am concerned we need to reboot the remediation effort. We c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. But today we think it is too hard so we don't try ? I think we need = a couple hours to discuss the reboot of the effort even if that means minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al Agencies. The initial effort was a mess, did little more than prove it = was possible and cause the vendor community a great deal of thrashing to pu= t a kludgey 'solution' in place. Reality is all our customers need roll up= reporting and an infrastructure that supports it. A data call should not = be special to anyone other than the agencies responding. The tools should b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces=85. We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess while we are all in the same room. This is always a big event for the = 'consensus of the willing' that assemble and driven to see security automat= ion make a difference. Let's see if we can have an event that, when we all= walk out the last day, we all feel that every minute was well spent and mo= ves us forward. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng the week of July 9 =96 starting Monday at 10:00 AM and ending on Friday = at 12:00. Meanwhile, we are working on the agenda and are currently considering this = list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year=92s MITRE-hosted Security Automation Developer Days event will be= held during the week of July 9, 2012 at MITRE=92s facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. From david.waltermire@nist.gov Tue May 8 07:44:15 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 AD47921F85D1 for ; Tue, 8 May 2012 07:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.435 X-Spam-Level: X-Spam-Status: No, score=-5.435 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVUFfT7qqF7m for ; Tue, 8 May 2012 07:44:06 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8B94721F85CE for ; Tue, 8 May 2012 07:44:05 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 8 May 2012 10:44:00 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 8 May 2012 10:43:17 -0400 From: "Waltermire, David A." To: "Kinney, Michael A" , SCAP-DEV , "sacm@ietf.org" Date: Tue, 8 May 2012 10:44:03 -0400 Thread-Topic: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Thread-Index: Ac0spojaQDLCQzcmSvqRdyTN8pGVawAYGTOAAAbpivA= Message-ID: References: <8E41D51B05B4EE4CA29C7DBDDA5B5B0E185C48@IMCMBX03.MITRE.ORG> <15D0981C9BE53042A4C9D0F3D0B6826B2900EC@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: <15D0981C9BE53042A4C9D0F3D0B6826B2900EC@MSIS-GH1-UEA10.corp.nsa.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_D7A0423E5E193F40BE6E94126930C4930B99201010MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA 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, 08 May 2012 14:44:15 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B99201010MBCLUSTERxcha_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content reposit= ory for use in a production environment. As an open source project, it wil= l be free for use by anyone interested. My thinking is that this project c= an bridge the gap until commercial solutions are available to augment it. = This is a similar path that was followed with DNS (bind) and HTTP (apache).= When it is ready for use, I am hoping to use it to host USGCB content. Y= ou would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supp= orting risk management and aspects of continuous monitoring. I would also = like to see some discussion on OCIL at Developer Days. With the proposals = we will likely have a sense of what needs to be discussed and what we can a= chieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see = it move forward. We just published the draft ASR specification for public comment. This spe= cification supports enterprise aggregate reporting which greatly reduces th= e data volumes needed verses detailed host-based reports. This specificatio= n has been designed as a more robust replacement for LASR. It can be used = in continuous monitoring applications to support aggregate data reporting n= eeds (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internatio= nalization issue. Many vendors have commented that they are still working o= n implementing the XCCDF 1.2.1 specification. We will be in a better place = in a few months once more development around XCCDF has occurred. As we con= sider changes to the SCAP stack to address OCIL and other issues, we will i= dentify areas that need improvement in XCCDF. These are good and necessary= discussions to have now, but we have a good deal of work to do before we a= re ready to open up XCCDF. My suggestion is to work on these related areas= and then work up change proposals for XCCDF as needed. By that time we sh= ould be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has bee= n too long. Sincerely, Dave From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, It's good to read your thoughts, and a realistic actionable approach is ind= eed needed. Since all the activity hasn't been on the lists a brief =BD ho= ur recap may be in order to bring everyone up to speed since there has been= a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone will= ing to stand one up it will be as valuable as the CCSS specification is tod= ay. I've been trying for two years to get my management to get a coordinat= ed effort together for the DoD to stand up a repository, it is a tough prob= lem and will require funding with a tail, I'm not sure a specification will= solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year try= ing to make it useful in an enterprise environment and will be posting our = ideas to the list before developer days it should have already started, we = need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I'm making every effort to get it kick started f= rom our perspective. I hope to assist in getting the draft ERI finished thi= s year. We are writing some new STIG content and intend to used the draft = CRE specification to insert CRE into the content so we (DoD) can do some au= tomatic configuration fixes, part of a self healing network concept. It is = just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and = content to roll up reporting, in any enterprise of size the problem gets gr= eater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from ef= forts to meet use cases, we have some things we would like changed in XCCDF= to support our OCIl use case and I have been told that I need to wait. I d= idn't think that a move to internationalization should impede efforts to mo= ve forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov From: scap-dev@nist.gov [mailto:scap-dev@nist.gov= ] On Behalf Of Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of ap= proach. We would like to see some community discussion around what are the= key areas/priorities that the community would like to see discussed at Dev= Days. Your topics below look like a good start. The SACM list might be a = better venue than the OVAL list for this discussion. For each area we shou= ld focus the discussion around developing objectives for each session. The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective. For example if continuous monitoring is = a priority and collectively it takes 3 days to work through all the objecti= ves, I see no problem with that. We can also keep a few sessions "on deck"= if all the objectives are reached and we complete all the scheduled sessio= ns early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov From: scap-dev@nist.gov [mailto:scap-dev@nist.gov= ] On Behalf Of Kent_Landfield@mcafee.com= Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation being sent out in advance, a webinar if it is felt there will be = questions and answers from those that are new to the efforts. We have a li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in ad= vance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas tha= t need real work by the community 4. Efforts to be discussed should be based on needs of the security autom= ation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d with. There are going to be things we need to do as a security automation= community to be able to accomplish what is listed in the CAESARS FE. Ther= e are interfaces that need to be worked and established. That is one area = that is not listed below. CM will have a major impact on all of us in the = next couple years and it is being ignored. We can't keep trying to solve w= hat has already been solved. We need to address the needed interface devel= opment now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +...) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e they are such a pain to manage from a content perspective. It is easier = to buy from one vendor that has a single means for distributing content tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that = is being underutilized and under implemented because of the limitations of = how it addresses uses in an enterprise environment. People don't need secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. Scheduling and tracking are key to it's success. We need to make that= happen. This too needs a focused brainstorming time box to discuss option= s. I am really disappointed that Remediation is not on the list below... Yes,= last Summer Dev Days, the time spent on Remediation was wasted time but th= at does not mean we should ignore it and not try to make some real progress= . As far as I am concerned we need to reboot the remediation effort. We c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. But today we think it is too hard so we don't try ? I think we need = a couple hours to discuss the reboot of the effort even if that means minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al Agencies. The initial effort was a mess, did little more than prove it = was possible and cause the vendor community a great deal of thrashing to pu= t a kludgey 'solution' in place. Reality is all our customers need roll up= reporting and an infrastructure that supports it. A data call should not = be special to anyone other than the agencies responding. The tools should b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces.... We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess while we are all in the same room. This is always a big event for the = 'consensus of the willing' that assemble and driven to see security automat= ion make a difference. Let's see if we can have an event that, when we all= walk out the last day, we all feel that every minute was well spent and mo= ves us forward. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng the week of July 9 - starting Monday at 10:00 AM and ending on Friday at= 12:00. Meanwhile, we are working on the agenda and are currently considering this = list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year's MITRE-hosted Security Automation Developer Days event will be h= eld during the week of July 9, 2012 at MITRE's facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. --_000_D7A0423E5E193F40BE6E94126930C4930B99201010MBCLUSTERxcha_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mike,

 

What about having webinars in-place of the 30 minute= briefs?

 

Regarding content management, we are building the prototype conte= nt repository for use in a production environment.=A0 As an open source pro= ject, it will be free for use by anyone interested.=A0 My thinking is that = this project can bridge the gap until commercial solutions are available to= augment it.=A0 This is a similar path that was followed with DNS (bind) an= d HTTP (apache).=A0 When it is ready for use, I am hoping to use it to host= USGCB content.=A0 You would be welcome to use it for your needs.

 <= /o:p>

It is go= od that OCIL is moving forward.=A0 This is an important piece of supporting= risk management and aspects of continuous monitoring.=A0 I would also like= to see some discussion on OCIL at Developer Days.=A0 With the proposals we= will likely have a sense of what needs to be discussed and what we can ach= ieve consensus on outside the meeting.

 

Remediation is a topic near and dea= r to my heart.=A0 I too would like to see it move forward.

 

We just publish= ed the draft ASR specification for public comment.=A0 This specification su= pports enterprise aggregate reporting which greatly reduces the data volume= s needed verses detailed host-based reports. This specification has been de= signed as a more robust replacement for LASR.=A0 It can be used in continuo= us monitoring applications to support aggregate data reporting needs (e.g. = FISMA reporting, =A0CyberScope).

=  

Here are the links:

=

 =

http://csrc.nist.gov/publications= /PubsDrafts.html

http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST= -IR-7848

 

The primary reason we have suggested waiting on XCCDF is not = the internationalization issue. Many vendors have commented that they are s= till working on implementing the XCCDF 1.2.1 specification. We will be in a= better place in a few months once more development around XCCDF has occurr= ed.=A0 As we consider changes to the SCAP stack to address OCIL and other i= ssues, we will identify areas that need improvement in XCCDF.=A0 These are = good and necessary discussions to have now, but we have a good deal of work= to do before we are ready to open up XCCDF.=A0 My suggestion is to work on= these related areas and then work up change proposals for XCCDF as needed.= =A0 By that time we should be ready to work on a new revision of XCCDF.

&= nbsp;

I = am also looking forward to the discussions at the conference.=A0 It has bee= n too long.

 

Sincerely,

Dave

 

From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mi= l]
Sent: Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEVCc: Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIS= T] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA<= o:p>

 

=

Kent,<= /p>

 

It’s good t= o read your thoughts, and a realistic actionable approach is indeed needed.=  Since all the activity hasn’t been on the lists a brief =BD ho= ur recap may be in order to bring everyone up to speed since there has been= a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.=

 

We could = write a content repository specification, but without someone willing to st= and one up it will be as valuable as the CCSS specification is today.  = ;I’ve been trying for two years to get my management to get a coordin= ated effort together for the DoD to stand up a repository, it is a tough pr= oblem and will require funding with a tail, I’m not sure a specificat= ion will solve that problem.

 

= We (DoD) have been putting a lot of effort in= to OCIL over the last year trying to make it useful in an enterprise enviro= nment and will be posting our ideas to the list before developer days it sh= ould have already started, we need to get consensus and a vote on how the c= ommunity wishes to proceed.

 

<= span style=3D'color:#1F497D'>Remediation is stalled but I’m making ev= ery effort to get it kick started from our perspective. I hope to assist in= getting the draft ERI finished this year.  We are writing some new ST= IG content and intend to used the draft CRE specification to insert CRE int= o the content so we (DoD) can do some automatic configuration fixes, part o= f a self healing network concept. It is just a start but the best we can do= at this point.

 

Enterprise reporting is an interesting subject, since XM= L adds size to and content to roll up reporting, in any enterprise of size = the problem gets greater, I look forward to your thoughts on that subject.<= o:p>

 

I am concerned that the internationalization efforts are detracting from e= fforts to meet use cases, we have some things we would like changed in XCCD= F to support our OCIl use case and I have been told that I need to wait. I = didn’t think that a move to internationalization should impede effort= s to move forward with use cases.

 

I look forward to talking with you at th= e conference.

 

v/r

 

Mike Kinney

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F49= 7D'>Project Director

Comput= er Network Defense Research and Technology (CND R&T) Office<= /span>

9800 Savage Road Ste 6767
Ft Meade, = MD 20755-6767
Phon= e: 410-854-4422
NSTS: 968-8886
Fax 410-854-4681

makinn2@nsa.go= v

 

=

 =

 

From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Waltermire, David A.Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipien= ts of list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation= Developer Days: Summer 2012 at MITRE in Bedford, MA

<= /div>

 

<= span style=3D'color:#1F497D'>Kent,

 

I like what you are saying here.  = We are also in support of this type of approach.  We would like to see= some community discussion around what are the key areas/priorities that th= e community would like to see discussed at Dev Days.  Your topics belo= w look like a good start. The SACM list might be a better venue than the OV= AL list for this discussion.  For each area we should focus the discus= sion around developing objectives for each session.  The sessions can = be time boxed based on what would be a reasonable amount of time to accompl= ish each objective.  For example if continuous monitoring is a priorit= y and collectively it takes 3 days to work through all the objectives, I se= e no problem with that.  We can also keep a few sessions “on dec= k” if all the objectives are reached and we complete all the schedule= d sessions early.

 

Thoughts?

 

Sincerely,

 

David Waltermire

= SCAP Architect

National Institute of Standards = and Technology

(301) 975-3390

david.waltermire@nist.gov

 

From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com
Sent: Mo= nday, May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [O= VAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITR= E in Bedford, MA

 

All,

 

I would like to discuss the format for t= he SCAP Developer Days that seems to be listed below.

=

 

I = see this appears to follow a path we have discussed in the past as the way = not to hold a Dev Days event.  We have been trying to get away from 'D= eath by Powerpoint' and back to the type of event we held years ago when we= were highly productive.  In the past we had a topic to be discussed a= nd a time box to work within.  That allowed us to have very active bra= instorming sessions in a high bandwidth environment.

<= /div>

 

At = past Summer events we have got into a pattern of lots of powerpoint, lots o= f status of the efforts and very little discussion about things that need a= ctive discussions.  We need to keep moving forward and making progress= as an effort. We can get status from various places such as the lists, a p= resentation being sent out in advance, a webinar if it is felt there will b= e questions and answers from those that are new to the efforts.  We ha= ve a limited amount of time and all who are attending are investing a great= deal of time and money to be there.  We should not  be spending = a great deal of time reeducating everyone when we could be focused on advan= cing needed efforts.

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

The type of approach to a Dev Days= event was discussed at the last Summer Dev Days.  I have seen the fol= lowing work quite well in other efforts.

  1. Presentations a= re sent out to the attendees and the lists a week in advance.
  2. Status for any effort is limi= ted to 30 minutes
  3. Efforts to be discussed should be based on needs of the se= curity automation space to move existing efforts to completion.<= /li>

For example:=

 

Continuous monitoring is a major direction the efforts = are becoming involved with. There are going to be things we need to do as a= security automation community to be able to accomplish what is listed in t= he CAESARS FE.  There are interfaces that need to be worked and establ= ished.  That is one area that is not listed below.  CM will have = a major impact on all of us in the next couple years and it is being ignore= d.  We can't keep trying to solve what has already been solved.  = We need to address the needed interface development now. This is an effort = that could take nearly a whole day by itself.

 

Operationa= lly we have a real need to be able to deliver SCAP content internally withi= n an organization. Today the SCAP vendors cannot share a single local site = security policy (XCCDF + OVAL + CPE +…) without the site staff having= to go to each of the individual products and figuring out how to inject th= at new or updated policy into that products delivery mechanisms.  That= is limiting sites from wanting to buy multiple focused SCAP products since= they are such a pain to manage from a content perspective.  It is eas= ier to buy from one vendor that has a single means for distributing content= than it is to deal with the management issues that having multiple SCAP pr= oducts presents.  We need to have at least an entire 1/2 a day on the = development of a Content Repository specification.

 <= /span>

OCIL = is a positive and a negative at the same time. It has real value that is be= ing underutilized and under implemented because of the limitations of how i= t addresses uses in an enterprise environment.  People don't need secu= rity automation to do things on/for a single host.  They need security= automation to focus on the enterprise issues that reduce their costs and i= mprove their efficiencies.  OCIL is failing in the enterprise and we a= ll understand that.  We need to address developing a definitive soluti= on for incorporating OCIL into the enterprise and that means into the exist= ing specifications. Scheduling and tracking are key to it's success.  = We need to make that happen.  This too needs a focused brainstorming t= ime box to discuss options.

 

I am really disappointed tha= t Remediation is not on the list below…  Yes, last Summer Dev Da= ys, the time spent on Remediation was wasted time but that does not mean we= should ignore it and not try to make some real progress.  As far as I= am concerned we need to reboot the remediation effort.  We cannot kee= p being the set of specifications / tools that act as the little boy crying= "Wolf" in the night.  We need to be able to find and fix is= sues if we are going to really make a difference in organizational security= postures.  But today we think it is too hard so we don't try ?  = I think we need a couple hours to discuss the reboot of the effort even if = that means minimizing work already done.

 

=

A focused discu= ssion on enterprise reporting is also critically needed.  For the vend= ors here, we have all gone through the Cyberscope goat rope, delivering lim= ited capabilities to specific data call requirements of the Federal Agencie= s.  The initial effort was a mess, did little more than prove it was p= ossible and cause the vendor community a great deal of thrashing to put a k= ludgey 'solution' in place.  Reality is all our customers need roll up= reporting and an infrastructure that supports it.  A data call should= not be special to anyone other than the agencies responding. The tools sho= uld be able to select the types of data needed and deliver that on a schedu= led basis automatically.    Enterprise Reporting pertains to comm= ercial as well as Federal customers.  We need to focus some time on wh= at that would look like using the ARF and ASR as the foundational pieces. &= nbsp;But there are missing pieces….  We need this discussed.

 

I would hope we can make this summer's SCAP Dev Days usefu= l in advancing the security automation efforts by addressing some of the mo= re critical issues our customers are facing now or will be facing in the ve= ry short term.  Status presentations are not interesting to those acti= ve in the efforts.  Let's try to do those before we get to Bedford so = we can real make some progress while we are all in the same room.  Thi= s is always a big event for the 'consensus of the willing' that assemble an= d driven to see security automation make a difference.  Let's see if w= e can have an event that, when we all walk out the last day, we all feel th= at every minute was well spent and moves us forward.

<= /div>

 

Tha= nks.

 

Kent Landfield
Director Content Strategy, Architecture and Standards

= McAfee | An Intel = Company
5000 Headquarters= Dr.
Plano, Texas 75024
=
Direct: +1.972.963.7096 
= Mobile: +1.817.637.8026
Web: www.mcafee.= com

 

From: <B= oczenowski>, Steve <sboczeno@MI= TRE.ORG>
Reply-To: "OVAL Developer List (Closed Publi= c Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@LISTS.M= ITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
Subject: Re: [OVAL= -DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE i= n Bedford, MA

=  

Frank;

 

We hope to have the registration site up next week.  The event = will be during the week of July 9 – starting Monday at 10:00 AM and e= nding on Friday at 12:00.

 

Meanwhile, we are working on the agenda and are curre= ntly considering this list of topics:

 = ;

CCE

CPE/SWID

CEE

= XCCDF=

OVAL

ASR

Ent= erprise OCIL

Cyb= OX/MAEC

Federate= d Content Repository Spec

Endpoint Reporting for Continuous Monitoring and Compliance (ERCC= )

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases

SCAP and IETF

<= span style=3D'color:#254061'>NETCONF and SCAP

 

Steve

 

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

From: Frank Lindsay Acker [mailto:af= rank@NOVA.EDU]
Sent: Tuesday, May 01, 2012 9:32 AM
To:= oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:= Summer 2012 at MITRE in Bedford, MA

 

Steve....

Has there been an= y additional information regarding this event?

Thanks,
Frank Acke= r

Fro= m: Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
<= b>To: OVAL-DEVEL= OPER-LIST@LISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Secu= rity Automation Developer Days: Summer 2012 at MITRE in Bedford, MA<= span style=3D'color:black'>

Save th= e Date: week of July 9, 2012

 =

This year’s MITRE-hosted Security Automation Developer Days even= t will be held during the week of July 9, 2012 at MITRE’s facility in= Bedford, MA.

 

Details to= follow.

 

Regards,

    Steve

 =

_________________= _____________________________=

Stephen P. Boczenowski

    =   The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-= 3849

    &nb= sp;sboczeno@mitre.o= rg

 =

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST= in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-req= uest@LISTS.MITRE.ORG.

<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:= black'>To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-L= IST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST= -request@LISTS.MITRE.ORG.

To unsubscribe, send an email mess= age to LISTSERV@LISTS.MITRE.ORG= with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you ha= ve difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. <= /span>

= --_000_D7A0423E5E193F40BE6E94126930C4930B99201010MBCLUSTERxcha_-- From m.kinne@radium.ncsc.mil Tue May 8 09:34: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 328B121F8495 for ; Tue, 8 May 2012 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.358 X-Spam-Level: X-Spam-Status: No, score=-9.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcVxsXbArnCT for ; Tue, 8 May 2012 09:34:26 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8B08E21F843E for ; Tue, 8 May 2012 09:34:25 -0700 (PDT) X-TM-IMSS-Message-ID: <2e98a089000bce6f@nsa.gov> Received: from MSCS-GH1-UEA01.corp.nsa.gov ([10.215.224.47]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 2e98a089000bce6f ; Tue, 8 May 2012 12:34:34 -0400 Received: from MSIS-GH1-UEA10.corp.nsa.gov ([10.215.229.132]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2012 12:34:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 8 May 2012 12:34:18 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A1_01CD2D16.E20548E0" Message-ID: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Thread-Index: Ac0spojaQDLCQzcmSvqRdyTN8pGVawAYGTOAAAbpivAABRrrQA== References: <8E41D51B05B4EE4CA29C7DBDDA5B5B0E185C48@IMCMBX03.MITRE.ORG> <15D0981C9BE53042A4C9D0F3D0B6826B2900EC@MSIS-GH1-UEA10.corp.nsa.gov> From: "Kinney, Michael A" To: "Waltermire, David A." , "SCAP-DEV" , X-OriginalArrivalTime: 08 May 2012 16:34:18.0847 (UTC) FILETIME=[6A4D1EF0:01CD2D38] X-Mailman-Approved-At: Tue, 08 May 2012 12:18:30 -0700 Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA 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, 08 May 2012 19:02:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01CD2D16.E20548E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A2_01CD2D16.E20548E0" ------=_NextPart_001_00A2_01CD2D16.E20548E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, I have no problem with webinars, I do want to keep developer days = actionable and use it to make decisions, and vote and accomplish things good or = bad. I do not want this to be an informational briefing conference. Thanks for the links. =20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful = for everyone. We need to talk more=85 =20 -Mike =20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 Regarding content management, we are building the prototype content repository for use in a production environment. As an open source = project, it will be free for use by anyone interested. My thinking is that this project can bridge the gap until commercial solutions are available to augment it. This is a similar path that was followed with DNS (bind) = and HTTP (apache). When it is ready for use, I am hoping to use it to host USGCB content. You would be welcome to use it for your needs. =20 It is good that OCIL is moving forward. This is an important piece of supporting risk management and aspects of continuous monitoring. I = would also like to see some discussion on OCIL at Developer Days. With the proposals we will likely have a sense of what needs to be discussed and = what we can achieve consensus on outside the meeting. =20 Remediation is a topic near and dear to my heart. I too would like to = see it move forward. =20 We just published the draft ASR specification for public comment. This specification supports enterprise aggregate reporting which greatly = reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR. = It can be used in continuous monitoring applications to support aggregate = data reporting needs (e.g. FISMA reporting, CyberScope). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are = still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred. As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF. = These are good and necessary discussions to have now, but we have a good deal = of work to do before we are ready to open up XCCDF. My suggestion is to = work on these related areas and then work up change proposals for XCCDF as needed. By that time we should be ready to work on a new revision of = XCCDF. =20 I am also looking forward to the discussions at the conference. It has = been too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]=20 Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 It=92s good to read your thoughts, and a realistic actionable approach = is indeed needed. Since all the activity hasn=92t been on the lists a = brief =BD hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. =20 We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification = is today. I=92ve been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is = a tough problem and will require funding with a tail, I=92m not sure a specification will solve that problem. =20 We (DoD) have been putting a lot of effort into OCIL over the last year trying to make it useful in an enterprise environment and will be = posting our ideas to the list before developer days it should have already = started, we need to get consensus and a vote on how the community wishes to = proceed. =20 Remediation is stalled but I=92m making every effort to get it kick = started from our perspective. I hope to assist in getting the draft ERI finished this year. We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can = do some automatic configuration fixes, part of a self healing network = concept. It is just a start but the best we can do at this point. =20 Enterprise reporting is an interesting subject, since XML adds size to = and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject. =20 I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to = wait. I didn=92t think that a move to internationalization should impede = efforts to move forward with use cases. =20 I look forward to talking with you at the conference. =20 v/r =20 Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov =20 =20 =20 From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 I like what you are saying here. We are also in support of this type of approach. We would like to see some community discussion around what = are the key areas/priorities that the community would like to see discussed = at Dev Days. Your topics below look like a good start. The SACM list might = be a better venue than the OVAL list for this discussion. For each area we should focus the discussion around developing objectives for each = session. The sessions can be time boxed based on what would be a reasonable = amount of time to accomplish each objective. For example if continuous monitoring = is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that. We can also keep a few sessions = =93on deck=94 if all the objectives are reached and we complete all the = scheduled sessions early. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 All, =20 I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. =20 I see this appears to follow a path we have discussed in the past as the = way not to hold a Dev Days event. We have been trying to get away from = 'Death by Powerpoint' and back to the type of event we held years ago when we = were highly productive. In the past we had a topic to be discussed and a = time box to work within. That allowed us to have very active brainstorming sessions in a high bandwidth environment. =20 At past Summer events we have got into a pattern of lots of powerpoint, = lots of status of the efforts and very little discussion about things that = need active discussions. We need to keep moving forward and making progress = as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. We = have a limited amount of time and all who are attending are investing a great = deal of time and money to be there. We should not be spending a great deal = of time reeducating everyone when we could be focused on advancing needed efforts. =20 The type of approach to a Dev Days event was discussed at the last = Summer Dev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in advance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas that need real work by the community 4. Efforts to be discussed should be based on needs of the security automation space to move existing efforts to completion. For example: =20 Continuous monitoring is a major direction the efforts are becoming = involved with. There are going to be things we need to do as a security = automation community to be able to accomplish what is listed in the CAESARS FE. = There are interfaces that need to be worked and established. That is one area that is not listed below. CM will have a major impact on all of us in = the next couple years and it is being ignored. We can't keep trying to = solve what has already been solved. We need to address the needed interface development now. This is an effort that could take nearly a whole day by itself. =20 Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +=85) without the = site staff having to go to each of the individual products and figuring out = how to inject that new or updated policy into that products delivery = mechanisms. That is limiting sites from wanting to buy multiple focused SCAP = products since they are such a pain to manage from a content perspective. It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having = multiple SCAP products presents. We need to have at least an entire 1/2 a day on = the development of a Content Repository specification. =20 OCIL is a positive and a negative at the same time. It has real value = that is being underutilized and under implemented because of the limitations = of how it addresses uses in an enterprise environment. People don't need security automation to do things on/for a single host. They need = security automation to focus on the enterprise issues that reduce their costs and improve their efficiencies. OCIL is failing in the enterprise and we = all understand that. We need to address developing a definitive solution = for incorporating OCIL into the enterprise and that means into the existing specifications. Scheduling and tracking are key to it's success. We = need to make that happen. This too needs a focused brainstorming time box to discuss options. =20 I am really disappointed that Remediation is not on the list below=85 = Yes, last Summer Dev Days, the time spent on Remediation was wasted time but = that does not mean we should ignore it and not try to make some real = progress. As far as I am concerned we need to reboot the remediation effort. We cannot keep being the set of specifications / tools that act as the = little boy crying "Wolf" in the night. We need to be able to find and fix = issues if we are going to really make a difference in organizational security postures. But today we think it is too hard so we don't try ? I think = we need a couple hours to discuss the reboot of the effort even if that = means minimizing work already done. =20 A focused discussion on enterprise reporting is also critically needed. = For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of = the Federal Agencies. The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of thrashing = to put a kludgey 'solution' in place. Reality is all our customers need = roll up reporting and an infrastructure that supports it. A data call should = not be special to anyone other than the agencies responding. The tools = should be able to select the types of data needed and deliver that on a scheduled basis automatically. Enterprise Reporting pertains to commercial as = well as Federal customers. We need to focus some time on what that would = look like using the ARF and ASR as the foundational pieces. But there are missing pieces=85. We need this discussed. =20 I would hope we can make this summer's SCAP Dev Days useful in advancing = the security automation efforts by addressing some of the more critical = issues our customers are facing now or will be facing in the very short term. Status presentations are not interesting to those active in the efforts. Let's try to do those before we get to Bedford so we can real make some progress while we are all in the same room. This is always a big event = for the 'consensus of the willing' that assemble and driven to see security automation make a difference. Let's see if we can have an event that, = when we all walk out the last day, we all feel that every minute was well = spent and moves us forward. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Frank; =20 We hope to have the registration site up next week. The event will be during the week of July 9 =96 starting Monday at 10:00 AM and ending on = Friday at 12:00. =20 Meanwhile, we are working on the agenda and are currently considering = this list of topics: =20 CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker _____ =20 From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 =20 This year=92s MITRE-hosted Security Automation Developer Days event will = be held during the week of July 9, 2012 at MITRE=92s facility in Bedford, = MA. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 ------=_NextPart_001_00A2_01CD2D16.E20548E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dave,

I have no problem with = webinars, I do want to keep developer days actionable and use it to make = decisions, and vote and accomplish things good or bad.=A0 I do not want = this to be an informational briefing conference.

Thanks for the = links.

 

I still think that any = specification for a repository is wishful thinking until someone builds = one and learns the lessons it will just be another whitepaper spec. =A0I = believe the DoD needs to incorporate a metadata repository as part of it = and other customizations that may not be useful for = everyone.

We need to talk = more…

 

-Mike=A0 =

 

From:= = Waltermire, David A. [mailto:david.waltermire@nist.gov]
Sent: = Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michael A; = SCAP-DEV; sacm@ietf.org
Subject: RE: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Mike,

 

What about having = webinars in-place of the 30 minute briefs?

 

Regarding content = management, we are building the prototype content repository for use in = a production environment.  As an open source project, it will be = free for use by anyone interested.  My thinking is that this = project can bridge the gap until commercial solutions are available to = augment it.  This is a similar path that was followed with DNS = (bind) and HTTP (apache).  When it is ready for use, I am hoping to = use it to host USGCB content.  You would be welcome to use it for = your needs.

 

It is good that OCIL is = moving forward.  This is an important piece of supporting risk = management and aspects of continuous monitoring.  I would also like = to see some discussion on OCIL at Developer Days.  With the = proposals we will likely have a sense of what needs to be discussed and = what we can achieve consensus on outside the = meeting.

 

Remediation is a topic = near and dear to my heart.  I too would like to see it move = forward.

 

We just published the = draft ASR specification for public comment.  This specification = supports enterprise aggregate reporting which greatly reduces the data = volumes needed verses detailed host-based reports. This specification = has been designed as a more robust replacement for LASR.  It can be = used in continuous monitoring applications to support aggregate data = reporting needs (e.g. FISMA reporting, =  CyberScope).

 

Here are the = links:

 

http://csrc.ni= st.gov/publications/PubsDrafts.html

= http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848<= /o:p>

 

The primary reason we = have suggested waiting on XCCDF is not the internationalization issue. = Many vendors have commented that they are still working on implementing = the XCCDF 1.2.1 specification. We will be in a better place in a few = months once more development around XCCDF has occurred.  As we = consider changes to the SCAP stack to address OCIL and other issues, we = will identify areas that need improvement in XCCDF.  These are good = and necessary discussions to have now, but we have a good deal of work = to do before we are ready to open up XCCDF.  My suggestion is to = work on these related areas and then work up change proposals for XCCDF = as needed.  By that time we should be ready to work on a new = revision of XCCDF.

 

I am also looking = forward to the discussions at the conference.  It has been too = long.

 

Sincerely,

Dave

 

From:= = Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]
Sent: = Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: = Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Kent,

 

It’s good to read = your thoughts, and a realistic actionable approach is indeed needed. =  Since all the activity hasn’t been on the lists a brief =BD = hour recap may be in order to bring everyone up to speed since there has = been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and = others.

 

We could write a content = repository specification, but without someone willing to stand one up it = will be as valuable as the CCSS specification is today.  I’ve = been trying for two years to get my management to get a coordinated = effort together for the DoD to stand up a repository, it is a tough = problem and will require funding with a tail, I’m not sure a = specification will solve that problem.

 

We (DoD) have been = putting a lot of effort into OCIL over the last year trying to make it = useful in an enterprise environment and will be posting our ideas to the = list before developer days it should have already started, we need to = get consensus and a vote on how the community wishes to = proceed.

 

Remediation is stalled = but I’m making every effort to get it kick started from our = perspective. I hope to assist in getting the draft ERI finished this = year.  We are writing some new STIG content and intend to used the = draft CRE specification to insert CRE into the content so we (DoD) can = do some automatic configuration fixes, part of a self healing network = concept. It is just a start but the best we can do at this = point.

 

Enterprise reporting is = an interesting subject, since XML adds size to and content to roll up = reporting, in any enterprise of size the problem gets greater, I look = forward to your thoughts on that subject.

 

I am concerned that the = internationalization efforts are detracting from efforts to meet use = cases, we have some things we would like changed in XCCDF to support our = OCIl use case and I have been told that I need to wait. I didn’t = think that a move to internationalization should impede efforts to move = forward with use cases.

 

I look forward to = talking with you at the conference.

 

v/r

 

Mike Kinney

Project Director

Computer Network Defense Research and Technology (CND R&T) = Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: = 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

 

From:= = scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A.
Sent: Monday, May = 07, 2012 7:09 PM
To: Multiple recipients of = list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation = Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Kent,

 

I like what you are = saying here.  We are also in support of this type of = approach.  We would like to see some community discussion around = what are the key areas/priorities that the community would like to see = discussed at Dev Days.  Your topics below look like a good start. = The SACM list might be a better venue than the OVAL list for this = discussion.  For each area we should focus the discussion around = developing objectives for each session.  The sessions can be time = boxed based on what would be a reasonable amount of time to accomplish = each objective.  For example if continuous monitoring is a priority = and collectively it takes 3 days to work through all the objectives, I = see no problem with that.  We can also keep a few sessions = “on deck” if all the objectives are reached and we complete = all the scheduled sessions early.

 

Thoughts?

 

Sincerely,

 

David Waltermire

SCAP = Architect

National Institute of Standards and = Technology

(301) 975-3390

david.waltermire@nist.gov

 

From:= = scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.comSent: Monday, May 07, 2012 4:25 PM
To: = SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

All,

 

I would like to discuss = the format for the SCAP Developer Days that seems to be listed = below.

 

I see this appears to = follow a path we have discussed in the past as the way not to hold a Dev = Days event.  We have been trying to get away from 'Death by = Powerpoint' and back to the type of event we held years ago when we were = highly productive.  In the past we had a topic to be discussed and = a time box to work within.  That allowed us to have very active = brainstorming sessions in a high bandwidth = environment.

 

At past Summer events we = have got into a pattern of lots of powerpoint, lots of status of the = efforts and very little discussion about things that need active = discussions.  We need to keep moving forward and making progress as = an effort. We can get status from various places such as the lists, a = presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. =  We have a limited amount of time and all who are attending are = investing a great deal of time and money to be there.  We should = not  be spending a great deal of time reeducating everyone when we = could be focused on advancing needed = efforts.

 

The type of approach to a = Dev Days event was discussed at the last Summer Dev Days.  I have = seen the following work quite well in other = efforts.

  1. Presentations are sent out to the attendees and = the lists a week in advance.
  2. Status for any effort is limited to 30 = minutes
  3. Focused brainstorming time should be established = for certain areas that need real work by the = community
  4. Efforts to be discussed should be based on needs = of the security automation space to move existing efforts to = completion.

For example:

 

Continuous monitoring is a = major direction the efforts are becoming involved with. There are going = to be things we need to do as a security automation community to be able = to accomplish what is listed in the CAESARS FE.  There are = interfaces that need to be worked and established.  That is one = area that is not listed below.  CM will have a major impact on all = of us in the next couple years and it is being ignored.  We can't = keep trying to solve what has already been solved.  We need to = address the needed interface development now. This is an effort that = could take nearly a whole day by = itself.

 

Operationally we have a = real need to be able to deliver SCAP content internally within an = organization. Today the SCAP vendors cannot share a single local site = security policy (XCCDF + OVAL + CPE +…) without the site staff = having to go to each of the individual products and figuring out how to = inject that new or updated policy into that products delivery = mechanisms.  That is limiting sites from wanting to buy multiple = focused SCAP products since they are such a pain to manage from a = content perspective.  It is easier to buy from one vendor that has = a single means for distributing content than it is to deal with the = management issues that having multiple SCAP products presents.  We = need to have at least an entire 1/2 a day on the development of a = Content Repository specification.

 

OCIL is a positive and a = negative at the same time. It has real value that is being underutilized = and under implemented because of the limitations of how it addresses = uses in an enterprise environment.  People don't need security = automation to do things on/for a single host.  They need security = automation to focus on the enterprise issues that reduce their costs and = improve their efficiencies.  OCIL is failing in the enterprise and = we all understand that.  We need to address developing a definitive = solution for incorporating OCIL into the enterprise and that means into = the existing specifications. Scheduling and tracking are key to it's = success.  We need to make that happen.  This too needs a = focused brainstorming time box to discuss = options.

 

I am really disappointed = that Remediation is not on the list below…  Yes, last Summer = Dev Days, the time spent on Remediation was wasted time but that does = not mean we should ignore it and not try to make some real progress. =  As far as I am concerned we need to reboot the remediation effort. =  We cannot keep being the set of specifications / tools that act as = the little boy crying "Wolf" in the night.  We need to be = able to find and fix issues if we are going to really make a difference = in organizational security postures.  But today we think it is too = hard so we don't try ?  I think we need a couple hours to discuss = the reboot of the effort even if that means minimizing work already = done.

 

A focused discussion on = enterprise reporting is also critically needed.  For the vendors = here, we have all gone through the Cyberscope goat rope, delivering = limited capabilities to specific data call requirements of the Federal = Agencies.  The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of = thrashing to put a kludgey 'solution' in place.  Reality is all our = customers need roll up reporting and an infrastructure that supports it. =  A data call should not be special to anyone other than the = agencies responding. The tools should be able to select the types of = data needed and deliver that on a scheduled basis automatically.   =  Enterprise Reporting pertains to commercial as well as Federal = customers.  We need to focus some time on what that would look like = using the ARF and ASR as the foundational pieces.  But there are = missing pieces….  We need this = discussed.

 

I would hope we can make = this summer's SCAP Dev Days useful in advancing the security automation = efforts by addressing some of the more critical issues our customers are = facing now or will be facing in the very short term.  Status = presentations are not interesting to those active in the efforts. =  Let's try to do those before we get to Bedford so we can real make = some progress while we are all in the same room.  This is always a = big event for the 'consensus of the willing' that assemble and driven to = see security automation make a difference.  Let's see if we can = have an event that, when we all walk out the last day, we all feel that = every minute was well spent and moves us = forward.

 

Thanks.

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

 

From: = <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply= -To: "OVAL Developer List (Closed Public Discussion)" = <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Frank;

 

We hope to have the registration site up next = week.  The event will be during the week of July 9 – starting = Monday at 10:00 AM and ending on Friday at 12:00.

 

Meanwhile, we are working on the agenda and are = currently considering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise = OCIL

CybOX/MAEC

Federated = Content Repository Spec

Endpoint = Reporting for Continuous Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for = SCAP

IF-MAP

SCAP = Releases

SCAP and IETF

NETCONF and = SCAP

 

Steve

 

= From:= Frank Lindsay Acker [mailto:afrank@NOVA.EDU] =
Sent: Tuesday, May 01, 2012 9:32 AM
To: = oval-developer-list OVAL Developer List/Closed Public = Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

= Steve....

Has there been any additional information regarding = this event?

Thanks,
Frank Acker

= From:= Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

Save the Date: week of July 9, = 2012

 

This year’s = MITRE-hosted Security Automation Developer Days event will be held = during the week of July 9, 2012 at MITRE’s facility in Bedford, = MA.

 

Details to = follow.

 

Regards,

    Steve

 

= ______________________________________________

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG. =

------=_NextPart_001_00A2_01CD2D16.E20548E0-- ------=_NextPart_000_00A1_01CD2D16.E20548E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRbzCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIELzCCAxegAwIBAgIDK7YlMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjAwHhcNMDkwOTI4MDAwMDAwWhcN MTIwOTI3MjM1OTU5WjB6MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDT1NEMScwJQYDVQQDEx5LSU5ORVku TUlDSEFFTC5BTEFOLjExOTI1Mzk4NTAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJJ8Qtiv fKHUqYHJYW7ZNYAkrIeR0S2Ag9wUyl53wnghFTWZciTBUwsOtbXTqaX8njoxZVDo2ojvdb1//Jx0 R49T8Qrkd1mUjhFYoC5xK5s0U/NWLleAuy+lio+fofWTJLz4R5ekWjU0KfsYliMBtFQJkfaDGW3k b99if6jMDVJDAgMBAAGjggFdMIIBWTAfBgNVHSMEGDAWgBSyv24AbblASS9gCvR41XmEJakxujA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9ET0QlMjBFTUFJTCUy MENBLTIwMA4GA1UdDwEB/wQEAwIFIDAWBgNVHSAEDzANMAsGCWCGSAFlAgELCTAdBgNVHQ4EFgQU VTBSD3U2HbwcQdk+sn6AnUowodQwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8v Y3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yMDAgBggrBgEFBQcwAYYUaHR0 cDovL29jc3AuZGlzYS5taWwwIgYDVR0RBBswGYEXbS5raW5uZUByYWRpdW0ubmNzYy5taWwwGwYD VR0JBBQwEjAQBggrBgEFBQcJBDEEEwJVUzANBgkqhkiG9w0BAQUFAAOCAQEAZieGCENpai/zGUAd ozpxH0xPpvRB12r6i1xDKbXEqbOIgmIm0TieqZ6+AzJiux3sepabEqKHaeuCeasXQYPDhHowfslH QEZUhOk//yeQHpGaAILILm7qAWZxCo2ZzORqkLfiUGyYTZiCpChYYzFZ06QKLMgu/c+siPYPkRB4 jWsxWaXy+O0hTEzW0rJrSvHibwhhmIUpu4asTI0dUzdabDrUDHeTRFP5ODik9iHS+Qq8F5SN217H XZMPYWOuo9llENS5TKrRmKzDKTbf6qINm8+a0Z4+Q0tx4Vir+Evg7Fvp2qqIYzsNJigtA7gvRc/m Uch9TzTgLoeVoUxY8y8BQTCCBHowggNioAMCAQICAyu2HTANBgkqhkiG9w0BAQUFADBdMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIwMB4XDTA5MDkyODAwMDAwMFoXDTEyMDkyNzIz NTk1OVowejELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMD RG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA09TRDEnMCUGA1UEAxMeS0lOTkVZLk1JQ0hBRUwu QUxBTi4xMTkyNTM5ODUwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZ/Cz/otL0tbCthpKC hOBg5bCJxl1nHPkQ17f6Cbdq3pPYk2dPjSSdH6JlsMbIsPxHUkEtAqchGvU72lXqPY1J5edBpvJF X05ANTPEbU6BRu820jgwnkZUGilfB4S3MsRY7uQjbfSwJoHcHXeyTalgnmCnP6V0A9s5pnO7jNsl dwIDAQABo4IBqDCCAaQwHwYDVR0jBBgwFoAUsr9uAG25QEkvYAr0eNV5hCWpMbowPwYDVR0fBDgw NjA0oDKgMIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RE9EJTIwRU1BSUwlMjBDQS0yMDAO BgNVHQ8BAf8EBAMCBsAwFgYDVR0gBA8wDTALBglghkgBZQIBCwkwHQYDVR0OBBYEFB4xOCjbEzXK +N+f+UMnn/d933i8MG0GCCsGAQUFBwEBBGEwXzA7BggrBgEFBQcwAoYvaHR0cDovL2NybC5kaXNh Lm1pbC9nZXRzaWduP0RPRCUyMEVNQUlMJTIwQ0EtMjAwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3Nw LmRpc2EubWlsMEIGA1UdEQQ7MDmBF20ua2lubmVAcmFkaXVtLm5jc2MubWlsoB4GCisGAQQBgjcU AgOgEAwOMTE5MjUzOTg1MEBtaWwwGwYDVR0JBBQwEjAQBggrBgEFBQcJBDEEEwJVUzApBgNVHSUE IjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQEFBQADggEBAA3v Xw4DSRXCHOvkjDbUWBy+PaO2l+EFfSbgctV3jXOb3MC3ZePpoYvF4ojB1h1VeCgULS8zaslfVtAN 7dalhNZcsGQwsZy1RG5JAciimx5GuRbp1kbW6C/ruAhqNoldvNeOMotz9xwcIijf3wq9lmduaGD/ txCgc0MSvl9CXbMy55n7Vcxq/pA2kEUPQEsMf2/5KZYaF7chqQon+7pfd5wJq3+/+gXVOGKB7DyG i3kLS6ndSWLxp6vYujYLYmSkTzFkStvItD4F3Gz/+QxpzUNzUOoMmxrYfjZcG1llKXWIWSGyTR7a lHeCcxloeEM9A8RCCoDN4pYR1U5fVyobef8wggVGMIIELqADAgECAgErMA0GCSqGSIb3DQEBBQUA MFsxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTA4MDQyMzIxMDg1NloXDTE0 MDQyMzIwMDg1NlowXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoG A1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yMDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALcakIkcgAvbobol7C6j9i0BiFXmFtFPnclTnKYp+YhB 8d2dMiafBzMhtkdBAiA8pdJKy7vLgU9hQdD2yO5opsb3eHq0LFAd/osytloyeZEwUfAhSpipEtMu dJlP5vrVuCeI+MkhoMWzfbdWqnuXQ5wgNE6BiTqOPBYSjLuos4xg13m87+ErtHyRBCeOc05INALl +660zoOd2JXkFPgz3zasTvjpUjnXVuQywk1uSDdv9eVGNxJjMknCT4v+NJnI7Pjm366GoH89SCBj pEktQT7+nUJ8gUbmHZLjdNICCFSIYCtlMalzgPqX+Go21IMrZPDNYWHhwliUtsriMbLZGmECAwEA AaOCAhEwggINMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBw ljAdBgNVHQ4EFgQUsr9uAG25QEkvYAr0eNV5hCWpMbowDAYDVR0kBAUwA4ABADASBgNVHRMBAf8E CDAGAQH/AgEAMFcGA1UdIARQME4wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIB CwowCwYJYIZIAWUCAQsSMAsGCWCGSAFlAgELEzALBglghkgBZQIBCxQwPwYDVR0fBDgwNjA0oDKg MIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RG9EJTIwUm9vdCUyMENBJTIwMjCB/gYIKwYB BQUHAQEEgfEwge4wPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0SXNzdWVkVG8/ RG9EJTIwUm9vdCUyMENBJTIwMjAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgYgG CCsGAQUFBzAChnxsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUy MDIlMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVT P2NBQ2VydGlmaWNhdGU7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQBtBWU/wdnV8bIG1gjNjuWL oOZGAn2lpmSbLxMStAGYofWMOoFLBSOm7c3rsAUrRDFOBNdtQx3aKVGr+cGvlnThaB5IT05cvMqw JEOi7EArEQLbCCNclbw1djXQYrF28tk5/8C12KjbrqFp+qX+XfQ+BbUMhffMPtDCsERbCcPmg1zO Lkt1KKn47VgslkudJga9doaNNyQkVB3PzBdRCPCGknxHv7ft+zhdFG4u6lPTquGu+yaQ9Pr071lr dW8vKFmbHx6+153erlVdKxSfFpoLcIbzkULTI2ii8r82N68UuoBvYUcyvodMd3luqFnMxBcUOSO9 riGc/bm6+HPc4KcaMYICsTCCAq0CAQEwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBH b3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlM IENBLTIwAgMrth0wCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIwNTA4MTYzNDE2WjAjBgkqhkiG9w0BCQQxFgQUrAt1F0n0N6GH+GjsxYgN 6zFqRJ0wWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBd MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIwAgMrtiUwdQYLKoZIhvcNAQkQAgsx ZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0Rv RDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjACAyu2JTANBgkqhkiG9w0B AQEFAASBgBq/4y6RqvCJO6uo3M7pjhpOZO/MsxC34J+Iv4LeAH9ZVh/bowinYkn+6iPwPZZA8ba0 W69ngVjZEUoOU4qJQUwLqp7RJhjB0CqMqDwkLm+tOu10kjMzX2wkAd45OltwNTpfF9DdclWlpcHU 6mNEvQ4u7YTqlgvFfx4TvOviskPFAAAAAAAA ------=_NextPart_000_00A1_01CD2D16.E20548E0-- From david.waltermire@nist.gov Fri May 11 09:24: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 CA2A621F859E for ; Fri, 11 May 2012 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmI0qnCTCB76 for ; Fri, 11 May 2012 09:24:19 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0121F857A for ; Fri, 11 May 2012 09:24:18 -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.355.2; Fri, 11 May 2012 12:24:05 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 11 May 2012 12:24:14 -0400 From: "Waltermire, David A." To: Anton Chuvakin Date: Fri, 11 May 2012 12:24:13 -0400 Thread-Topic: [sacm] Use Cases Thread-Index: Ac0qHgA4LA3ln5SmRAq/jw54IuLt4AFc8qKA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases 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, 11 May 2012 16:24:19 -0000 I am currently working to update the use cases document based on the feedba= ck. You had mentioned below that you would like to see timed and non-timed= data logically separated. Are you talking about real-time vs. periodic da= ta? If so, would it be adequate to identify where data with different temp= oral characteristics is used in each use case? Sincerely, Dave -----Original Message----- From: anton.chuvakin@gmail.com [mailto:anton.chuvakin@gmail.com] On Behalf = Of Anton Chuvakin Sent: Friday, May 04, 2012 1:48 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases >> I think these is a mix of monitoring (activity, behavior, events) and as= sessment (controls, settings, configurations) use cases, is this intentiona= l? > Yes. =A0To some extent there is a compositional relationship between the = use cases. =A0UC 1 & 2 provide data collection (assessment) that can be use= d for UC 3 and UC 5 which focus on monitoring. =A0UC 4 provides reporting c= apabilities based on UC 3 and 5. That makes sense - in general, I'd feel more comfortable is state/control/= configuration/assessment/non-timed data is more logically separated from ac= tivity/event/behavior/logs/timed data. -- Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From Kent_Landfield@mcafee.com Fri May 11 09:36: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 6299521F85D5 for ; Fri, 11 May 2012 09:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YthAdHBxZ0Fo for ; Fri, 11 May 2012 09:36:06 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id E26C921F862F for ; Fri, 11 May 2012 09:36:05 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 31ea_022a_4ffb818d_02d6_4833_9f1a_87b15dcec445; Fri, 11 May 2012 11:35:52 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Fri, 11 May 2012 11:35:00 -0500 From: To: , , , Date: Fri, 11 May 2012 11:35:38 -0500 Thread-Topic: Request for participants - Content Repository Specification Development Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQ== Message-ID: In-Reply-To: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD0067532964kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: [sacm] Request for participants - Content Repository Specification Development 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, 11 May 2012 16:36:09 -0000 --_000_CBD0067532964kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mike I love it when you tee something up like that=85. ;-) Thank you. ;) Mike wrote: I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more=85 If you are talking about a holistic, complete federated approach to a conte= nt repository, I some what agree. If you are talking about an organization= al repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and oth= er related content to be served up inside an organization. Today we have s= ituation where the standards allow us to provide sites the capability to ha= ve a single SCAP implemented policy they call official for their environmen= t. Yes this is a rather simplistic since there are things such as targeting= specific platforms, specific operational use needs, but for now lets agree= SCAP is a massive improvement over the proprietary situations of the past.= While we have created this standard content so that sites can implement th= eir local site security once and then assure they are measuring all appropr= iately targeted devices the same way, we have failed to support the operati= onal needs of the sites. We have a situation where no two vendors distribu= te content the same way. This causes massive problems for the administrati= on staff when they need to incorporate a new SCAP enabled product into thei= r architecture. They need to discover how the new product supports distrib= uting SCAP content to it's various components. If they have one product th= en they do this one and they are done. If they have multiple products they= will have to figure out how to minimize the impact by incorporating the up= date process for the new product into the existing SCAP security content pr= ocesses. Now when the inevitable happens and the site staff needs to make a= change to their security policy, they have to make the modifications to th= e benchmark or checks or both and then distribute those updates across thei= r network. For each SCAP enabled product they have in place, they have dou= bled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Conte= nt Distribution. If you think global DNS you have a general frame of refer= ence. The guidance authors need to be able to publish content in an author= itative manner so their content is updated in a timely fashion. This is a = much harder problem to solve if there is no local organizational infrastruc= ture to support it. ;) So here is what I am thinking=85 We should consider addressing these as tw= o separate but integrated efforts. I believe the Organizational Content Re= pository is the more critical piece that is actually easier to address. Th= e Federated Content Distribution should be a subsequent effort integrating = / augmenting the Organizational repository specification. Mike, to your point that we need someone to build one first=85 That has hap= pened already. I have one as do other vendors but what we don=92t have is = the access specification. Ours are focused on our specific product needs. = Additionally there is a company that has developed a commercial SCAP conte= nt repository that will be announced later this month. I won't steal their = thunder but I was recently given a sneak peek at it and I must admit I was = very impressed. Again, to your point, it has been done. What is needed to = address the initial operational problem is to develop a specification that = provides a consistent means for all SCAP products to retrieve the appropria= te content as configured and managed but the site. TO THAT END=85. I am requesting participation from those in the community that see the need= and want to put in the work to make this specification happen. I have tal= ked to a couple of you but I do not want to assume your participation. If = you are interested please contact me so we can get this started. Thanks! Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Michael A > To: David Waltermire >, SCAP-DEV >, "sacm@ietf= .org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionabl= e and use it to make decisions, and vote and accomplish things good or bad.= I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more=85 -Mike From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content reposit= ory for use in a production environment. As an open source project, it wil= l be free for use by anyone interested. My thinking is that this project c= an bridge the gap until commercial solutions are available to augment it. = This is a similar path that was followed with DNS (bind) and HTTP (apache).= When it is ready for use, I am hoping to use it to host USGCB content. Y= ou would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supp= orting risk management and aspects of continuous monitoring. I would also = like to see some discussion on OCIL at Developer Days. With the proposals = we will likely have a sense of what needs to be discussed and what we can a= chieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see = it move forward. We just published the draft ASR specification for public comment. This spe= cification supports enterprise aggregate reporting which greatly reduces th= e data volumes needed verses detailed host-based reports. This specificatio= n has been designed as a more robust replacement for LASR. It can be used = in continuous monitoring applications to support aggregate data reporting n= eeds (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internatio= nalization issue. Many vendors have commented that they are still working o= n implementing the XCCDF 1.2.1 specification. We will be in a better place = in a few months once more development around XCCDF has occurred. As we con= sider changes to the SCAP stack to address OCIL and other issues, we will i= dentify areas that need improvement in XCCDF. These are good and necessary= discussions to have now, but we have a good deal of work to do before we a= re ready to open up XCCDF. My suggestion is to work on these related areas= and then work up change proposals for XCCDF as needed. By that time we sh= ould be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has bee= n too long. Sincerely, Dave From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, It=92s good to read your thoughts, and a realistic actionable approach is i= ndeed needed. Since all the activity hasn=92t been on the lists a brief 1= =8E2 hour recap may be in order to bring everyone up to speed since there h= as been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone will= ing to stand one up it will be as valuable as the CCSS specification is tod= ay. I=92ve been trying for two years to get my management to get a coordin= ated effort together for the DoD to stand up a repository, it is a tough pr= oblem and will require funding with a tail, I=92m not sure a specification = will solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year try= ing to make it useful in an enterprise environment and will be posting our = ideas to the list before developer days it should have already started, we = need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I=92m making every effort to get it kick started= from our perspective. I hope to assist in getting the draft ERI finished t= his year. We are writing some new STIG content and intend to used the draf= t CRE specification to insert CRE into the content so we (DoD) can do some = automatic configuration fixes, part of a self healing network concept. It i= s just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and = content to roll up reporting, in any enterprise of size the problem gets gr= eater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from ef= forts to meet use cases, we have some things we would like changed in XCCDF= to support our OCIl use case and I have been told that I need to wait. I d= idn=92t think that a move to internationalization should impede efforts to = move forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of ap= proach. We would like to see some community discussion around what are the= key areas/priorities that the community would like to see discussed at Dev= Days. Your topics below look like a good start. The SACM list might be a = better venue than the OVAL list for this discussion. For each area we shou= ld focus the discussion around developing objectives for each session. The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective. For example if continuous monitoring is = a priority and collectively it takes 3 days to work through all the objecti= ves, I see no problem with that. We can also keep a few sessions =93on dec= k=94 if all the objectives are reached and we complete all the scheduled se= ssions early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.com<= mailto:Kent_Landfield@mcafee.com> Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation being sent out in advance, a webinar if it is felt there will be = questions and answers from those that are new to the efforts. We have a li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in ad= vance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas tha= t need real work by the community 4. Efforts to be discussed should be based on needs of the security autom= ation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d with. There are going to be things we need to do as a security automation= community to be able to accomplish what is listed in the CAESARS FE. Ther= e are interfaces that need to be worked and established. That is one area = that is not listed below. CM will have a major impact on all of us in the = next couple years and it is being ignored. We can't keep trying to solve w= hat has already been solved. We need to address the needed interface devel= opment now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +=85) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e they are such a pain to manage from a content perspective. It is easier = to buy from one vendor that has a single means for distributing content tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that = is being underutilized and under implemented because of the limitations of = how it addresses uses in an enterprise environment. People don't need secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. Scheduling and tracking are key to it's success. We need to make that= happen. This too needs a focused brainstorming time box to discuss option= s. I am really disappointed that Remediation is not on the list below=85 Yes,= last Summer Dev Days, the time spent on Remediation was wasted time but th= at does not mean we should ignore it and not try to make some real progress= . As far as I am concerned we need to reboot the remediation effort. We c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. But today we think it is too hard so we don't try ? I think we need = a couple hours to discuss the reboot of the effort even if that means minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al Agencies. The initial effort was a mess, did little more than prove it = was possible and cause the vendor community a great deal of thrashing to pu= t a kludgey 'solution' in place. Reality is all our customers need roll up= reporting and an infrastructure that supports it. A data call should not = be special to anyone other than the agencies responding. The tools should b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces=85. We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess while we are all in the same room. This is always a big event for the = 'consensus of the willing' that assemble and driven to see security automat= ion make a difference. Let's see if we can have an event that, when we all= walk out the last day, we all feel that every minute was well spent and mo= ves us forward. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng the week of July 9 =96 starting Monday at 10:00 AM and ending on Friday = at 12:00. Meanwhile, we are working on the agenda and are currently considering this = list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year=92s MITRE-hosted Security Automation Developer Days event will be= held during the week of July 9, 2012 at MITRE=92s facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. --_000_CBD0067532964kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Mike I love it when you tee something up like that=85.= ;-)  Thank you. ;)

Mike = wrote: 

I still think that any specification for a reposit= ory is wishful thinking until someone builds one and learns the lessons it = will just be another whitepaper spec.  I believe the DoD needs to inco= rporate a metadata repository as part of it and other customizations that m= ay not be useful for everyone.


If = you are talking about a holistic, complete federated approach to a content = repository, I some what agree.  If you are talking about an organizati= onal repository, I totally disagree. But you knew I would. ;)


Here is how I see the probl= em.  There is an immediate need for SCAP and other related content to = be served up inside an organization.  Today we have situation where th= e standards allow us to provide sites the capability to have a single SCAP = implemented policy they call official for their environment. Yes this is a = rather simplistic since there are things such as targeting specific platfor= ms, specific operational use needs, but for now lets agree SCAP is a massiv= e improvement over the proprietary situations of the past. While we have cr= eated this standard content so that sites can implement their local site se= curity once and then assure they are measuring all appropriately targeted d= evices the same way, we have failed to support the operational needs of the= sites.  We have a situation where no two vendors distribute content t= he same way.  This causes massive problems for the administration staf= f when they need to incorporate a new SCAP enabled product into their archi= tecture.  They need to discover how the new product supports distribut= ing SCAP content to it's various components.  If they have one product= then they do this one and they are done.  If they have multiple produ= cts they will have to figure out how to minimize the impact by incorporatin= g the update process for the new product into the existing SCAP security co= ntent processes. Now when the inevitable happens and the site staff needs t= o make a change to their security policy, they have to make the modificatio= ns to the benchmark or checks or both and then distribute those updates acr= oss their network.  For each SCAP enabled product they have in place, = they have doubled, tripled or more the work needed to make those updates av= ailable. 


There is another content repository problem and that is the Federated Cont= ent Distribution.  If you think global DNS you have a general frame of= reference.  The guidance authors need to be able to publish content i= n an authoritative manner so their content is updated in a timely fashion. =  This is a much harder problem to solve if there is no local organizat= ional infrastructure to support it. ;)


So here is what I am thinking=85  We should c= onsider addressing these as two separate but integrated efforts.  I be= lieve the Organizational Content Repository is the more critical piece that= is actually easier to address.  The Federated Content Distribution sh= ould be a subsequent effort integrating / augmenting the Organizational rep= ository specification. 


Mike, to your point that we need someone to build one first= =85 That has happened already.  I have one as do other vendors but wha= t we don=92t have is the access specification.  Ours are focused on ou= r specific product needs.  Additionally there is a company that has de= veloped a commercial SCAP content repository that will be announced later t= his month. I won't steal their thunder but I was recently given a sneak pee= k at it and I must admit I was very impressed.  Again, to your point, = it has been done. What is needed to address the initial operational problem= is to develop a specification that provides a consistent means for all SCA= P products to retrieve the appropriate content as configured and managed bu= t the site.  


TO THAT END=85.


I am requesting participation from those in the community that se= e the need and want to put in the work to make this specification happen. &= nbsp;I have talked to a couple of you but I do not want to assume your part= icipation.  If you are interested please contact me so we can get this= started. 


Thanks!


<= /div>
Kent Landfield
Director Content Strategy, Architecture and = Standards<= br>
McAfe= e | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mc= afee.com

From: <= Kinney>, Michael A <m.kinn= e@radium.ncsc.mil>
To: D= avid Waltermire <david.walt= ermire@nist.gov>, SCAP-DEV <= SCAP-DEV@nist.gov>, "sacm@ietf= .org" <sacm@ietf.org>Subject: Re: [sacm] [OVAL-DEVELO= PER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedfo= rd, MA

Dave,

I have no problem with webinars, I do want to keep = developer days actionable and use it to make decisions, and vote and accomp= lish things good or bad.  I do not want this to be an informational br= iefing conference.

Thanks for the links.

 

I still think that any specif= ication for a repository is wishful thinking until someone builds one and l= earns the lessons it will just be another whitepaper spec.  I believe = the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful f= or everyone.

We need to talk more=85

 

-Mike 

=

 

From: Waltermire, David A. [mailto:david.waltermire@nist.gov= ]
Sent: Tuesday, May 08, 2012 10:44 AM
To: Kinney, Micha= el A; SCAP-DEV; sacm@ietf.org
Su= bject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Su= mmer 2012 at MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-place of the 30 minu= te briefs?

 

Regarding content management, we are building the prototype= content repository for use in a production environment.  As an open s= ource project, it will be free for use by anyone interested.  My think= ing is that this project can bridge the gap until commercial solutions are available t= o augment it.  This is a similar path that was followed with DNS (bind= ) and HTTP (apache).  When it is ready for use, I am hoping to use it = to host USGCB content.  You would be welcome to use it for your needs.

 

It is good that OCIL is moving forward.&nbs= p; This is an important piece of supporting risk management and aspects of = continuous monitoring.  I would also like to see some discussion on OC= IL at Developer Days.  With the proposals we will likely have a sense of what needs to be discussed an= d what we can achieve consensus on outside the meeting.

 

Remediation is= a topic near and dear to my heart.  I too would like to see it move f= orward.

 

We just published the draft ASR specification for public comme= nt.  This specification supports enterprise aggregate reporting which = greatly reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR= .  It can be used in continuous monitoring applications to support agg= regate data reporting needs (e.g. FISMA reporting,  CyberScope).<= /o:p>

&= nbsp;

= Here are the links:

 

http://csrc.nist.gov/publications/PubsDrafts.html

http://cs= rc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

 =

The primary= reason we have suggested waiting on XCCDF is not the internationalization = issue. Many vendors have commented that they are still working on implement= ing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occu= rred.  As we consider changes to the SCAP stack to address OCIL and ot= her issues, we will identify areas that need improvement in XCCDF.  Th= ese are good and necessary discussions to have now, but we have a good deal of work to do before we are ready to ope= n up XCCDF.  My suggestion is to work on these related areas and then = work up change proposals for XCCDF as needed.  By that time we should = be ready to work on a new revision of XCCDF.

 

I am also looking forwar= d to the discussions at the conference.  It has been too long.

&nb= sp;

Sincerely,

Dave

 

From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]
Sent: Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

 

<= p class=3D"MsoNormal">Kent,=

 <= /span>

It=92s good = to read your thoughts, and a realistic actionable approach is indeed needed= .  Since all the activity hasn=92t been on the lists a brief 1=8E2 hou= r recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and oth= ers.

 

We could write a content repository specification, but without so= meone willing to stand one up it will be as valuable as the CCSS specificat= ion is today.  I=92ve been trying for two years to get my management t= o get a coordinated effort together for the DoD to stand up a repository, it= is a tough problem and will require funding with a tail, I=92m not sure a = specification will solve that problem.

 

We (DoD) have been putting a l= ot of effort into OCIL over the last year trying to make it useful in an en= terprise environment and will be posting our ideas to the list before devel= oper days it should have already started, we need to get consensus and a vote on how the community wishes t= o proceed.

 

Remediation is stalled but I=92m making every effort to get= it kick started from our perspective. I hope to assist in getting the draf= t ERI finished this year.  We are writing some new STIG content and in= tend to used the draft CRE specification to insert CRE into the content so we (DoD= ) can do some automatic configuration fixes, part of a self healing network= concept. It is just a start but the best we can do at this point.

&nbs= p;

Ent= erprise reporting is an interesting subject, since XML adds size to and con= tent to roll up reporting, in any enterprise of size the problem gets great= er, I look forward to your thoughts on that subject.

<= p class=3D"MsoNormal"> 

I am concerned th= at the internationalization efforts are detracting from efforts to meet use= cases, we have some things we would like changed in XCCDF to support our O= CIl use case and I have been told that I need to wait. I didn=92t think that a move to internationalization should = impede efforts to move forward with use cases.

 

<= p class=3D"MsoNormal">I look forward to talki= ng with you at the conference.

=  

v/r

 

Mike Kinney

Computer Network Defense Research and Technology (CND R&T) Office<= o:p>

9800 Savage Roa= d Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: 968-8886
Fax 410-854-4681

=

makinn2@nsa.gov

 

 

 

<= div>

From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Waltermire, David A.
= Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipients= of list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation D= eveloper Days: Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

I like what you are saying here.&= nbsp; We are also in support of this type of approach.  We would like = to see some community discussion around what are the key areas/priorities t= hat the community would like to see discussed at Dev Days.  Your topics below look like a good start. The= SACM list might be a better venue than the OVAL list for this discussion.&= nbsp; For each area we should focus the discussion around developing object= ives for each session.  The sessions can be time boxed based on what would be a reasonable amount of time to accomplis= h each objective.  For example if continuous monitoring is a priority = and collectively it takes 3 days to work through all the objectives, I see = no problem with that.  We can also keep a few sessions =93on deck=94 if all the objectives are reached and we comp= lete all the scheduled sessions early.

 

Thoughts?

 

Sincerely,=

 

David Waltermire

SCAP Arch= itect

National Institute of Standards and Technology

(301) 975-3390

david.waltermire@nist.gov

 

From:scap-dev@nist.gov<= /a> [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com
Sent: Monday, = May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [OVAL-DE= VELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in B= edford, MA

&nb= sp;

All,

 

I would like to discuss the format for= the SCAP Developer Days that seems to be listed below.

 =

I see this appears to follow a path we have discussed in the past as th= e way not to hold a Dev Days event.  We have been trying to get away f= rom 'Death by Powerpoint' and back to the type of event we held years ago when we were highly productive.  In the past we had a topic to be= discussed and a time box to work within.  That allowed us to have ver= y active brainstorming sessions in a high bandwidth environment.=

 

At past Summer events we have got into a pattern of lots of po= werpoint, lots of status of the efforts and very little discussion about th= ings that need active discussions.  We need to keep moving forward and= making progress as an effort. We can get status from various places such as the l= ists, a presentation being sent out in advance, a webinar if it is felt the= re will be questions and answers from those that are new to the efforts. &n= bsp;We have a limited amount of time and all who are attending are investing a great deal of time and money to = be there.  We should not  be spending a great deal of time reeduc= ating everyone when we could be focused on advancing needed efforts.

 

The type of approach to a Dev Days event was discussed at = the last Summer Dev Days.  I have seen the following work quite well i= n other efforts.

  1. Presentations are sent out to the attendees and the lists a week in advance= .
  2. Status for any effort is limited to 30 minutes
  3. Focused brainstorming time should be established for certain areas that nee= d real work by the community
  4. Efforts to be discussed should be based on needs of the security automation= space to move existing efforts to completion.

For example:

&= nbsp;

Continuous monitoring is a major direction the efforts are becomin= g involved with. There are going to be things we need to do as a security a= utomation community to be able to accomplish what is listed in the CAESARS FE.  There are interfaces that need to be worked and established. &nb= sp;That is one area that is not listed below.  CM will have a major im= pact on all of us in the next couple years and it is being ignored.  W= e can't keep trying to solve what has already been solved.  We need to address the needed interface development now. This is an = effort that could take nearly a whole day by itself.

<= /div>

 

Operationally we have a real need to be able to deliver SCAP content inter= nally within an organization. Today the SCAP vendors cannot share a single = local site security policy (XCCDF + OVAL + CPE +=85) without th= e site staff having to go to each of the individual products and figuring ou= t how to inject that new or updated policy into that products delivery mech= anisms.  That is limiting sites from wanting to buy multiple focused S= CAP products since they are such a pain to manage from a content perspective.  It is easier to buy from one v= endor that has a single means for distributing content than it is to deal w= ith the management issues that having multiple SCAP products presents. &nbs= p;We need to have at least an entire 1/2 a day on the development of a Content Repository specification.

 

OCIL is a positive and a negative at the same time. It has real = value that is being underutilized and under implemented because of the limi= tations of how it addresses uses in an enterprise environment.  People don't need security automation to do things on/for a single host.  Th= ey need security automation to focus on the enterprise issues that reduce t= heir costs and improve their efficiencies.  OCIL is failing in the ent= erprise and we all understand that.  We need to address developing a definitive solution for incorporating OCIL into th= e enterprise and that means into the existing specifications. Scheduling an= d tracking are key to it's success.  We need to make that happen. &nbs= p;This too needs a focused brainstorming time box to discuss options.

 

I am really disappointed th= at Remediation is not on the list below=85  Yes, last Summer Dev Days,= the time spent on Remediation was wasted time but that does not mean we sh= ould ignore it and not try to make some real progress.  As far as I am concerned we need to reboot the remedi= ation effort.  We cannot keep being the set of specifications / tools = that act as the little boy crying "Wolf" in the night.  We n= eed to be able to find and fix issues if we are going to really make a difference in organizational security postures.  But to= day we think it is too hard so we don't try ?  I think we need a coupl= e hours to discuss the reboot of the effort even if that means minimizing w= ork already done.

 

A focused discussion on enterpri= se reporting is also critically needed.  For the vendors here, we have= all gone through the Cyberscope goat rope, delivering limited capabilities= to specific data call requirements of the Federal Agencies.  The initial effort was a mess, did little m= ore than prove it was possible and cause the vendor community a great deal = of thrashing to put a kludgey 'solution' in place.  Reality is all our= customers need roll up reporting and an infrastructure that supports it.  A data call should not be special to anyone other = than the agencies responding. The tools should be able to select the types = of data needed and deliver that on a scheduled basis automatically.   =  Enterprise Reporting pertains to commercial as well as Federal customers.  We need to focus some time on what tha= t would look like using the ARF and ASR as the foundational pieces.  B= ut there are missing pieces=85.  We need this discussed.

=  

I would hope we can make this summer's SCAP Dev Days useful in ad= vancing the security automation efforts by addressing some of the more crit= ical issues our customers are facing now or will be facing in the very short term.  Status presentations are not interesting to those active= in the efforts.  Let's try to do those before we get to Bedford so we= can real make some progress while we are all in the same room.  This = is always a big event for the 'consensus of the willing' that assemble and driven to see security automation make a differ= ence.  Let's see if we can have an event that, when we all walk out th= e last day, we all feel that every minute was well spent and moves us forwa= rd.

 

<= span style=3D"color:black">Thanks.

 

Kent Landfield
Director= Content Strategy, Architecture and Standards

McAfee | An Intel Company<= /strong>
5000 Headquarters Dr.Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
<= span style=3D"font-family: Arial, sans-serif; ">Web: <= span class=3D"apple-style-span">www.mcaf= ee.com

<= /div>

 

From: <Boczenowski>, Steve <sboc= zeno@MITRE.ORG>
Reply-To: "OVAL Developer List (Close= d Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: "= OVAL-DEVELOPER-LIST@= LISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
Subject: Re= : [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Frank;

 

We hope to have the registration site up next wee= k.  The event will be during the week of July 9 =96 starting Monday at= 10:00 AM and ending on Friday at 12:00.=

=  

Meanwhile, we are working on the a= genda and are currently considering this list of topics:

 

CCE

CPE/SWID

CEE=

XCCDF<= span style=3D"color:black">

OVAL

ASR

Enterprise OCIL

CybOX/MAEC

Federated Content Repository Spec<= span style=3D"color:black">

Endpoint Reporting fo= r Continuous Monitoring and Compliance (ERCC)

MILE

TAXII<= /span>

IF-M for SCAP<= /span>

IF-MAP<= /p>

SCAP Releases<= /p>

SCAP and IETF<= /p>

NETCONF and SCAP

 

Steve

 

From: = Frank Lindsay Acker [mailto:afrank@NOVA.= EDU]
Sent: Tuesday, May 01, 2012 9:32 AM
To: oval-developer= -list OVAL Developer List/Closed Public Discussion
Subject: Re: [= OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MIT= RE in Bedford, MA

<= /div>

 

Steve....

Has there been any additional information regarding this event?

Thanks,
Frank Acker

From: Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tues= day, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Subject:<= /b> [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 a= t MITRE in Bedford, MA=

Save the Date: week of July 9, 2012

 

This year=92s MITRE-hosted Security = Automation Developer Days event will be held during the week of July 9, 201= 2 at MITRE=92s facility in Bedford, MA.

 =

Details to follow.

 <= /o:p>

Regards,

    Stev= e

 

__________________________________________= ____

Stephen P. = Boczenowski

    = ;  The MIT= RE Corporation

      Office: (781) 271-7682

   &nb= sp;  Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an = email message to LISTSERV@LISTS.MITRE.ORG wi= th SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have diff= iculties, write to OVAL-DEVELOP= ER-LIST-request@LISTS.MITRE.ORG.

=

To unsubscrib= e, send an email message to LISTSERV@LISTS.MITRE.ORG wi= th SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have diff= iculties, write to OVAL-DEVELOP= ER-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG wi= th SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have diff= iculties, write to OVAL-DEVELOP= ER-LIST-request@LISTS.MITRE.ORG.

--_000_CBD0067532964kentlandfieldmcafeecom_-- From gunnar.engelbach@threatguard.com Fri May 11 09:42: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 704A321F85D4 for ; Fri, 11 May 2012 09:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQsteg4Velqq for ; Fri, 11 May 2012 09:42:46 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8A39221F8517 for ; Fri, 11 May 2012 09:42:46 -0700 (PDT) Received: (qmail 26998 invoked from network); 11 May 2012 10:45:49 -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); 11 May 2012 10:45:48 -0700 Message-ID: <4FAD4190.4040509@ThreatGuard.com> Date: Fri, 11 May 2012 12:42:56 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: SCAP-DEV@nist.gov, sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 11 May 2012 16:42:48 -0000 I'm not going to make any other comments at this point other than noting that this is a worthwhile effort, so count me in. --gun ThreatGuard, Inc. On 5/11/2012 12:35 PM, Kent_Landfield@McAfee.com wrote: > Mike I love it when you tee something up like that…. ;-) Thank you. ;) > > Mike wrote: > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will just be > another whitepaper spec. I believe the DoD needs to incorporate a > metadata repository as part of it and other customizations that may not > be useful for everyone. > > We need to talk more… > > > If you are talking about a holistic, complete federated approach to a > content repository, I some what agree. If you are talking about an > organizational repository, I totally disagree. But you knew I would. ;) > > > Here is how I see the problem. There is an immediate need for SCAP and > other related content to be served up inside an organization. Today we > have situation where the standards allow us to provide sites the > capability to have a single SCAP implemented policy they call official > for their environment. Yes this is a rather simplistic since there are > things such as targeting specific platforms, specific operational use > needs, but for now lets agree SCAP is a massive improvement over the > proprietary situations of the past. While we have created this standard > content so that sites can implement their local site security once and > then assure they are measuring all appropriately targeted devices the > same way, we have failed to support the operational needs of the sites. > We have a situation where no two vendors distribute content the same > way. This causes massive problems for the administration staff when they > need to incorporate a new SCAP enabled product into their architecture. > They need to discover how the new product supports distributing SCAP > content to it's various components. If they have one product then they > do this one and they are done. If they have multiple products they will > have to figure out how to minimize the impact by incorporating the > update process for the new product into the existing SCAP security > content processes. Now when the inevitable happens and the site staff > needs to make a change to their security policy, they have to make the > modifications to the benchmark or checks or both and then distribute > those updates across their network. For each SCAP enabled product they > have in place, they have doubled, tripled or more the work needed to > make those updates available. > > > There is another content repository problem and that is the Federated > Content Distribution. If you think global DNS you have a general frame > of reference. The guidance authors need to be able to publish content in > an authoritative manner so their content is updated in a timely fashion. > This is a much harder problem to solve if there is no local > organizational infrastructure to support it. ;) > > > So here is what I am thinking… We should consider addressing these as > two separate but integrated efforts. I believe the Organizational > Content Repository is the more critical piece that is actually easier to > address. The Federated Content Distribution should be a subsequent > effort integrating / augmenting the Organizational repository > specification. > > > Mike, to your point that we need someone to build one first… That has > happened already. I have one as do other vendors but what we don’t have > is the access specification. Ours are focused on our specific product > needs. Additionally there is a company that has developed a commercial > SCAP content repository that will be announced later this month. I won't > steal their thunder but I was recently given a sneak peek at it and I > must admit I was very impressed. Again, to your point, it has been done. > What is needed to address the initial operational problem is to develop > a specification that provides a consistent means for all SCAP products > to retrieve the appropriate content as configured and managed but the site. > > > TO THAT END…. > > > I am requesting participation from those in the community that see the > need and want to put in the work to make this specification happen. I > have talked to a couple of you but I do not want to assume your > participation. If you are interested please contact me so we can get > this started. > > > Thanks! > > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: , Michael A > > To: David Waltermire >, SCAP-DEV >, "sacm@ietf.org " > > > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Dave, > > I have no problem with webinars, I do want to keep developer days > actionable and use it to make decisions, and vote and accomplish > things good or bad. I do not want this to be an informational > briefing conference. > > Thanks for the links. > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will > just be another whitepaper spec. I believe the DoD needs to > incorporate a metadata repository as part of it and other > customizations that may not be useful for everyone. > > We need to talk more… > > -Mike > > *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] > *Sent:* Tuesday, May 08, 2012 10:44 AM > *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Mike, > > What about having webinars in-place of the 30 minute briefs? > > Regarding content management, we are building the prototype content > repository for use in a production environment. As an open source > project, it will be free for use by anyone interested. My thinking > is that this project can bridge the gap until commercial solutions > are available to augment it. This is a similar path that was > followed with DNS (bind) and HTTP (apache). When it is ready for > use, I am hoping to use it to host USGCB content. You would be > welcome to use it for your needs. > > It is good that OCIL is moving forward. This is an important piece > of supporting risk management and aspects of continuous monitoring. > I would also like to see some discussion on OCIL at Developer Days. > With the proposals we will likely have a sense of what needs to be > discussed and what we can achieve consensus on outside the meeting. > > Remediation is a topic near and dear to my heart. I too would like > to see it move forward. > > We just published the draft ASR specification for public comment. > This specification supports enterprise aggregate reporting which > greatly reduces the data volumes needed verses detailed host-based > reports. This specification has been designed as a more robust > replacement for LASR. It can be used in continuous monitoring > applications to support aggregate data reporting needs (e.g. FISMA > reporting, CyberScope). > > Here are the links: > > http://csrc.nist.gov/publications/PubsDrafts.html > > http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 > > The primary reason we have suggested waiting on XCCDF is not the > internationalization issue. Many vendors have commented that they > are still working on implementing the XCCDF 1.2.1 specification. We > will be in a better place in a few months once more development > around XCCDF has occurred. As we consider changes to the SCAP stack > to address OCIL and other issues, we will identify areas that need > improvement in XCCDF. These are good and necessary discussions to > have now, but we have a good deal of work to do before we are ready > to open up XCCDF. My suggestion is to work on these related areas > and then work up change proposals for XCCDF as needed. By that time > we should be ready to work on a new revision of XCCDF. > > I am also looking forward to the discussions at the conference. It > has been too long. > > Sincerely, > > Dave > > *From:*Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] > *Sent:* Tuesday, May 08, 2012 7:09 AM > *To:* SCAP-DEV > *Cc:* Waltermire, David A. > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > It’s good to read your thoughts, and a realistic actionable approach > is indeed needed. Since all the activity hasn’t been on the lists a > brief 1Ž2 hour recap may be in order to bring everyone up to speed > since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX > CEE and others. > > We could write a content repository specification, but without > someone willing to stand one up it will be as valuable as the CCSS > specification is today. I’ve been trying for two years to get my > management to get a coordinated effort together for the DoD to stand > up a repository, it is a tough problem and will require funding with > a tail, I’m not sure a specification will solve that problem. > > We (DoD) have been putting a lot of effort into OCIL over the last > year trying to make it useful in an enterprise environment and will > be posting our ideas to the list before developer days it should > have already started, we need to get consensus and a vote on how the > community wishes to proceed. > > Remediation is stalled but I’m making every effort to get it kick > started from our perspective. I hope to assist in getting the draft > ERI finished this year. We are writing some new STIG content and > intend to used the draft CRE specification to insert CRE into the > content so we (DoD) can do some automatic configuration fixes, part > of a self healing network concept. It is just a start but the best > we can do at this point. > > Enterprise reporting is an interesting subject, since XML adds size > to and content to roll up reporting, in any enterprise of size the > problem gets greater, I look forward to your thoughts on that subject. > > I am concerned that the internationalization efforts are detracting > from efforts to meet use cases, we have some things we would like > changed in XCCDF to support our OCIl use case and I have been told > that I need to wait. I didn’t think that a move to > internationalization should impede efforts to move forward with use > cases. > > I look forward to talking with you at the conference. > > v/r > > Mike Kinney > > Project Director > > Computer Network Defense Research and Technology (CND R&T) Office > > 9800 Savage Road Ste 6767 > Ft Meade, MD 20755-6767 > Phone: 410-854-4422 > NSTS: 968-8886 > Fax 410-854-4681 > > makinn2@nsa.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Waltermire, David A. > *Sent:* Monday, May 07, 2012 7:09 PM > *To:* Multiple recipients of list > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > I like what you are saying here. We are also in support of this type > of approach. We would like to see some community discussion around > what are the key areas/priorities that the community would like to > see discussed at Dev Days. Your topics below look like a good start. > The SACM list might be a better venue than the OVAL list for this > discussion. For each area we should focus the discussion around > developing objectives for each session. The sessions can be time > boxed based on what would be a reasonable amount of time to > accomplish each objective. For example if continuous monitoring is a > priority and collectively it takes 3 days to work through all the > objectives, I see no problem with that. We can also keep a few > sessions “on deck” if all the objectives are reached and we complete > all the scheduled sessions early. > > Thoughts? > > Sincerely, > > David Waltermire > > SCAP Architect > > National Institute of Standards and Technology > > (301) 975-3390 > > david.waltermire@nist.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Kent_Landfield@mcafee.com > *Sent:* Monday, May 07, 2012 4:25 PM > *To:* SCAP-DEV > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > All, > > I would like to discuss the format for the SCAP Developer Days that > seems to be listed below. > > I see this appears to follow a path we have discussed in the past as > the way not to hold a Dev Days event. We have been trying to get > away from 'Death by Powerpoint' and back to the type of event we > held years ago when we were highly productive. In the past we had a > topic to be discussed and a time box to work within. That allowed us > to have very active brainstorming sessions in a high bandwidth > environment. > > At past Summer events we have got into a pattern of lots of > powerpoint, lots of status of the efforts and very little discussion > about things that need active discussions. We need to keep moving > forward and making progress as an effort. We can get status from > various places such as the lists, a presentation being sent out in > advance, a webinar if it is felt there will be questions and answers > from those that are new to the efforts. We have a limited amount of > time and all who are attending are investing a great deal of time > and money to be there. We should not be spending a great deal of > time reeducating everyone when we could be focused on advancing > needed efforts. > > The type of approach to a Dev Days event was discussed at the last > Summer Dev Days. I have seen the following work quite well in other > efforts. > > 1. Presentations are sent out to the attendees and the lists a week > in advance. > 2. Status for any effort is limited to 30 minutes > 3. Focused brainstorming time should be established for certain > areas that need real work by the community > 4. Efforts to be discussed should be based on needs of the security > automation space to move existing efforts to completion. > > For example: > > Continuous monitoring is a major direction the efforts are becoming > involved with. There are going to be things we need to do as a > security automation community to be able to accomplish what is > listed in the CAESARS FE. There are interfaces that need to be > worked and established. That is one area that is not listed below. > CM will have a major impact on all of us in the next couple years > and it is being ignored. We can't keep trying to solve what has > already been solved. We need to address the needed interface > development now. This is an effort that could take nearly a whole > day by itself. > > Operationally we have a real need to be able to deliver SCAP content > internally within an organization. Today the SCAP vendors cannot > share a single local site security policy (XCCDF + OVAL + CPE +…) > without the site staff having to go to each of the individual > products and figuring out how to inject that new or updated policy > into that products delivery mechanisms. That is limiting sites from > wanting to buy multiple focused SCAP products since they are such a > pain to manage from a content perspective. It is easier to buy from > one vendor that has a single means for distributing content than it > is to deal with the management issues that having multiple SCAP > products presents. We need to have at least an entire 1/2 a day on > the development of a Content Repository specification. > > OCIL is a positive and a negative at the same time. It has real > value that is being underutilized and under implemented because of > the limitations of how it addresses uses in an enterprise > environment. People don't need security automation to do things > on/for a single host. They need security automation to focus on the > enterprise issues that reduce their costs and improve their > efficiencies. OCIL is failing in the enterprise and we all > understand that. We need to address developing a definitive solution > for incorporating OCIL into the enterprise and that means into the > existing specifications. Scheduling and tracking are key to it's > success. We need to make that happen. This too needs a focused > brainstorming time box to discuss options. > > I am really disappointed that Remediation is not on the list below… > Yes, last Summer Dev Days, the time spent on Remediation was wasted > time but that does not mean we should ignore it and not try to make > some real progress. As far as I am concerned we need to reboot the > remediation effort. We cannot keep being the set of specifications / > tools that act as the little boy crying "Wolf" in the night. We need > to be able to find and fix issues if we are going to really make a > difference in organizational security postures. But today we think > it is too hard so we don't try ? I think we need a couple hours to > discuss the reboot of the effort even if that means minimizing work > already done. > > A focused discussion on enterprise reporting is also critically > needed. For the vendors here, we have all gone through the > Cyberscope goat rope, delivering limited capabilities to specific > data call requirements of the Federal Agencies. The initial effort > was a mess, did little more than prove it was possible and cause the > vendor community a great deal of thrashing to put a kludgey > 'solution' in place. Reality is all our customers need roll up > reporting and an infrastructure that supports it. A data call should > not be special to anyone other than the agencies responding. The > tools should be able to select the types of data needed and deliver > that on a scheduled basis automatically. Enterprise Reporting > pertains to commercial as well as Federal customers. We need to > focus some time on what that would look like using the ARF and ASR > as the foundational pieces. But there are missing pieces…. We need > this discussed. > > I would hope we can make this summer's SCAP Dev Days useful in > advancing the security automation efforts by addressing some of the > more critical issues our customers are facing now or will be facing > in the very short term. Status presentations are not interesting to > those active in the efforts. Let's try to do those before we get to > Bedford so we can real make some progress while we are all in the > same room. This is always a big event for the 'consensus of the > willing' that assemble and driven to see security automation make a > difference. Let's see if we can have an event that, when we all walk > out the last day, we all feel that every minute was well spent and > moves us forward. > > Thanks. > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Steve > > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > > > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > " > > > *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Frank; > > We hope to have the registration site up next week. The event > will be during the week of July 9 – starting Monday at 10:00 AM > and ending on Friday at 12:00. > > Meanwhile, we are working on the agenda and are currently > considering this list of topics: > > CCE > > CPE/SWID > > CEE > > XCCDF > > OVAL > > ASR > > Enterprise OCIL > > CybOX/MAEC > > Federated Content Repository Spec > > Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) > > MILE > > TAXII > > IF-M for SCAP > > IF-MAP > > SCAP Releases > > SCAP and IETF > > NETCONF and SCAP > > Steve > > *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU] > *Sent:* Tuesday, May 01, 2012 9:32 AM > *To:* oval-developer-list OVAL Developer List/Closed Public > Discussion > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Steve.... > > Has there been any additional information regarding this event? > > Thanks, > Frank Acker > > ------------------------------------------------------------------------ > > *From:*Boczenowski, Steve [sboczeno@MITRE.ORG > ] > *Sent:* Tuesday, March 20, 2012 16:38 > *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > > *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Save the Date: week of July 9, 2012 > > This year’s MITRE-hosted Security Automation Developer Days > event will be held during the week of July 9, 2012 at MITRE’s > facility in Bedford, MA. > > Details to follow. > > Regards, > > Steve > > ______________________________________________ > > /Stephen P. Boczenowski/ > > The MITRECorporation > > Office: (781) 271-7682 > > Cell: (978) 302-3849 > > sboczeno@mitre.org > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From michael.hammer@yaanatech.com Fri May 11 10:07: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 659CB21F85A1 for ; Fri, 11 May 2012 10:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIm63esEWfy1 for ; Fri, 11 May 2012 10: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 A832621F8565 for ; Fri, 11 May 2012 10:07:37 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 11 May 2012 10:07:37 -0700 From: Michael Hammer To: "Kent_Landfield@McAfee.com" , "m.kinne@radium.ncsc.mil" , "david.waltermire@nist.gov" , "SCAP-DEV@nist.gov" , "sacm@ietf.org" Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: AQHNL5QuldOyVyYpdE+TeN1iYtf+U5bE0XPQ Date: Fri, 11 May 2012 17:07:35 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38AA570@EX2K10MB1.corp.yaanatech.com> References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.9] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0051_01CD2F77.07239AC0" MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 11 May 2012 17:07:52 -0000 ------=_NextPart_000_0051_01CD2F77.07239AC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0052_01CD2F77.07239AC0" ------=_NextPart_001_0052_01CD2F77.07239AC0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable When you say publish content, is the content still distributed, but = index entries are published somewhere? You seem to hint at that with the DNS reference, but I'm not sure. =20 Mike =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Friday, May 11, 2012 12:36 PM To: m.kinne@radium.ncsc.mil; david.waltermire@nist.gov; = SCAP-DEV@nist.gov; sacm@ietf.org Subject: [sacm] Request for participants - Content Repository = Specification Development =20 Mike I love it when you tee something up like that.. ;-) Thank you. ;) =20 Mike wrote:=20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful = for everyone. We need to talk more. =20 If you are talking about a holistic, complete federated approach to a content repository, I some what agree. If you are talking about an organizational repository, I totally disagree. But you knew I would. ;) =20 Here is how I see the problem. There is an immediate need for SCAP and other related content to be served up inside an organization. Today we = have situation where the standards allow us to provide sites the capability = to have a single SCAP implemented policy they call official for their environment. Yes this is a rather simplistic since there are things such = as targeting specific platforms, specific operational use needs, but for = now lets agree SCAP is a massive improvement over the proprietary situations = of the past. While we have created this standard content so that sites can implement their local site security once and then assure they are = measuring all appropriately targeted devices the same way, we have failed to = support the operational needs of the sites. We have a situation where no two vendors distribute content the same way. This causes massive problems = for the administration staff when they need to incorporate a new SCAP = enabled product into their architecture. They need to discover how the new = product supports distributing SCAP content to it's various components. If they = have one product then they do this one and they are done. If they have = multiple products they will have to figure out how to minimize the impact by incorporating the update process for the new product into the existing = SCAP security content processes. Now when the inevitable happens and the site staff needs to make a change to their security policy, they have to make = the modifications to the benchmark or checks or both and then distribute = those updates across their network. For each SCAP enabled product they have = in place, they have doubled, tripled or more the work needed to make those updates available.=20 =20 There is another content repository problem and that is the Federated Content Distribution. If you think global DNS you have a general frame = of reference. The guidance authors need to be able to publish content in = an authoritative manner so their content is updated in a timely fashion. = This is a much harder problem to solve if there is no local organizational infrastructure to support it. ;) =20 So here is what I am thinking. We should consider addressing these as = two separate but integrated efforts. I believe the Organizational Content Repository is the more critical piece that is actually easier to = address. The Federated Content Distribution should be a subsequent effort = integrating / augmenting the Organizational repository specification.=20 =20 Mike, to your point that we need someone to build one first. That has happened already. I have one as do other vendors but what we don't have = is the access specification. Ours are focused on our specific product = needs. Additionally there is a company that has developed a commercial SCAP = content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I = was very impressed. Again, to your point, it has been done. What is needed = to address the initial operational problem is to develop a specification = that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site. =20 =20 TO THAT END.. =20 I am requesting participation from those in the community that see the = need and want to put in the work to make this specification happen. I have talked to a couple of you but I do not want to assume your = participation. If you are interested please contact me so we can get this started.=20 =20 Thanks! =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Michael A To: David Waltermire , SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Dave, I have no problem with webinars, I do want to keep developer days = actionable and use it to make decisions, and vote and accomplish things good or = bad. I do not want this to be an informational briefing conference. Thanks for the links. =20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful = for everyone. We need to talk more. =20 -Mike =20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 Regarding content management, we are building the prototype content repository for use in a production environment. As an open source = project, it will be free for use by anyone interested. My thinking is that this project can bridge the gap until commercial solutions are available to augment it. This is a similar path that was followed with DNS (bind) = and HTTP (apache). When it is ready for use, I am hoping to use it to host USGCB content. You would be welcome to use it for your needs. =20 It is good that OCIL is moving forward. This is an important piece of supporting risk management and aspects of continuous monitoring. I = would also like to see some discussion on OCIL at Developer Days. With the proposals we will likely have a sense of what needs to be discussed and = what we can achieve consensus on outside the meeting. =20 Remediation is a topic near and dear to my heart. I too would like to = see it move forward. =20 We just published the draft ASR specification for public comment. This specification supports enterprise aggregate reporting which greatly = reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR. = It can be used in continuous monitoring applications to support aggregate = data reporting needs (e.g. FISMA reporting, CyberScope). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are = still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred. As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF. = These are good and necessary discussions to have now, but we have a good deal = of work to do before we are ready to open up XCCDF. My suggestion is to = work on these related areas and then work up change proposals for XCCDF as needed. By that time we should be ready to work on a new revision of = XCCDF. =20 I am also looking forward to the discussions at the conference. It has = been too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]=20 Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 It's good to read your thoughts, and a realistic actionable approach is indeed needed. Since all the activity hasn't been on the lists a brief = 1=AE2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. =20 We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification = is today. I've been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is = a tough problem and will require funding with a tail, I'm not sure a specification will solve that problem. =20 We (DoD) have been putting a lot of effort into OCIL over the last year trying to make it useful in an enterprise environment and will be = posting our ideas to the list before developer days it should have already = started, we need to get consensus and a vote on how the community wishes to = proceed. =20 Remediation is stalled but I'm making every effort to get it kick = started from our perspective. I hope to assist in getting the draft ERI finished this year. We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can = do some automatic configuration fixes, part of a self healing network = concept. It is just a start but the best we can do at this point. =20 Enterprise reporting is an interesting subject, since XML adds size to = and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject. =20 I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to = wait. I didn't think that a move to internationalization should impede efforts = to move forward with use cases. =20 I look forward to talking with you at the conference. =20 v/r =20 Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov =20 =20 =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 I like what you are saying here. We are also in support of this type of approach. We would like to see some community discussion around what = are the key areas/priorities that the community would like to see discussed = at Dev Days. Your topics below look like a good start. The SACM list might = be a better venue than the OVAL list for this discussion. For each area we should focus the discussion around developing objectives for each = session. The sessions can be time boxed based on what would be a reasonable = amount of time to accomplish each objective. For example if continuous monitoring = is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that. We can also keep a few sessions = "on deck" if all the objectives are reached and we complete all the = scheduled sessions early. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 All, =20 I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. =20 I see this appears to follow a path we have discussed in the past as the = way not to hold a Dev Days event. We have been trying to get away from = 'Death by Powerpoint' and back to the type of event we held years ago when we = were highly productive. In the past we had a topic to be discussed and a = time box to work within. That allowed us to have very active brainstorming sessions in a high bandwidth environment. =20 At past Summer events we have got into a pattern of lots of powerpoint, = lots of status of the efforts and very little discussion about things that = need active discussions. We need to keep moving forward and making progress = as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. We = have a limited amount of time and all who are attending are investing a great = deal of time and money to be there. We should not be spending a great deal = of time reeducating everyone when we could be focused on advancing needed efforts. =20 The type of approach to a Dev Days event was discussed at the last = Summer Dev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in advance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas that need real work by the community 4. Efforts to be discussed should be based on needs of the security automation space to move existing efforts to completion. For example: =20 Continuous monitoring is a major direction the efforts are becoming = involved with. There are going to be things we need to do as a security = automation community to be able to accomplish what is listed in the CAESARS FE. = There are interfaces that need to be worked and established. That is one area that is not listed below. CM will have a major impact on all of us in = the next couple years and it is being ignored. We can't keep trying to = solve what has already been solved. We need to address the needed interface development now. This is an effort that could take nearly a whole day by itself. =20 Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +.) without the = site staff having to go to each of the individual products and figuring out = how to inject that new or updated policy into that products delivery = mechanisms. That is limiting sites from wanting to buy multiple focused SCAP = products since they are such a pain to manage from a content perspective. It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having = multiple SCAP products presents. We need to have at least an entire 1/2 a day on = the development of a Content Repository specification. =20 OCIL is a positive and a negative at the same time. It has real value = that is being underutilized and under implemented because of the limitations = of how it addresses uses in an enterprise environment. People don't need security automation to do things on/for a single host. They need = security automation to focus on the enterprise issues that reduce their costs and improve their efficiencies. OCIL is failing in the enterprise and we = all understand that. We need to address developing a definitive solution = for incorporating OCIL into the enterprise and that means into the existing specifications. Scheduling and tracking are key to it's success. We = need to make that happen. This too needs a focused brainstorming time box to discuss options. =20 I am really disappointed that Remediation is not on the list below. = Yes, last Summer Dev Days, the time spent on Remediation was wasted time but = that does not mean we should ignore it and not try to make some real = progress. As far as I am concerned we need to reboot the remediation effort. We cannot keep being the set of specifications / tools that act as the = little boy crying "Wolf" in the night. We need to be able to find and fix = issues if we are going to really make a difference in organizational security postures. But today we think it is too hard so we don't try ? I think = we need a couple hours to discuss the reboot of the effort even if that = means minimizing work already done. =20 A focused discussion on enterprise reporting is also critically needed. = For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of = the Federal Agencies. The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of thrashing = to put a kludgey 'solution' in place. Reality is all our customers need = roll up reporting and an infrastructure that supports it. A data call should = not be special to anyone other than the agencies responding. The tools = should be able to select the types of data needed and deliver that on a scheduled basis automatically. Enterprise Reporting pertains to commercial as = well as Federal customers. We need to focus some time on what that would = look like using the ARF and ASR as the foundational pieces. But there are missing pieces.. We need this discussed. =20 I would hope we can make this summer's SCAP Dev Days useful in advancing = the security automation efforts by addressing some of the more critical = issues our customers are facing now or will be facing in the very short term. Status presentations are not interesting to those active in the efforts. Let's try to do those before we get to Bedford so we can real make some progress while we are all in the same room. This is always a big event = for the 'consensus of the willing' that assemble and driven to see security automation make a difference. Let's see if we can have an event that, = when we all walk out the last day, we all feel that every minute was well = spent and moves us forward. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Frank; =20 We hope to have the registration site up next week. The event will be during the week of July 9 - starting Monday at 10:00 AM and ending on = Friday at 12:00. =20 Meanwhile, we are working on the agenda and are currently considering = this list of topics: =20 CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker _____ =20 From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 =20 This year's MITRE-hosted Security Automation Developer Days event will = be held during the week of July 9, 2012 at MITRE's facility in Bedford, MA. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 ------=_NextPart_001_0052_01CD2F77.07239AC0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

When you say publish content, is the content = still distributed, but index entries are published = somewhere?

You seem to hint at that with the DNS reference, = but I’m not sure.

 

Mike

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Kent_Landfield@McAfee.com
Sent: Friday, May 11, 2012 12:36 = PM
To: m.kinne@radium.ncsc.mil; david.waltermire@nist.gov; = SCAP-DEV@nist.gov; sacm@ietf.org
Subject: [sacm] Request for = participants - Content Repository Specification = Development

 

Mike I love it when you = tee something up like that…. ;-)  Thank you. = ;)

 

Mike = wrote: 

I still think that any = specification for a repository is wishful thinking until someone builds = one and learns the lessons it will just be another whitepaper spec. =  I believe the DoD needs to incorporate a metadata repository as = part of it and other customizations that may not be useful for = everyone.

We need to talk = more…

 

If you are talking about a = holistic, complete federated approach to a content repository, I some = what agree.  If you are talking about an organizational repository, = I totally disagree. But you knew I would. ;)

 

Here is how I see the = problem.  There is an immediate need for SCAP and other related = content to be served up inside an organization.  Today we have = situation where the standards allow us to provide sites the capability = to have a single SCAP implemented policy they call official for their = environment. Yes this is a rather simplistic since there are things such = as targeting specific platforms, specific operational use needs, but for = now lets agree SCAP is a massive improvement over the proprietary = situations of the past. While we have created this standard content so = that sites can implement their local site security once and then assure = they are measuring all appropriately targeted devices the same way, we = have failed to support the operational needs of the sites.  We have = a situation where no two vendors distribute content the same way. =  This causes massive problems for the administration staff when = they need to incorporate a new SCAP enabled product into their = architecture.  They need to discover how the new product supports = distributing SCAP content to it's various components.  If they have = one product then they do this one and they are done.  If they have = multiple products they will have to figure out how to minimize the = impact by incorporating the update process for the new product into the = existing SCAP security content processes. Now when the inevitable = happens and the site staff needs to make a change to their security = policy, they have to make the modifications to the benchmark or checks = or both and then distribute those updates across their network. =  For each SCAP enabled product they have in place, they have = doubled, tripled or more the work needed to make those updates = available. 

 

There is another content = repository problem and that is the Federated Content Distribution. =  If you think global DNS you have a general frame of reference. =  The guidance authors need to be able to publish content in an = authoritative manner so their content is updated in a timely fashion. =  This is a much harder problem to solve if there is no local = organizational infrastructure to support it. ;)

 

So here is what I am = thinking…  We should consider addressing these as two = separate but integrated efforts.  I believe the Organizational = Content Repository is the more critical piece that is actually easier to = address.  The Federated Content Distribution should be a subsequent = effort integrating / augmenting the Organizational repository = specification. 

 

Mike, to your point that = we need someone to build one first… That has happened already. =  I have one as do other vendors but what we don’t have is the = access specification.  Ours are focused on our specific product = needs.  Additionally there is a company that has developed a = commercial SCAP content repository that will be announced later this = month. I won't steal their thunder but I was recently given a sneak peek = at it and I must admit I was very impressed.  Again, to your point, = it has been done. What is needed to address the initial operational = problem is to develop a specification that provides a consistent means = for all SCAP products to retrieve the appropriate content as configured = and managed but the site.  

 

TO THAT = END….

 

I am requesting = participation from those in the community that see the need and want to = put in the work to make this specification happen.  I have talked = to a couple of you but I do not want to assume your participation. =  If you are interested please contact me so we can get this = started. 

 

Thanks!

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

=

 

From: = <Kinney>, Michael A <m.kinne@radium.ncsc.mil>To: David Waltermire <david.waltermire@nist.gov&g= t;, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: = Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA

 

Dave,

I have no problem with webinars, I do want to = keep developer days actionable and use it to make decisions, and vote = and accomplish things good or bad.  I do not want this to be an = informational briefing conference.

Thanks for the links.

 

I still think that any specification for a = repository is wishful thinking until someone builds one and learns the = lessons it will just be another whitepaper spec.  I believe the DoD = needs to incorporate a metadata repository as part of it and other = customizations that may not be useful for everyone.

We need to talk more…

 

-Mike 

 

= From:= Waltermire, David A. [mailto:david.waltermire@nist.go= v]
Sent: Tuesday, May 08, 2012 10:44 AM
To: = Kinney, Michael A; SCAP-DEV; sacm@ietf.org
Subject: RE: = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-place of the 30 = minute briefs?

 

Regarding content management, we are building = the prototype content repository for use in a production = environment.  As an open source project, it will be free for use by = anyone interested.  My thinking is that this project can bridge the = gap until commercial solutions are available to augment it.  This = is a similar path that was followed with DNS (bind) and HTTP = (apache).  When it is ready for use, I am hoping to use it to host = USGCB content.  You would be welcome to use it for your = needs.

 

It is good that OCIL is moving forward.  = This is an important piece of supporting risk management and aspects of = continuous monitoring.  I would also like to see some discussion on = OCIL at Developer Days.  With the proposals we will likely have a = sense of what needs to be discussed and what we can achieve consensus on = outside the meeting.

 

Remediation is a topic near and dear to my = heart.  I too would like to see it move forward.

 

We just published the draft ASR specification = for public comment.  This specification supports enterprise = aggregate reporting which greatly reduces the data volumes needed verses = detailed host-based reports. This specification has been designed as a = more robust replacement for LASR.  It can be used in continuous = monitoring applications to support aggregate data reporting needs (e.g. = FISMA reporting,  CyberScope).

 

Here are the links:

 

http://csrc.ni= st.gov/publications/PubsDrafts.html

= http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

 

The primary reason we have suggested waiting on = XCCDF is not the internationalization issue. Many vendors have commented = that they are still working on implementing the XCCDF 1.2.1 = specification. We will be in a better place in a few months once more = development around XCCDF has occurred.  As we consider changes to = the SCAP stack to address OCIL and other issues, we will identify areas = that need improvement in XCCDF.  These are good and necessary = discussions to have now, but we have a good deal of work to do before we = are ready to open up XCCDF.  My suggestion is to work on these = related areas and then work up change proposals for XCCDF as = needed.  By that time we should be ready to work on a new revision = of XCCDF.

 

I am also looking forward to the discussions at = the conference.  It has been too long.

 

Sincerely,

Dave

 

 

Kent,

 

It’s good to read your thoughts, and a = realistic actionable approach is indeed needed.  Since all the = activity hasn’t been on the lists a brief 1=AE2 hour recap may be = in order to bring everyone up to speed since there has been a lot of = activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

 

We could write a content repository = specification, but without someone willing to stand one up it will be as = valuable as the CCSS specification is today.  I’ve been = trying for two years to get my management to get a coordinated effort = together for the DoD to stand up a repository, it is a tough problem and = will require funding with a tail, I’m not sure a specification = will solve that problem.

 

We (DoD) have been putting a lot of effort into = OCIL over the last year trying to make it useful in an enterprise = environment and will be posting our ideas to the list before developer = days it should have already started, we need to get consensus and a vote = on how the community wishes to proceed.

 

Remediation is stalled but I’m making = every effort to get it kick started from our perspective. I hope to = assist in getting the draft ERI finished this year.  We are writing = some new STIG content and intend to used the draft CRE specification to = insert CRE into the content so we (DoD) can do some automatic = configuration fixes, part of a self healing network concept. It is just = a start but the best we can do at this point.

 

Enterprise reporting is an interesting subject, = since XML adds size to and content to roll up reporting, in any = enterprise of size the problem gets greater, I look forward to your = thoughts on that subject.

 

I am concerned that the internationalization = efforts are detracting from efforts to meet use cases, we have some = things we would like changed in XCCDF to support our OCIl use case and I = have been told that I need to wait. I didn’t think that a move to = internationalization should impede efforts to move forward with use = cases.

 

I look forward to talking with you at the = conference.

 

v/r

 

Mike Kinney

Project Director

Computer Network Defense Research and Technology (CND R&T) = Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: = 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A.
Sent: Monday, May = 07, 2012 7:09 PM
To: Multiple recipients of = list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation = Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

I like what you are saying here.  We are = also in support of this type of approach.  We would like to see = some community discussion around what are the key areas/priorities that = the community would like to see discussed at Dev Days.  Your topics = below look like a good start. The SACM list might be a better venue than = the OVAL list for this discussion.  For each area we should focus = the discussion around developing objectives for each session.  The = sessions can be time boxed based on what would be a reasonable amount of = time to accomplish each objective.  For example if continuous = monitoring is a priority and collectively it takes 3 days to work = through all the objectives, I see no problem with that.  We can = also keep a few sessions “on deck” if all the objectives are = reached and we complete all the scheduled sessions early.

 

Thoughts?

 

Sincerely,

 

David = Waltermire

SCAP = Architect

National Institute of = Standards and Technology

(301) 975-3390

david.waltermire@nist.gov

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.comSent: Monday, May 07, 2012 4:25 PM
To: = SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

All,

 

I would like to discuss = the format for the SCAP Developer Days that seems to be listed = below.

 

I see this appears to = follow a path we have discussed in the past as the way not to hold a Dev = Days event.  We have been trying to get away from 'Death by = Powerpoint' and back to the type of event we held years ago when we were = highly productive.  In the past we had a topic to be discussed and = a time box to work within.  That allowed us to have very active = brainstorming sessions in a high bandwidth = environment.

 

At past Summer events we = have got into a pattern of lots of powerpoint, lots of status of the = efforts and very little discussion about things that need active = discussions.  We need to keep moving forward and making progress as = an effort. We can get status from various places such as the lists, a = presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. =  We have a limited amount of time and all who are attending are = investing a great deal of time and money to be there.  We should = not  be spending a great deal of time reeducating everyone when we = could be focused on advancing needed = efforts.

 

The type of approach to a = Dev Days event was discussed at the last Summer Dev Days.  I have = seen the following work quite well in other = efforts.

  1. Presentations are sent out to the attendees and = the lists a week in advance.
  2. Status for any effort is limited to 30 = minutes
  3. Focused brainstorming time should be established = for certain areas that need real work by the = community
  4. Efforts to be discussed should be based on needs = of the security automation space to move existing efforts to = completion.

For example:

 

Continuous monitoring is a = major direction the efforts are becoming involved with. There are going = to be things we need to do as a security automation community to be able = to accomplish what is listed in the CAESARS FE.  There are = interfaces that need to be worked and established.  That is one = area that is not listed below.  CM will have a major impact on all = of us in the next couple years and it is being ignored.  We can't = keep trying to solve what has already been solved.  We need to = address the needed interface development now. This is an effort that = could take nearly a whole day by = itself.

 

Operationally we have a = real need to be able to deliver SCAP content internally within an = organization. Today the SCAP vendors cannot share a single local site = security policy (XCCDF + OVAL + CPE +…) without the site staff = having to go to each of the individual products and figuring out how to = inject that new or updated policy into that products delivery = mechanisms.  That is limiting sites from wanting to buy multiple = focused SCAP products since they are such a pain to manage from a = content perspective.  It is easier to buy from one vendor that has = a single means for distributing content than it is to deal with the = management issues that having multiple SCAP products presents.  We = need to have at least an entire 1/2 a day on the development of a = Content Repository specification.

 

OCIL is a positive and a = negative at the same time. It has real value that is being underutilized = and under implemented because of the limitations of how it addresses = uses in an enterprise environment.  People don't need security = automation to do things on/for a single host.  They need security = automation to focus on the enterprise issues that reduce their costs and = improve their efficiencies.  OCIL is failing in the enterprise and = we all understand that.  We need to address developing a definitive = solution for incorporating OCIL into the enterprise and that means into = the existing specifications. Scheduling and tracking are key to it's = success.  We need to make that happen.  This too needs a = focused brainstorming time box to discuss = options.

 

I am really disappointed = that Remediation is not on the list below…  Yes, last Summer = Dev Days, the time spent on Remediation was wasted time but that does = not mean we should ignore it and not try to make some real progress. =  As far as I am concerned we need to reboot the remediation effort. =  We cannot keep being the set of specifications / tools that act as = the little boy crying "Wolf" in the night.  We need to be = able to find and fix issues if we are going to really make a difference = in organizational security postures.  But today we think it is too = hard so we don't try ?  I think we need a couple hours to discuss = the reboot of the effort even if that means minimizing work already = done.

 

A focused discussion on = enterprise reporting is also critically needed.  For the vendors = here, we have all gone through the Cyberscope goat rope, delivering = limited capabilities to specific data call requirements of the Federal = Agencies.  The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of = thrashing to put a kludgey 'solution' in place.  Reality is all our = customers need roll up reporting and an infrastructure that supports it. =  A data call should not be special to anyone other than the = agencies responding. The tools should be able to select the types of = data needed and deliver that on a scheduled basis automatically.   =  Enterprise Reporting pertains to commercial as well as Federal = customers.  We need to focus some time on what that would look like = using the ARF and ASR as the foundational pieces.  But there are = missing pieces….  We need this = discussed.

 

I would hope we can make = this summer's SCAP Dev Days useful in advancing the security automation = efforts by addressing some of the more critical issues our customers are = facing now or will be facing in the very short term.  Status = presentations are not interesting to those active in the efforts. =  Let's try to do those before we get to Bedford so we can real make = some progress while we are all in the same room.  This is always a = big event for the 'consensus of the willing' that assemble and driven to = see security automation make a difference.  Let's see if we can = have an event that, when we all walk out the last day, we all feel that = every minute was well spent and moves us = forward.

 

Thanks.

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

 

From: = <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply= -To: "OVAL Developer List (Closed Public Discussion)" = <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Frank;

 

We hope to have the registration site up next = week.  The event will be during the week of July 9 – starting = Monday at 10:00 AM and ending on Friday at 12:00.

 

Meanwhile, we are working on the agenda and are = currently considering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise = OCIL

CybOX/MAEC

Federated = Content Repository Spec

Endpoint = Reporting for Continuous Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for = SCAP

IF-MAP

SCAP = Releases

SCAP and IETF

NETCONF and = SCAP

 

Steve

 

= From:= Frank Lindsay Acker [mailto:afrank@NOVA.EDU] =
Sent: Tuesday, May 01, 2012 9:32 AM
To: = oval-developer-list OVAL Developer List/Closed Public = Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

= Steve....

Has there been any additional information regarding = this event?

Thanks,
Frank Acker

= From:= Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

Save the Date: week of July 9, = 2012

 

This year’s = MITRE-hosted Security Automation Developer Days event will be held = during the week of July 9, 2012 at MITRE’s facility in Bedford, = MA.

 

Details to = follow.

 

Regards,

    Steve

 

= ______________________________________________

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

------=_NextPart_001_0052_01CD2F77.07239AC0-- ------=_NextPart_000_0051_01CD2F77.07239AC0 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx MTE3MDczM1owIwYJKoZIhvcNAQkEMRYEFCsoHA1ep5A0y6bEiqMMYOWZKq6iMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA5FMLsmyzZYqQ4fZ5f4dJxegonUMwD8gPfEYfn8cNnLpU hYoNVV/mwlNmKW13RiJc9kZD51ecGTpbcPlzvcJUNaWHusQcz9RwLr3YSv56MRxK78qCAvVveEg7 pJEWtt+y1TFLWeclBo0jISd4C4xxgUtCRLNg4/kjkE2tRuO2//AAAAAAAAA= ------=_NextPart_000_0051_01CD2F77.07239AC0-- From david.waltermire@nist.gov Fri May 11 10:13:23 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 4FA8B21F8675 for ; Fri, 11 May 2012 10:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.461 X-Spam-Level: X-Spam-Status: No, score=-5.461 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T11WFs6OQD3Y for ; Fri, 11 May 2012 10:13:09 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 106B021F85E7 for ; Fri, 11 May 2012 10:13:09 -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.355.2; Fri, 11 May 2012 13:12:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 11 May 2012 13:13:07 -0400 From: "Waltermire, David A." To: "Kent_Landfield@McAfee.com" , "m.kinne@radium.ncsc.mil" , SCAP-DEV , "sacm@ietf.org" Date: Fri, 11 May 2012 13:13:06 -0400 Thread-Topic: Request for participants - Content Repository Specification Development Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQAArCrA Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.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: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B99323F2EMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 11 May 2012 17:13:23 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B99323F2EMBCLUSTERxcha_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Kent, I have already started work on a draft specification in this area. My hope= is that this work could be used as an initial draft within SACM at the app= ropriate time. Count me in. I mostly agree with what you are describing below. The only area I disagre= e with is in regards to federation. If we do not implement the specificati= on for an organizational repository in the right way, we may need to make m= ajor changes to support federation. This is not good for anyone. In my mi= nd these two concepts cannot be decoupled. We need to insure that any work= towards supporting an organizational repository provides a foundation for = supporting a federated repository network. Imagine if DNS was designed wit= h a single organization mindset first without thinking about federation. T= op Level Domains (TLDs) and subdomains would not likely exist as concepts. = An individual DNS server would likely not support caching, time-to-live an= d delegating capabilities that are necessary for federation to happen. All= of these things would need to be retrofitted. To prevent this, we need to= address the building blocks of federation in the basic design. Sincerely, Dave From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] Sent: Friday, May 11, 2012 12:36 PM To: m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; sacm@ietf.org Subject: Request for participants - Content Repository Specification Develo= pment Mike I love it when you tee something up like that.... ;-) Thank you. ;) Mike wrote: I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more... If you are talking about a holistic, complete federated approach to a conte= nt repository, I some what agree. If you are talking about an organization= al repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and oth= er related content to be served up inside an organization. Today we have s= ituation where the standards allow us to provide sites the capability to ha= ve a single SCAP implemented policy they call official for their environmen= t. Yes this is a rather simplistic since there are things such as targeting= specific platforms, specific operational use needs, but for now lets agree= SCAP is a massive improvement over the proprietary situations of the past.= While we have created this standard content so that sites can implement th= eir local site security once and then assure they are measuring all appropr= iately targeted devices the same way, we have failed to support the operati= onal needs of the sites. We have a situation where no two vendors distribu= te content the same way. This causes massive problems for the administrati= on staff when they need to incorporate a new SCAP enabled product into thei= r architecture. They need to discover how the new product supports distrib= uting SCAP content to it's various components. If they have one product th= en they do this one and they are done. If they have multiple products they= will have to figure out how to minimize the impact by incorporating the up= date process for the new product into the existing SCAP security content pr= ocesses. Now when the inevitable happens and the site staff needs to make a= change to their security policy, they have to make the modifications to th= e benchmark or checks or both and then distribute those updates across thei= r network. For each SCAP enabled product they have in place, they have dou= bled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Conte= nt Distribution. If you think global DNS you have a general frame of refer= ence. The guidance authors need to be able to publish content in an author= itative manner so their content is updated in a timely fashion. This is a = much harder problem to solve if there is no local organizational infrastruc= ture to support it. ;) So here is what I am thinking... We should consider addressing these as tw= o separate but integrated efforts. I believe the Organizational Content Re= pository is the more critical piece that is actually easier to address. Th= e Federated Content Distribution should be a subsequent effort integrating = / augmenting the Organizational repository specification. Mike, to your point that we need someone to build one first... That has hap= pened already. I have one as do other vendors but what we don't have is th= e access specification. Ours are focused on our specific product needs. A= dditionally there is a company that has developed a commercial SCAP content= repository that will be announced later this month. I won't steal their th= under but I was recently given a sneak peek at it and I must admit I was ve= ry impressed. Again, to your point, it has been done. What is needed to ad= dress the initial operational problem is to develop a specification that pr= ovides a consistent means for all SCAP products to retrieve the appropriate= content as configured and managed but the site. TO THAT END.... I am requesting participation from those in the community that see the need= and want to put in the work to make this specification happen. I have tal= ked to a couple of you but I do not want to assume your participation. If = you are interested please contact me so we can get this started. Thanks! Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Michael A > To: David Waltermire >, SCAP-DEV >, "sacm@ietf= .org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionabl= e and use it to make decisions, and vote and accomplish things good or bad.= I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more... -Mike From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content reposit= ory for use in a production environment. As an open source project, it wil= l be free for use by anyone interested. My thinking is that this project c= an bridge the gap until commercial solutions are available to augment it. = This is a similar path that was followed with DNS (bind) and HTTP (apache).= When it is ready for use, I am hoping to use it to host USGCB content. Y= ou would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supp= orting risk management and aspects of continuous monitoring. I would also = like to see some discussion on OCIL at Developer Days. With the proposals = we will likely have a sense of what needs to be discussed and what we can a= chieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see = it move forward. We just published the draft ASR specification for public comment. This spe= cification supports enterprise aggregate reporting which greatly reduces th= e data volumes needed verses detailed host-based reports. This specificatio= n has been designed as a more robust replacement for LASR. It can be used = in continuous monitoring applications to support aggregate data reporting n= eeds (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internatio= nalization issue. Many vendors have commented that they are still working o= n implementing the XCCDF 1.2.1 specification. We will be in a better place = in a few months once more development around XCCDF has occurred. As we con= sider changes to the SCAP stack to address OCIL and other issues, we will i= dentify areas that need improvement in XCCDF. These are good and necessary= discussions to have now, but we have a good deal of work to do before we a= re ready to open up XCCDF. My suggestion is to work on these related areas= and then work up change proposals for XCCDF as needed. By that time we sh= ould be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has bee= n too long. Sincerely, Dave From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, It's good to read your thoughts, and a realistic actionable approach is ind= eed needed. Since all the activity hasn't been on the lists a brief 1=AE2 = hour recap may be in order to bring everyone up to speed since there has be= en a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone will= ing to stand one up it will be as valuable as the CCSS specification is tod= ay. I've been trying for two years to get my management to get a coordinat= ed effort together for the DoD to stand up a repository, it is a tough prob= lem and will require funding with a tail, I'm not sure a specification will= solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year try= ing to make it useful in an enterprise environment and will be posting our = ideas to the list before developer days it should have already started, we = need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I'm making every effort to get it kick started f= rom our perspective. I hope to assist in getting the draft ERI finished thi= s year. We are writing some new STIG content and intend to used the draft = CRE specification to insert CRE into the content so we (DoD) can do some au= tomatic configuration fixes, part of a self healing network concept. It is = just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and = content to roll up reporting, in any enterprise of size the problem gets gr= eater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from ef= forts to meet use cases, we have some things we would like changed in XCCDF= to support our OCIl use case and I have been told that I need to wait. I d= idn't think that a move to internationalization should impede efforts to mo= ve forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of ap= proach. We would like to see some community discussion around what are the= key areas/priorities that the community would like to see discussed at Dev= Days. Your topics below look like a good start. The SACM list might be a = better venue than the OVAL list for this discussion. For each area we shou= ld focus the discussion around developing objectives for each session. The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective. For example if continuous monitoring is = a priority and collectively it takes 3 days to work through all the objecti= ves, I see no problem with that. We can also keep a few sessions "on deck"= if all the objectives are reached and we complete all the scheduled sessio= ns early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.com<= mailto:Kent_Landfield@mcafee.com> Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation being sent out in advance, a webinar if it is felt there will be = questions and answers from those that are new to the efforts. We have a li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in ad= vance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas tha= t need real work by the community 4. Efforts to be discussed should be based on needs of the security autom= ation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d with. There are going to be things we need to do as a security automation= community to be able to accomplish what is listed in the CAESARS FE. Ther= e are interfaces that need to be worked and established. That is one area = that is not listed below. CM will have a major impact on all of us in the = next couple years and it is being ignored. We can't keep trying to solve w= hat has already been solved. We need to address the needed interface devel= opment now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +...) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e they are such a pain to manage from a content perspective. It is easier = to buy from one vendor that has a single means for distributing content tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that = is being underutilized and under implemented because of the limitations of = how it addresses uses in an enterprise environment. People don't need secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. Scheduling and tracking are key to it's success. We need to make that= happen. This too needs a focused brainstorming time box to discuss option= s. I am really disappointed that Remediation is not on the list below... Yes,= last Summer Dev Days, the time spent on Remediation was wasted time but th= at does not mean we should ignore it and not try to make some real progress= . As far as I am concerned we need to reboot the remediation effort. We c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. But today we think it is too hard so we don't try ? I think we need = a couple hours to discuss the reboot of the effort even if that means minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al Agencies. The initial effort was a mess, did little more than prove it = was possible and cause the vendor community a great deal of thrashing to pu= t a kludgey 'solution' in place. Reality is all our customers need roll up= reporting and an infrastructure that supports it. A data call should not = be special to anyone other than the agencies responding. The tools should b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces.... We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess while we are all in the same room. This is always a big event for the = 'consensus of the willing' that assemble and driven to see security automat= ion make a difference. Let's see if we can have an event that, when we all= walk out the last day, we all feel that every minute was well spent and mo= ves us forward. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng the week of July 9 - starting Monday at 10:00 AM and ending on Friday at= 12:00. Meanwhile, we are working on the agenda and are currently considering this = list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year's MITRE-hosted Security Automation Developer Days event will be h= eld during the week of July 9, 2012 at MITRE's facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. --_000_D7A0423E5E193F40BE6E94126930C4930B99323F2EMBCLUSTERxcha_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Kent,

 

I have already started work on a draft specification= in this area.=A0 My hope is that this work could be used as an initial dra= ft within SACM at the appropriate time.=A0 Count me in.

 

I mostly agree wit= h what you are describing below.=A0 The only area I disagree with is in reg= ards to federation.=A0 If we do not implement the specification for an orga= nizational repository in the right way, we may need to make major changes t= o support federation.=A0 This is not good for anyone.=A0 In my mind these t= wo concepts cannot be decoupled.=A0 We need to insure that any work towards= supporting an organizational repository provides a foundation for supporti= ng a federated repository network.=A0 Imagine if DNS was designed with a si= ngle organization mindset first without thinking about federation.=A0 Top L= evel Domains (TLDs) and subdomains would not likely exist as concepts.=A0 A= n individual DNS server would likely not support caching, time-to-live and = delegating capabilities that are necessary for federation to happen. =A0All= of these things would need to be retrofitted.=A0 To prevent this, we need = to address the building blocks of federation in the basic design.

 <= /o:p>

Sin= cerely,

Dave

 

From= : Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]
Se= nt: Friday, May 11, 2012 12:36 PM
To: m.kinne@radium.ncsc.mil= ; Waltermire, David A.; SCAP-DEV; sacm@ietf.org
Subject: Request = for participants - Content Repository Specification Development<= /span>

 

<= div>

Mike I love it when yo= u tee something up like that…. ;-)  Thank you. ;)

&nb= sp;

Mike wrote: 

I still think that= any specification for a repository is wishful thinking until someone build= s one and learns the lessons it will just be another whitepaper spec.  = ;I believe the DoD needs to incorporate a metadata repository as part of it= and other customizations that may not be useful for everyone.

We need to talk more…

 

If you are talking about a holistic, complete federated approach to a = content repository, I some what agree.  If you are talking about an or= ganizational repository, I totally disagree. But you knew I would. ;)

 

Here is how I see the problem.  There is an immediate need for = SCAP and other related content to be served up inside an organization. &nbs= p;Today we have situation where the standards allow us to provide sites the= capability to have a single SCAP implemented policy they call official for= their environment. Yes this is a rather simplistic since there are things = such as targeting specific platforms, specific operational use needs, but f= or now lets agree SCAP is a massive improvement over the proprietary situat= ions of the past. While we have created this standard content so that sites= can implement their local site security once and then assure they are meas= uring all appropriately targeted devices the same way, we have failed to su= pport the operational needs of the sites.  We have a situation where n= o two vendors distribute content the same way.  This causes massive pr= oblems for the administration staff when they need to incorporate a new SCA= P enabled product into their architecture.  They need to discover how = the new product supports distributing SCAP content to it's various componen= ts.  If they have one product then they do this one and they are done.=  If they have multiple products they will have to figure out how to m= inimize the impact by incorporating the update process for the new product = into the existing SCAP security content processes. Now when the inevitable = happens and the site staff needs to make a change to their security policy,= they have to make the modifications to the benchmark or checks or both and= then distribute those updates across their network.  For each SCAP en= abled product they have in place, they have doubled, tripled or more the wo= rk needed to make those updates available. 

 

There is another content repo= sitory problem and that is the Federated Content Distribution.  If you= think global DNS you have a general frame of reference.  The guidance= authors need to be able to publish content in an authoritative manner so t= heir content is updated in a timely fashion.  This is a much harder pr= oblem to solve if there is no local organizational infrastructure to suppor= t it. ;)

 

So here is what I am thinking…  We should consider address= ing these as two separate but integrated efforts.  I believe the Organ= izational Content Repository is the more critical piece that is actually ea= sier to address.  The Federated Content Distribution should be a subse= quent effort integrating / augmenting the Organizational repository specifi= cation. 

 

Mike, to your point that we need someone to build one first̷= 0; That has happened already.  I have one as do other vendors but what= we don’t have is the access specification.  Ours are focused on= our specific product needs.  Additionally there is a company that has= developed a commercial SCAP content repository that will be announced late= r this month. I won't steal their thunder but I was recently given a sneak = peek at it and I must admit I was very impressed.  Again, to your poin= t, it has been done. What is needed to address the initial operational prob= lem is to develop a specification that provides a consistent means for all = SCAP products to retrieve the appropriate content as configured and managed= but the site.  

 

TO THAT END….

 

I am requesting participation from thos= e in the community that see the need and want to put in the work to make th= is specification happen.  I have talked to a couple of you but I do no= t want to assume your participation.  If you are interested please con= tact me so we can get this started. 

 

Thanks!

 

Kent Landfield
Director Content Strategy, Architec= ture and Standards

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

Direct:= +1.972.963.7096 
Mobile: +1.= 817.637.8026
Web: www.mcafee.com

 

=

From: <Kinney>, Michael A <m.kinne@radium.ncsc.mil>
To: David Wal= termire <david.waltermire@n= ist.gov>, SCAP-DEV <SCAP-DEV= @nist.gov>, "sacm@ietf.org= " <sacm@ietf.org>
Sub= ject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Da= ys: Summer 2012 at MITRE in Bedford, MA

 

Dave,

<= span style=3D'color:#1F497D'>I have no problem with webinars, I do want to = keep developer days actionable and use it to make decisions, and vote and a= ccomplish things good or bad.  I do not want this to be an information= al briefing conference.

Thanks for the link= s.

 

I= still think that any specification for a repository is wishful thinking un= til someone builds one and learns the lessons it will just be another white= paper spec.  I believe the DoD needs to incorporate a metadata reposit= ory as part of it and other customizations that may not be useful for every= one.

We need to talk more…

 <= /span>

-Mike 

 

From: Waltermire, David A. [m= ailto:david.waltermire@nist.gov]
Sent: Tuesday, May 08, 2012= 10:44 AM
To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org
Subject: RE: [OVAL-DEVELOPER-LIST] S= ecurity Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-= place of the 30 minute briefs?

 

Regarding content management, we are building th= e prototype content repository for use in a production environment.  A= s an open source project, it will be free for use by anyone interested.&nbs= p; My thinking is that this project can bridge the gap until commercial sol= utions are available to augment it.  This is a similar path that was f= ollowed with DNS (bind) and HTTP (apache).  When it is ready for use, = I am hoping to use it to host USGCB content.  You would be welcome to = use it for your needs.=

 

It is good that OCIL is moving forward.  This is an= important piece of supporting risk management and aspects of continuous mo= nitoring.  I would also like to see some discussion on OCIL at Develop= er Days.  With the proposals we will likely have a sense of what needs= to be discussed and what we can achieve consensus on outside the meeting.<= /span>

 

Reme= diation is a topic near and dear to my heart.  I too would like to see= it move forward.

<= p class=3DMsoNormal> 

We just published the draft ASR specification for public com= ment.  This specification supports enterprise aggregate reporting whic= h greatly reduces the data volumes needed verses detailed host-based report= s. This specification has been designed as a more robust replacement for LA= SR.  It can be used in continuous monitoring applications to support a= ggregate data reporting needs (e.g. FISMA reporting,  CyberScope).

<= span style=3D'color:#1F497D'> =

Here ar= e the links:

 

http= ://csrc.nist.gov/publications/PubsDrafts.html

http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848=

 <= o:p>

The= primary reason we have suggested waiting on XCCDF is not the international= ization issue. Many vendors have commented that they are still working on i= mplementing the XCCDF 1.2.1 specification. We will be in a better place in = a few months once more development around XCCDF has occurred.  As we c= onsider changes to the SCAP stack to address OCIL and other issues, we will= identify areas that need improvement in XCCDF.  These are good and ne= cessary discussions to have now, but we have a good deal of work to do befo= re we are ready to open up XCCDF.  My suggestion is to work on these r= elated areas and then work up change proposals for XCCDF as needed.  B= y that time we should be ready to work on a new revision of XCCDF.

 

I am also lo= oking forward to the discussions at the conference.  It has been too l= ong.

 

Sincerely,

Dave

 

From: Kinne= y, Michael A [mailto:m.kinne@rad= ium.ncsc.mil]
Sent: Tuesday, May 08, 2012 7:09 AM
To:<= /b> SCAP-DEV
Cc: Waltermire, David A.
Subject: RE: [OVA= L-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE = in Bedford, MA

 <= /span>

Kent,

 

It’s g= ood to read your thoughts, and a realistic actionable approach is indeed ne= eded.  Since all the activity hasn’t been on the lists a brief 1= =AE2 hour recap may be in order to bring everyone up to speed since there h= as been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

<= span style=3D'color:#1F497D'> =

We coul= d write a content repository specification, but without someone willing to = stand one up it will be as valuable as the CCSS specification is today. &nb= sp;I’ve been trying for two years to get my management to get a coord= inated effort together for the DoD to stand up a repository, it is a tough = problem and will require funding with a tail, I’m not sure a specific= ation will solve that problem.

 

We (DoD) have been putting a lot of effort into = OCIL over the last year trying to make it useful in an enterprise environme= nt and will be posting our ideas to the list before developer days it shoul= d have already started, we need to get consensus and a vote on how the comm= unity wishes to proceed.

 

Remediation is stalled but I’m making every effo= rt to get it kick started from our perspective. I hope to assist in getting= the draft ERI finished this year.  We are writing some new STIG conte= nt and intend to used the draft CRE specification to insert CRE into the co= ntent so we (DoD) can do some automatic configuration fixes, part of a self= healing network concept. It is just a start but the best we can do at this= point.

 

Enterprise reporting is an interesting subject, since XML adds size to = and content to roll up reporting, in any enterprise of size the problem get= s greater, I look forward to your thoughts on that subject.

 

I am concerned th= at the internationalization efforts are detracting from efforts to meet use= cases, we have some things we would like changed in XCCDF to support our O= CIl use case and I have been told that I need to wait. I didn’t think= that a move to internationalization should impede efforts to move forward = with use cases.

 

I look forward to talking with you at the conference.

 =

v/r=

 

Mike Kinney

Project Director=

Computer Network Defense Research and Technol= ogy (CND R&T) Office

9800 Savage Road Ste 6767
Ft Meade, MD 2= 0755-6767
Phone: 4= 10-854-4422
NSTS: 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

 

 

Kent,=

 <= o:p>

I l= ike what you are saying here.  We are also in support of this type of = approach.  We would like to see some community discussion around what = are the key areas/priorities that the community would like to see discussed= at Dev Days.  Your topics below look like a good start. The SACM list= might be a better venue than the OVAL list for this discussion.  For = each area we should focus the discussion around developing objectives for e= ach session.  The sessions can be time boxed based on what would be a = reasonable amount of time to accomplish each objective.  For example i= f continuous monitoring is a priority and collectively it takes 3 days to w= ork through all the objectives, I see no problem with that.  We can al= so keep a few sessions “on deck” if all the objectives are reac= hed and we complete all the scheduled sessions early.

 

<= p class=3DMsoNormal>Thoughts?

 

Sincerely,

 

David Waltermire

SCAP Architect=

National Inst= itute of Standards and Technology

(301) 975= -3390

david.waltermire@nist.gov

 <= o:p>

From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov] On= Behalf Of Kent_Landfield@= mcafee.com
Sent: Monday, May 07, 2012 4:25 PM
To: S= CAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation De= veloper Days: Summer 2012 at MITRE in Bedford, MA

 

All,

 

I would li= ke to discuss the format for the SCAP Developer Days that seems to be liste= d below.

 

I see this appears to follow a path we have d= iscussed in the past as the way not to hold a Dev Days event.  We have= been trying to get away from 'Death by Powerpoint' and back to the type of= event we held years ago when we were highly productive.  In the past = we had a topic to be discussed and a time box to work within.  That al= lowed us to have very active brainstorming sessions in a high bandwidth env= ironment.

 

At past Summer events we have got into a patt= ern of lots of powerpoint, lots of status of the efforts and very little di= scussion about things that need active discussions.  We need to keep m= oving forward and making progress as an effort. We can get status from vari= ous places such as the lists, a presentation being sent out in advance, a w= ebinar if it is felt there will be questions and answers from those that ar= e new to the efforts.  We have a limited amount of time and all who ar= e attending are investing a great deal of time and money to be there.  = ;We should not  be spending a great deal of time reeducating everyone = when we could be focused on advancing needed efforts.

=

 

Th= e type of approach to a Dev Days event was discussed at the last Summer Dev= Days.  I have seen the following work quite well in other efforts.

  1. Presentations are sent out to the attendees and the lists = a week in advance.
  2. Status for any effort is limited to 30 minutes
  3. Focused brainstorming time should be est= ablished for certain areas that need real work by the community<= /li>
  4. Efforts to be discussed sho= uld be based on needs of the security automation space to move existing eff= orts to completion.

For example:

 

Continuous monitoring is= a major direction the efforts are becoming involved with. There are going = to be things we need to do as a security automation community to be able to= accomplish what is listed in the CAESARS FE.  There are interfaces th= at need to be worked and established.  That is one area that is not li= sted below.  CM will have a major impact on all of us in the next coup= le years and it is being ignored.  We can't keep trying to solve what = has already been solved.  We need to address the needed interface deve= lopment now. This is an effort that could take nearly a whole day by itself= .

 

Operationally we have a real need to be able to delive= r SCAP content internally within an organization. Today the SCAP vendors ca= nnot share a single local site security policy (XCCDF + OVAL + CPE +…= ) without the site staff having to go to each of the individual products an= d figuring out how to inject that new or updated policy into that products = delivery mechanisms.  That is limiting sites from wanting to buy multi= ple focused SCAP products since they are such a pain to manage from a conte= nt perspective.  It is easier to buy from one vendor that has a single= means for distributing content than it is to deal with the management issu= es that having multiple SCAP products presents.  We need to have at le= ast an entire 1/2 a day on the development of a Content Repository specific= ation.

 

OCIL is a positive and a negative at the same tim= e. It has real value that is being underutilized and under implemented beca= use of the limitations of how it addresses uses in an enterprise environmen= t.  People don't need security automation to do things on/for a single= host.  They need security automation to focus on the enterprise issue= s that reduce their costs and improve their efficiencies.  OCIL is fai= ling in the enterprise and we all understand that.  We need to address= developing a definitive solution for incorporating OCIL into the enterpris= e and that means into the existing specifications. Scheduling and tracking = are key to it's success.  We need to make that happen.  This too = needs a focused brainstorming time box to discuss options.

 

I am really disappointed that Remediation is not on the list below…= ;  Yes, last Summer Dev Days, the time spent on Remediation was wasted= time but that does not mean we should ignore it and not try to make some r= eal progress.  As far as I am concerned we need to reboot the remediat= ion effort.  We cannot keep being the set of specifications / tools th= at act as the little boy crying "Wolf" in the night.  We nee= d to be able to find and fix issues if we are going to really make a differ= ence in organizational security postures.  But today we think it is to= o hard so we don't try ?  I think we need a couple hours to discuss th= e reboot of the effort even if that means minimizing work already done.

 

A focused discussion on enterprise reporting is also criti= cally needed.  For the vendors here, we have all gone through the Cybe= rscope goat rope, delivering limited capabilities to specific data call req= uirements of the Federal Agencies.  The initial effort was a mess, did= little more than prove it was possible and cause the vendor community a gr= eat deal of thrashing to put a kludgey 'solution' in place.  Reality i= s all our customers need roll up reporting and an infrastructure that suppo= rts it.  A data call should not be special to anyone other than the ag= encies responding. The tools should be able to select the types of data nee= ded and deliver that on a scheduled basis automatically.    Enter= prise Reporting pertains to commercial as well as Federal customers.  = We need to focus some time on what that would look like using the ARF and A= SR as the foundational pieces.  But there are missing pieces…. &= nbsp;We need this discussed.

 

<= p class=3DMsoNormal>I would hope we can make th= is summer's SCAP Dev Days useful in advancing the security automation effor= ts by addressing some of the more critical issues our customers are facing = now or will be facing in the very short term.  Status presentations ar= e not interesting to those active in the efforts.  Let's try to do tho= se before we get to Bedford so we can real make some progress while we are = all in the same room.  This is always a big event for the 'consensus o= f the willing' that assemble and driven to see security automation make a d= ifference.  Let's see if we can have an event that, when we all walk o= ut the last day, we all feel that every minute was well spent and moves us = forward.

 

Thanks.

 

Kent Landfield
Director Content Strategy, Architec= ture and Standards

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

Direct:= +1.972.963.7096 
Mobile: +1.= 817.637.8026
Web: www.mcafee.com

 

From: = <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply-To: "= OVAL Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG= >
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Devel= oper Days: Summer 2012 at MITRE in Bedford, MA

<= div>

 <= o:p>

Frank= ;

 =

We= hope to have the registration site up next week.  The event will be d= uring the week of July 9 – starting Monday at 10:00 AM and ending on = Friday at 12:00.

 

Meanwhile, we are working on the agenda and are currently co= nsidering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF<= /span>

OVAL

<= p class=3DMsoNormal style=3D'margin-left:.5in'>ASR

Enterprise= OCIL

CybOX/MAEC=

Federated Conte= nt Repository Spec

=

Endpoint Reporting for Continuous Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases=

SCAP and IETF

NETCONF and SCAP=

 <= /span>

Steve

 = ;

<= p class=3DMsoNormal style=3D'margin-left:2.0in'>From:= Frank Lindsay Acker [mailto:afrank@NOVA= .EDU]
Sent: Tuesday, May 01, 2012 9:32 AM
To: oval= -developer-list OVAL Developer List/Closed Public Discussion
Subject:= Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA

 

Steve....

Has there been any additio= nal information regarding this event?

Thanks,
Frank Acker<= span style=3D'color:black'>

From: Boczenowski, Steve [sboczeno@M= ITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: <= a href=3D"mailto:OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG">OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Security Automa= tion Developer Days: Summer 2012 at MITRE in Bedford, MA

Save the Date: week= of July 9, 2012

 

This ye= ar’s MITRE-hosted Security Automation Developer Days event will be he= ld during the week of July 9, 2012 at MITRE’s facility in Bedford, MA= .

 

Details to follow.

 

Regards,

    Steve

 

____________________________= __________________

=

Stephen P.= Boczenowski

      The = MIT= RE Corporation

 = ;     Office: (781) 271-7682

      Cell: (978) 302-3849=

     sboczeno@mitre.org

 

To uns= ubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BO= DY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS= .MITRE.ORG.

To = unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the= BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with S= IGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficul= ties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

= --_000_D7A0423E5E193F40BE6E94126930C4930B99323F2EMBCLUSTERxcha_-- From RNATALE@mitre.org Fri May 11 10:45:23 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 CAFB321F86DC for ; Fri, 11 May 2012 10:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry+bWIsf0a44 for ; Fri, 11 May 2012 10:45:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D609421F86C7 for ; Fri, 11 May 2012 10:45:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E93921B18FB; Fri, 11 May 2012 13:45:21 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F3C9D21B1596; Fri, 11 May 2012 13:45:20 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Fri, 11 May 2012 13:45:20 -0400 From: "Natale, Bob" To: "sacm@ietf.org" Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQACFVVQ Date: Fri, 11 May 2012 17:45:19 +0000 Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.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.56] Content-Type: multipart/alternative; boundary="_000_A65E21691881E64DBF058A66E53068ED30FE6AIMCMBX01MITREORG_" MIME-Version: 1.0 Cc: "SCAP-DEV@nist.gov" Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 11 May 2012 17:45:23 -0000 --_000_A65E21691881E64DBF058A66E53068ED30FE6AIMCMBX01MITREORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With respect specifically to: "I believe the DoD needs to incorporate a met= adata repository as part of it" ... have you already (or will you) consider= the DoD MetaData Repository (MDR), now best reviewed as part of the overar= ching Data Services Environment (DSE), https://metadata.ces.mil/dse/homepag= e.htm. I am not suggesting that the MDR/DSE provides an appropriate solution for t= hat component or that it does not - just that it's an existing capability t= hat you might want to evaluate as a candidate solution for the metadata rep= ository requirements. Cheers, BobN From: , Michael A > To: David Waltermire >, SCAP-DEV >, "sacm@ietf= .org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionabl= e and use it to make decisions, and vote and accomplish things good or bad.= I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more... -Mike --_000_A65E21691881E64DBF058A66E53068ED30FE6AIMCMBX01MITREORG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With respect specifica= lly to: “I believe the DoD needs= to incorporate a metadata repository as part of it” … have you already (or will you) consider the DoD MetaData Repository (MDR), now best reviewed as part of t= he overarching Data Services Environment (DSE), https://metadata.ces.= mil/dse/homepage.htm.

 

I am not suggesting th= at the MDR/DSE provides an appropriate solution for that component or that = it does not – just that it’s an existing capability that you mi= ght want to evaluate as a candidate solution for the metadata repository requirements.

 

Cheers,

BobN=

 =

From: <Kinney>, Michael A <m.kinne@radium.ncsc.mil>
To: David Waltermire <david.waltermire@nist.gov>, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.o= rg>
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Develo= per Days: Summer 2012 at MITRE in Bedford, MA

 =

Dave,

I have no problem with= webinars, I do want to keep developer days actionable and use it to make d= ecisions, and vote and accomplish things good or bad.  I do not want t= his to be an informational briefing conference.

Thanks for the links.<= /span>

 

I still think that any= specification for a repository is wishful thinking until someone builds on= e and learns the lessons it will just be another whitepaper spec.  I b= elieve the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful f= or everyone.

We need to talk more&#= 8230;

 

-Mike 

--_000_A65E21691881E64DBF058A66E53068ED30FE6AIMCMBX01MITREORG_-- From gunnar.engelbach@threatguard.com Fri May 11 11:02: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 95E9C21F8427 for ; Fri, 11 May 2012 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEEzJ2TEkXbS for ; Fri, 11 May 2012 11:02:43 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id AF3AC21F8483 for ; Fri, 11 May 2012 11:02:43 -0700 (PDT) Received: (qmail 28702 invoked from network); 11 May 2012 12:05:46 -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); 11 May 2012 12:05:46 -0700 Message-ID: <4FAD544D.2090601@ThreatGuard.com> Date: Fri, 11 May 2012 14:02:53 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 11 May 2012 18:02:45 -0000 It would be great to have as many of these considerations as possible in mind from the start as the actual work begins. As another example, I'd like to see active participation from vendors that have commercial content repositories so those concerns also don't have to be later addressed with major changes. But we also see a lot of these type of topics come up on the lists, get discussed for a bit, then languish. If reducing the problem set is what it takes to spur some action, let's get started. It kinda sounds like this is headed towards having a dedicated working group to take it on, which is what I'd prefer to see, so I'm avoiding making specific comments until then. And my apologies to Dave: I'd like to see how much you've already addressed, but I just haven't had a chance to look through your draft yet. --gun ThreatGuard, Inc. On 5/11/2012 1:13 PM, Waltermire, David A. wrote: > Kent, > > I have already started work on a draft specification in this area. My > hope is that this work could be used as an initial draft within SACM at > the appropriate time. Count me in. > > I mostly agree with what you are describing below. The only area I > disagree with is in regards to federation. If we do not implement the > specification for an organizational repository in the right way, we may > need to make major changes to support federation. This is not good for > anyone. In my mind these two concepts cannot be decoupled. We need to > insure that any work towards supporting an organizational repository > provides a foundation for supporting a federated repository network. > Imagine if DNS was designed with a single organization mindset first > without thinking about federation. Top Level Domains (TLDs) and > subdomains would not likely exist as concepts. An individual DNS server > would likely not support caching, time-to-live and delegating > capabilities that are necessary for federation to happen. All of these > things would need to be retrofitted. To prevent this, we need to > address the building blocks of federation in the basic design. > > Sincerely, > > Dave > > *From:*Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] > *Sent:* Friday, May 11, 2012 12:36 PM > *To:* m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; sacm@ietf.org > *Subject:* Request for participants - Content Repository Specification > Development > > Mike I love it when you tee something up like that…. ;-) Thank you. ;) > > Mike wrote: > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will just be > another whitepaper spec. I believe the DoD needs to incorporate a > metadata repository as part of it and other customizations that may not > be useful for everyone. > > We need to talk more… > > If you are talking about a holistic, complete federated approach to a > content repository, I some what agree. If you are talking about an > organizational repository, I totally disagree. But you knew I would. ;) > > Here is how I see the problem. There is an immediate need for SCAP and > other related content to be served up inside an organization. Today we > have situation where the standards allow us to provide sites the > capability to have a single SCAP implemented policy they call official > for their environment. Yes this is a rather simplistic since there are > things such as targeting specific platforms, specific operational use > needs, but for now lets agree SCAP is a massive improvement over the > proprietary situations of the past. While we have created this standard > content so that sites can implement their local site security once and > then assure they are measuring all appropriately targeted devices the > same way, we have failed to support the operational needs of the sites. > We have a situation where no two vendors distribute content the same > way. This causes massive problems for the administration staff when they > need to incorporate a new SCAP enabled product into their architecture. > They need to discover how the new product supports distributing SCAP > content to it's various components. If they have one product then they > do this one and they are done. If they have multiple products they will > have to figure out how to minimize the impact by incorporating the > update process for the new product into the existing SCAP security > content processes. Now when the inevitable happens and the site staff > needs to make a change to their security policy, they have to make the > modifications to the benchmark or checks or both and then distribute > those updates across their network. For each SCAP enabled product they > have in place, they have doubled, tripled or more the work needed to > make those updates available. > > There is another content repository problem and that is the Federated > Content Distribution. If you think global DNS you have a general frame > of reference. The guidance authors need to be able to publish content in > an authoritative manner so their content is updated in a timely fashion. > This is a much harder problem to solve if there is no local > organizational infrastructure to support it. ;) > > So here is what I am thinking… We should consider addressing these as > two separate but integrated efforts. I believe the Organizational > Content Repository is the more critical piece that is actually easier to > address. The Federated Content Distribution should be a subsequent > effort integrating / augmenting the Organizational repository > specification. > > Mike, to your point that we need someone to build one first… That has > happened already. I have one as do other vendors but what we don’t have > is the access specification. Ours are focused on our specific product > needs. Additionally there is a company that has developed a commercial > SCAP content repository that will be announced later this month. I won't > steal their thunder but I was recently given a sneak peek at it and I > must admit I was very impressed. Again, to your point, it has been done. > What is needed to address the initial operational problem is to develop > a specification that provides a consistent means for all SCAP products > to retrieve the appropriate content as configured and managed but the site. > > TO THAT END…. > > I am requesting participation from those in the community that see the > need and want to put in the work to make this specification happen. I > have talked to a couple of you but I do not want to assume your > participation. If you are interested please contact me so we can get > this started. > > Thanks! > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Michael A > > *To: *David Waltermire >, SCAP-DEV >, "sacm@ietf.org " > > > *Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Dave, > > I have no problem with webinars, I do want to keep developer days > actionable and use it to make decisions, and vote and accomplish > things good or bad. I do not want this to be an informational > briefing conference. > > Thanks for the links. > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will > just be another whitepaper spec. I believe the DoD needs to > incorporate a metadata repository as part of it and other > customizations that may not be useful for everyone. > > We need to talk more… > > -Mike > > *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] > *Sent:* Tuesday, May 08, 2012 10:44 AM > *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Mike, > > What about having webinars in-place of the 30 minute briefs? > > Regarding content management, we are building the prototype content > repository for use in a production environment. As an open source > project, it will be free for use by anyone interested. My thinking > is that this project can bridge the gap until commercial solutions > are available to augment it. This is a similar path that was > followed with DNS (bind) and HTTP (apache). When it is ready for > use, I am hoping to use it to host USGCB content. You would be > welcome to use it for your needs. > > It is good that OCIL is moving forward. This is an important piece > of supporting risk management and aspects of continuous monitoring. > I would also like to see some discussion on OCIL at Developer Days. > With the proposals we will likely have a sense of what needs to be > discussed and what we can achieve consensus on outside the meeting. > > Remediation is a topic near and dear to my heart. I too would like > to see it move forward. > > We just published the draft ASR specification for public comment. > This specification supports enterprise aggregate reporting which > greatly reduces the data volumes needed verses detailed host-based > reports. This specification has been designed as a more robust > replacement for LASR. It can be used in continuous monitoring > applications to support aggregate data reporting needs (e.g. FISMA > reporting, CyberScope). > > Here are the links: > > http://csrc.nist.gov/publications/PubsDrafts.html > > http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 > > The primary reason we have suggested waiting on XCCDF is not the > internationalization issue. Many vendors have commented that they > are still working on implementing the XCCDF 1.2.1 specification. We > will be in a better place in a few months once more development > around XCCDF has occurred. As we consider changes to the SCAP stack > to address OCIL and other issues, we will identify areas that need > improvement in XCCDF. These are good and necessary discussions to > have now, but we have a good deal of work to do before we are ready > to open up XCCDF. My suggestion is to work on these related areas > and then work up change proposals for XCCDF as needed. By that time > we should be ready to work on a new revision of XCCDF. > > I am also looking forward to the discussions at the conference. It > has been too long. > > Sincerely, > > Dave > > *From:*Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] > *Sent:* Tuesday, May 08, 2012 7:09 AM > *To:* SCAP-DEV > *Cc:* Waltermire, David A. > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > It’s good to read your thoughts, and a realistic actionable approach > is indeed needed. Since all the activity hasn’t been on the lists a > brief 1Ž2 hour recap may be in order to bring everyone up to speed > since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX > CEE and others. > > We could write a content repository specification, but without > someone willing to stand one up it will be as valuable as the CCSS > specification is today. I’ve been trying for two years to get my > management to get a coordinated effort together for the DoD to stand > up a repository, it is a tough problem and will require funding with > a tail, I’m not sure a specification will solve that problem. > > We (DoD) have been putting a lot of effort into OCIL over the last > year trying to make it useful in an enterprise environment and will > be posting our ideas to the list before developer days it should > have already started, we need to get consensus and a vote on how the > community wishes to proceed. > > Remediation is stalled but I’m making every effort to get it kick > started from our perspective. I hope to assist in getting the draft > ERI finished this year. We are writing some new STIG content and > intend to used the draft CRE specification to insert CRE into the > content so we (DoD) can do some automatic configuration fixes, part > of a self healing network concept. It is just a start but the best > we can do at this point. > > Enterprise reporting is an interesting subject, since XML adds size > to and content to roll up reporting, in any enterprise of size the > problem gets greater, I look forward to your thoughts on that subject. > > I am concerned that the internationalization efforts are detracting > from efforts to meet use cases, we have some things we would like > changed in XCCDF to support our OCIl use case and I have been told > that I need to wait. I didn’t think that a move to > internationalization should impede efforts to move forward with use > cases. > > I look forward to talking with you at the conference. > > v/r > > Mike Kinney > > Project Director > > Computer Network Defense Research and Technology (CND R&T) Office > > 9800 Savage Road Ste 6767 > Ft Meade, MD 20755-6767 > Phone: 410-854-4422 > NSTS: 968-8886 > Fax 410-854-4681 > > makinn2@nsa.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Waltermire, David A. > *Sent:* Monday, May 07, 2012 7:09 PM > *To:* Multiple recipients of list > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > I like what you are saying here. We are also in support of this type > of approach. We would like to see some community discussion around > what are the key areas/priorities that the community would like to > see discussed at Dev Days. Your topics below look like a good start. > The SACM list might be a better venue than the OVAL list for this > discussion. For each area we should focus the discussion around > developing objectives for each session. The sessions can be time > boxed based on what would be a reasonable amount of time to > accomplish each objective. For example if continuous monitoring is a > priority and collectively it takes 3 days to work through all the > objectives, I see no problem with that. We can also keep a few > sessions “on deck” if all the objectives are reached and we complete > all the scheduled sessions early. > > Thoughts? > > Sincerely, > > David Waltermire > > SCAP Architect > > National Institute of Standards and Technology > > (301) 975-3390 > > david.waltermire@nist.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Kent_Landfield@mcafee.com > *Sent:* Monday, May 07, 2012 4:25 PM > *To:* SCAP-DEV > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > All, > > I would like to discuss the format for the SCAP Developer Days that > seems to be listed below. > > I see this appears to follow a path we have discussed in the past as > the way not to hold a Dev Days event. We have been trying to get > away from 'Death by Powerpoint' and back to the type of event we > held years ago when we were highly productive. In the past we had a > topic to be discussed and a time box to work within. That allowed us > to have very active brainstorming sessions in a high bandwidth > environment. > > At past Summer events we have got into a pattern of lots of > powerpoint, lots of status of the efforts and very little discussion > about things that need active discussions. We need to keep moving > forward and making progress as an effort. We can get status from > various places such as the lists, a presentation being sent out in > advance, a webinar if it is felt there will be questions and answers > from those that are new to the efforts. We have a limited amount of > time and all who are attending are investing a great deal of time > and money to be there. We should not be spending a great deal of > time reeducating everyone when we could be focused on advancing > needed efforts. > > The type of approach to a Dev Days event was discussed at the last > Summer Dev Days. I have seen the following work quite well in other > efforts. > > 1. Presentations are sent out to the attendees and the lists a week > in advance. > 2. Status for any effort is limited to 30 minutes > 3. Focused brainstorming time should be established for certain > areas that need real work by the community > 4. Efforts to be discussed should be based on needs of the security > automation space to move existing efforts to completion. > > For example: > > Continuous monitoring is a major direction the efforts are becoming > involved with. There are going to be things we need to do as a > security automation community to be able to accomplish what is > listed in the CAESARS FE. There are interfaces that need to be > worked and established. That is one area that is not listed below. > CM will have a major impact on all of us in the next couple years > and it is being ignored. We can't keep trying to solve what has > already been solved. We need to address the needed interface > development now. This is an effort that could take nearly a whole > day by itself. > > Operationally we have a real need to be able to deliver SCAP content > internally within an organization. Today the SCAP vendors cannot > share a single local site security policy (XCCDF + OVAL + CPE +…) > without the site staff having to go to each of the individual > products and figuring out how to inject that new or updated policy > into that products delivery mechanisms. That is limiting sites from > wanting to buy multiple focused SCAP products since they are such a > pain to manage from a content perspective. It is easier to buy from > one vendor that has a single means for distributing content than it > is to deal with the management issues that having multiple SCAP > products presents. We need to have at least an entire 1/2 a day on > the development of a Content Repository specification. > > OCIL is a positive and a negative at the same time. It has real > value that is being underutilized and under implemented because of > the limitations of how it addresses uses in an enterprise > environment. People don't need security automation to do things > on/for a single host. They need security automation to focus on the > enterprise issues that reduce their costs and improve their > efficiencies. OCIL is failing in the enterprise and we all > understand that. We need to address developing a definitive solution > for incorporating OCIL into the enterprise and that means into the > existing specifications. Scheduling and tracking are key to it's > success. We need to make that happen. This too needs a focused > brainstorming time box to discuss options. > > I am really disappointed that Remediation is not on the list below… > Yes, last Summer Dev Days, the time spent on Remediation was wasted > time but that does not mean we should ignore it and not try to make > some real progress. As far as I am concerned we need to reboot the > remediation effort. We cannot keep being the set of specifications / > tools that act as the little boy crying "Wolf" in the night. We need > to be able to find and fix issues if we are going to really make a > difference in organizational security postures. But today we think > it is too hard so we don't try ? I think we need a couple hours to > discuss the reboot of the effort even if that means minimizing work > already done. > > A focused discussion on enterprise reporting is also critically > needed. For the vendors here, we have all gone through the > Cyberscope goat rope, delivering limited capabilities to specific > data call requirements of the Federal Agencies. The initial effort > was a mess, did little more than prove it was possible and cause the > vendor community a great deal of thrashing to put a kludgey > 'solution' in place. Reality is all our customers need roll up > reporting and an infrastructure that supports it. A data call should > not be special to anyone other than the agencies responding. The > tools should be able to select the types of data needed and deliver > that on a scheduled basis automatically. Enterprise Reporting > pertains to commercial as well as Federal customers. We need to > focus some time on what that would look like using the ARF and ASR > as the foundational pieces. But there are missing pieces…. We need > this discussed. > > I would hope we can make this summer's SCAP Dev Days useful in > advancing the security automation efforts by addressing some of the > more critical issues our customers are facing now or will be facing > in the very short term. Status presentations are not interesting to > those active in the efforts. Let's try to do those before we get to > Bedford so we can real make some progress while we are all in the > same room. This is always a big event for the 'consensus of the > willing' that assemble and driven to see security automation make a > difference. Let's see if we can have an event that, when we all walk > out the last day, we all feel that every minute was well spent and > moves us forward. > > Thanks. > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Steve > > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > > > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > " > > > *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Frank; > > We hope to have the registration site up next week. The event > will be during the week of July 9 – starting Monday at 10:00 AM > and ending on Friday at 12:00. > > Meanwhile, we are working on the agenda and are currently > considering this list of topics: > > CCE > > CPE/SWID > > CEE > > XCCDF > > OVAL > > ASR > > Enterprise OCIL > > CybOX/MAEC > > Federated Content Repository Spec > > Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) > > MILE > > TAXII > > IF-M for SCAP > > IF-MAP > > SCAP Releases > > SCAP and IETF > > NETCONF and SCAP > > Steve > > *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU] > *Sent:* Tuesday, May 01, 2012 9:32 AM > *To:* oval-developer-list OVAL Developer List/Closed Public > Discussion > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Steve.... > > Has there been any additional information regarding this event? > > Thanks, > Frank Acker > > ------------------------------------------------------------------------ > > *From:*Boczenowski, Steve [sboczeno@MITRE.ORG > ] > *Sent:* Tuesday, March 20, 2012 16:38 > *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > > *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Save the Date: week of July 9, 2012 > > This year’s MITRE-hosted Security Automation Developer Days > event will be held during the week of July 9, 2012 at MITRE’s > facility in Bedford, MA. > > Details to follow. > > Regards, > > Steve > > ______________________________________________ > > /Stephen P. Boczenowski/ > > The MITRECorporation > > Office: (781) 271-7682 > > Cell: (978) 302-3849 > > sboczeno@mitre.org > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From bchandra@secpod.com Fri May 11 23:43: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 87ED421F857F for ; Fri, 11 May 2012 23:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NxITPkB7lMA for ; Fri, 11 May 2012 23:43:40 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 86D2321F857A for ; Fri, 11 May 2012 23:43:40 -0700 (PDT) Received: from [182.72.99.242] (port=2688 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1ST63F-0001zi-BN; Sat, 12 May 2012 12:13:38 +0530 From: "Chandrashekhar B" To: "'SCAP-DEV'" , References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <4FAD544D.2090601@ThreatGuard.com> In-Reply-To: <4FAD544D.2090601@ThreatGuard.com> Date: Sat, 12 May 2012 12:13:29 +0530 Organization: SecPod Technologies Message-ID: <04a001cd300a$8c816970$a5843c50$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIK+AsmsxvscjAWr3S8jTQP4mAzmQJt5r4nAUXjM/wBLq8ZKJYjDpSA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sacm] Request for participants - Content Repository Specification Development X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.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: Sat, 12 May 2012 06:43:42 -0000 Having a standard access interface is really important for content repository. I had proposed a simple WSDL in a presentation I shared with Kent, last year's ITSAC. We are looking forward to take active = participation in it. Thanks, Chandra. www.secpod.com -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 11, 2012 11:33 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specification Development It would be great to have as many of these considerations as possible in mind from the start as the actual work begins. As another example, I'd = like to see active participation from vendors that have commercial content repositories so those concerns also don't have to be later addressed = with major changes. But we also see a lot of these type of topics come up on the lists, get discussed for a bit, then languish. If reducing the problem set is what = it takes to spur some action, let's get started. It kinda sounds like this is headed towards having a dedicated working = group to take it on, which is what I'd prefer to see, so I'm avoiding making specific comments until then. And my apologies to Dave: I'd like to see how much you've already addressed, but I just haven't had a chance to look through your draft = yet. --gun ThreatGuard, Inc. On 5/11/2012 1:13 PM, Waltermire, David A. wrote: > Kent, > > I have already started work on a draft specification in this area. My > hope is that this work could be used as an initial draft within SACM = at > the appropriate time. Count me in. > > I mostly agree with what you are describing below. The only area I > disagree with is in regards to federation. If we do not implement the > specification for an organizational repository in the right way, we = may > need to make major changes to support federation. This is not good = for > anyone. In my mind these two concepts cannot be decoupled. We need = to > insure that any work towards supporting an organizational repository > provides a foundation for supporting a federated repository network. > Imagine if DNS was designed with a single organization mindset first > without thinking about federation. Top Level Domains (TLDs) and > subdomains would not likely exist as concepts. An individual DNS = server > would likely not support caching, time-to-live and delegating > capabilities that are necessary for federation to happen. All of = these > things would need to be retrofitted. To prevent this, we need to > address the building blocks of federation in the basic design. > > Sincerely, > > Dave > > *From:*Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] > *Sent:* Friday, May 11, 2012 12:36 PM > *To:* m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; sacm@ietf.org > *Subject:* Request for participants - Content Repository Specification > Development > > Mike I love it when you tee something up like that.. ;-) Thank you. ;) > > Mike wrote: > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will just = be > another whitepaper spec. I believe the DoD needs to incorporate a > metadata repository as part of it and other customizations that may = not > be useful for everyone. > > We need to talk more. > > If you are talking about a holistic, complete federated approach to a > content repository, I some what agree. If you are talking about an > organizational repository, I totally disagree. But you knew I would. = ;) > > Here is how I see the problem. There is an immediate need for SCAP and > other related content to be served up inside an organization. Today we > have situation where the standards allow us to provide sites the > capability to have a single SCAP implemented policy they call official > for their environment. Yes this is a rather simplistic since there are > things such as targeting specific platforms, specific operational use > needs, but for now lets agree SCAP is a massive improvement over the > proprietary situations of the past. While we have created this = standard > content so that sites can implement their local site security once and > then assure they are measuring all appropriately targeted devices the > same way, we have failed to support the operational needs of the = sites. > We have a situation where no two vendors distribute content the same > way. This causes massive problems for the administration staff when = they > need to incorporate a new SCAP enabled product into their = architecture. > They need to discover how the new product supports distributing SCAP > content to it's various components. If they have one product then they > do this one and they are done. If they have multiple products they = will > have to figure out how to minimize the impact by incorporating the > update process for the new product into the existing SCAP security > content processes. Now when the inevitable happens and the site staff > needs to make a change to their security policy, they have to make the > modifications to the benchmark or checks or both and then distribute > those updates across their network. For each SCAP enabled product they > have in place, they have doubled, tripled or more the work needed to > make those updates available. > > There is another content repository problem and that is the Federated > Content Distribution. If you think global DNS you have a general frame > of reference. The guidance authors need to be able to publish content = in > an authoritative manner so their content is updated in a timely = fashion. > This is a much harder problem to solve if there is no local > organizational infrastructure to support it. ;) > > So here is what I am thinking. We should consider addressing these as > two separate but integrated efforts. I believe the Organizational > Content Repository is the more critical piece that is actually easier = to > address. The Federated Content Distribution should be a subsequent > effort integrating / augmenting the Organizational repository > specification. > > Mike, to your point that we need someone to build one first. That has > happened already. I have one as do other vendors but what we don't = have > is the access specification. Ours are focused on our specific product > needs. Additionally there is a company that has developed a commercial > SCAP content repository that will be announced later this month. I = won't > steal their thunder but I was recently given a sneak peek at it and I > must admit I was very impressed. Again, to your point, it has been = done. > What is needed to address the initial operational problem is to = develop > a specification that provides a consistent means for all SCAP products > to retrieve the appropriate content as configured and managed but the site. > > TO THAT END.. > > I am requesting participation from those in the community that see the > need and want to put in the work to make this specification happen. I > have talked to a couple of you but I do not want to assume your > participation. If you are interested please contact me so we can get > this started. > > Thanks! > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Michael A > > *To: *David Waltermire >, SCAP-DEV >, "sacm@ietf.org " > > > *Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Dave, > > I have no problem with webinars, I do want to keep developer days > actionable and use it to make decisions, and vote and accomplish > things good or bad. I do not want this to be an informational > briefing conference. > > Thanks for the links. > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will > just be another whitepaper spec. I believe the DoD needs to > incorporate a metadata repository as part of it and other > customizations that may not be useful for everyone. > > We need to talk more. > > -Mike > > *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] > *Sent:* Tuesday, May 08, 2012 10:44 AM > *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Mike, > > What about having webinars in-place of the 30 minute briefs? > > Regarding content management, we are building the prototype = content > repository for use in a production environment. As an open source > project, it will be free for use by anyone interested. My thinking > is that this project can bridge the gap until commercial solutions > are available to augment it. This is a similar path that was > followed with DNS (bind) and HTTP (apache). When it is ready for > use, I am hoping to use it to host USGCB content. You would be > welcome to use it for your needs. > > It is good that OCIL is moving forward. This is an important piece > of supporting risk management and aspects of continuous = monitoring. > I would also like to see some discussion on OCIL at Developer = Days. > With the proposals we will likely have a sense of what needs to be > discussed and what we can achieve consensus on outside the = meeting. > > Remediation is a topic near and dear to my heart. I too would like > to see it move forward. > > We just published the draft ASR specification for public comment. > This specification supports enterprise aggregate reporting which > greatly reduces the data volumes needed verses detailed host-based > reports. This specification has been designed as a more robust > replacement for LASR. It can be used in continuous monitoring > applications to support aggregate data reporting needs (e.g. FISMA > reporting, CyberScope). > > Here are the links: > > http://csrc.nist.gov/publications/PubsDrafts.html > > http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 > > The primary reason we have suggested waiting on XCCDF is not the > internationalization issue. Many vendors have commented that they > are still working on implementing the XCCDF 1.2.1 specification. = We > will be in a better place in a few months once more development > around XCCDF has occurred. As we consider changes to the SCAP = stack > to address OCIL and other issues, we will identify areas that need > improvement in XCCDF. These are good and necessary discussions to > have now, but we have a good deal of work to do before we are = ready > to open up XCCDF. My suggestion is to work on these related areas > and then work up change proposals for XCCDF as needed. By that = time > we should be ready to work on a new revision of XCCDF. > > I am also looking forward to the discussions at the conference. It > has been too long. > > Sincerely, > > Dave > > *From:*Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] > *Sent:* Tuesday, May 08, 2012 7:09 AM > *To:* SCAP-DEV > *Cc:* Waltermire, David A. > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > It's good to read your thoughts, and a realistic actionable = approach > is indeed needed. Since all the activity hasn't been on the lists = a > brief 1=AE2 hour recap may be in order to bring everyone up to = speed > since there has been a lot of activity on CPE/SWID, OCIl, = MAEC/CybOX > CEE and others. > > We could write a content repository specification, but without > someone willing to stand one up it will be as valuable as the CCSS > specification is today. I've been trying for two years to get my > management to get a coordinated effort together for the DoD to = stand > up a repository, it is a tough problem and will require funding = with > a tail, I'm not sure a specification will solve that problem. > > We (DoD) have been putting a lot of effort into OCIL over the last > year trying to make it useful in an enterprise environment and = will > be posting our ideas to the list before developer days it should > have already started, we need to get consensus and a vote on how = the > community wishes to proceed. > > Remediation is stalled but I'm making every effort to get it kick > started from our perspective. I hope to assist in getting the = draft > ERI finished this year. We are writing some new STIG content and > intend to used the draft CRE specification to insert CRE into the > content so we (DoD) can do some automatic configuration fixes, = part > of a self healing network concept. It is just a start but the best > we can do at this point. > > Enterprise reporting is an interesting subject, since XML adds = size > to and content to roll up reporting, in any enterprise of size the > problem gets greater, I look forward to your thoughts on that = subject. > > I am concerned that the internationalization efforts are = detracting > from efforts to meet use cases, we have some things we would like > changed in XCCDF to support our OCIl use case and I have been told > that I need to wait. I didn't think that a move to > internationalization should impede efforts to move forward with = use > cases. > > I look forward to talking with you at the conference. > > v/r > > Mike Kinney > > Project Director > > Computer Network Defense Research and Technology (CND R&T) Office > > 9800 Savage Road Ste 6767 > Ft Meade, MD 20755-6767 > Phone: 410-854-4422 > NSTS: 968-8886 > Fax 410-854-4681 > > makinn2@nsa.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Waltermire, David A. > *Sent:* Monday, May 07, 2012 7:09 PM > *To:* Multiple recipients of list > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > I like what you are saying here. We are also in support of this = type > of approach. We would like to see some community discussion around > what are the key areas/priorities that the community would like to > see discussed at Dev Days. Your topics below look like a good = start. > The SACM list might be a better venue than the OVAL list for this > discussion. For each area we should focus the discussion around > developing objectives for each session. The sessions can be time > boxed based on what would be a reasonable amount of time to > accomplish each objective. For example if continuous monitoring is = a > priority and collectively it takes 3 days to work through all the > objectives, I see no problem with that. We can also keep a few > sessions "on deck" if all the objectives are reached and we = complete > all the scheduled sessions early. > > Thoughts? > > Sincerely, > > David Waltermire > > SCAP Architect > > National Institute of Standards and Technology > > (301) 975-3390 > > david.waltermire@nist.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Kent_Landfield@mcafee.com > *Sent:* Monday, May 07, 2012 4:25 PM > *To:* SCAP-DEV > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > All, > > I would like to discuss the format for the SCAP Developer Days = that > seems to be listed below. > > I see this appears to follow a path we have discussed in the past = as > the way not to hold a Dev Days event. We have been trying to get > away from 'Death by Powerpoint' and back to the type of event we > held years ago when we were highly productive. In the past we had = a > topic to be discussed and a time box to work within. That allowed = us > to have very active brainstorming sessions in a high bandwidth > environment. > > At past Summer events we have got into a pattern of lots of > powerpoint, lots of status of the efforts and very little = discussion > about things that need active discussions. We need to keep moving > forward and making progress as an effort. We can get status from > various places such as the lists, a presentation being sent out in > advance, a webinar if it is felt there will be questions and = answers > from those that are new to the efforts. We have a limited amount = of > time and all who are attending are investing a great deal of time > and money to be there. We should not be spending a great deal of > time reeducating everyone when we could be focused on advancing > needed efforts. > > The type of approach to a Dev Days event was discussed at the last > Summer Dev Days. I have seen the following work quite well in = other > efforts. > > 1. Presentations are sent out to the attendees and the lists a = week > in advance. > 2. Status for any effort is limited to 30 minutes > 3. Focused brainstorming time should be established for certain > areas that need real work by the community > 4. Efforts to be discussed should be based on needs of the = security > automation space to move existing efforts to completion. > > For example: > > Continuous monitoring is a major direction the efforts are = becoming > involved with. There are going to be things we need to do as a > security automation community to be able to accomplish what is > listed in the CAESARS FE. There are interfaces that need to be > worked and established. That is one area that is not listed below. > CM will have a major impact on all of us in the next couple years > and it is being ignored. We can't keep trying to solve what has > already been solved. We need to address the needed interface > development now. This is an effort that could take nearly a whole > day by itself. > > Operationally we have a real need to be able to deliver SCAP = content > internally within an organization. Today the SCAP vendors cannot > share a single local site security policy (XCCDF + OVAL + CPE +.) > without the site staff having to go to each of the individual > products and figuring out how to inject that new or updated policy > into that products delivery mechanisms. That is limiting sites = from > wanting to buy multiple focused SCAP products since they are such = a > pain to manage from a content perspective. It is easier to buy = from > one vendor that has a single means for distributing content than = it > is to deal with the management issues that having multiple SCAP > products presents. We need to have at least an entire 1/2 a day on > the development of a Content Repository specification. > > OCIL is a positive and a negative at the same time. It has real > value that is being underutilized and under implemented because of > the limitations of how it addresses uses in an enterprise > environment. People don't need security automation to do things > on/for a single host. They need security automation to focus on = the > enterprise issues that reduce their costs and improve their > efficiencies. OCIL is failing in the enterprise and we all > understand that. We need to address developing a definitive = solution > for incorporating OCIL into the enterprise and that means into the > existing specifications. Scheduling and tracking are key to it's > success. We need to make that happen. This too needs a focused > brainstorming time box to discuss options. > > I am really disappointed that Remediation is not on the list = below. > Yes, last Summer Dev Days, the time spent on Remediation was = wasted > time but that does not mean we should ignore it and not try to = make > some real progress. As far as I am concerned we need to reboot the > remediation effort. We cannot keep being the set of specifications = / > tools that act as the little boy crying "Wolf" in the night. We = need > to be able to find and fix issues if we are going to really make a > difference in organizational security postures. But today we think > it is too hard so we don't try ? I think we need a couple hours to > discuss the reboot of the effort even if that means minimizing = work > already done. > > A focused discussion on enterprise reporting is also critically > needed. For the vendors here, we have all gone through the > Cyberscope goat rope, delivering limited capabilities to specific > data call requirements of the Federal Agencies. The initial effort > was a mess, did little more than prove it was possible and cause = the > vendor community a great deal of thrashing to put a kludgey > 'solution' in place. Reality is all our customers need roll up > reporting and an infrastructure that supports it. A data call = should > not be special to anyone other than the agencies responding. The > tools should be able to select the types of data needed and = deliver > that on a scheduled basis automatically. Enterprise Reporting > pertains to commercial as well as Federal customers. We need to > focus some time on what that would look like using the ARF and ASR > as the foundational pieces. But there are missing pieces.. We need > this discussed. > > I would hope we can make this summer's SCAP Dev Days useful in > advancing the security automation efforts by addressing some of = the > more critical issues our customers are facing now or will be = facing > in the very short term. Status presentations are not interesting = to > those active in the efforts. Let's try to do those before we get = to > Bedford so we can real make some progress while we are all in the > same room. This is always a big event for the 'consensus of the > willing' that assemble and driven to see security automation make = a > difference. Let's see if we can have an event that, when we all = walk > out the last day, we all feel that every minute was well spent and > moves us forward. > > Thanks. > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Steve > > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > > > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > " > > > *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Frank; > > We hope to have the registration site up next week. The event > will be during the week of July 9 - starting Monday at 10:00 = AM > and ending on Friday at 12:00. > > Meanwhile, we are working on the agenda and are currently > considering this list of topics: > > CCE > > CPE/SWID > > CEE > > XCCDF > > OVAL > > ASR > > Enterprise OCIL > > CybOX/MAEC > > Federated Content Repository Spec > > Endpoint Reporting for Continuous Monitoring and Compliance = (ERCC) > > MILE > > TAXII > > IF-M for SCAP > > IF-MAP > > SCAP Releases > > SCAP and IETF > > NETCONF and SCAP > > Steve > > *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU] > *Sent:* Tuesday, May 01, 2012 9:32 AM > *To:* oval-developer-list OVAL Developer List/Closed Public > Discussion > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Steve.... > > Has there been any additional information regarding this = event? > > Thanks, > Frank Acker > > ------------------------------------------------------------------------ > > *From:*Boczenowski, Steve [sboczeno@MITRE.ORG > ] > *Sent:* Tuesday, March 20, 2012 16:38 > *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > > *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Save the Date: week of July 9, 2012 > > This year's MITRE-hosted Security Automation Developer Days > event will be held during the week of July 9, 2012 at MITRE's > facility in Bedford, MA. > > Details to follow. > > Regards, > > Steve > > ______________________________________________ > > /Stephen P. Boczenowski/ > > The MITRECorporation > > Office: (781) 271-7682 > > Cell: (978) 302-3849 > > sboczeno@mitre.org > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG = with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG = with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG = with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > > > _______________________________________________ > 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 andrew.bove@secureacuity.net Sat May 12 09:27: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 9A1B021F8445 for ; Sat, 12 May 2012 09:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76cUXCWoCzaL for ; Sat, 12 May 2012 09:27:28 -0700 (PDT) Received: from bay0-omc4-s18.bay0.hotmail.com (bay0-omc4-s18.bay0.hotmail.com [65.54.190.220]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64B21F8443 for ; Sat, 12 May 2012 09:27:28 -0700 (PDT) Received: from BAY164-DS2 ([65.54.190.199]) by bay0-omc4-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 May 2012 09:27:28 -0700 X-Originating-IP: [96.231.98.66] X-Originating-Email: [andrew.bove@secureacuity.net] Message-ID: From: "Andrew Bove [SA]" To: , , , , References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: Date: Sat, 12 May 2012 12:27:28 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CD303A.98645100" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHNL5Qyr+svejPQnUq3EX7pBTJtuJbGV77Q Content-Language: en-us X-OriginalArrivalTime: 12 May 2012 16:27:28.0002 (UTC) FILETIME=[1F122620:01CD305C] Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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: Sat, 12 May 2012 16:27:40 -0000 ------=_NextPart_000_0031_01CD303A.98645100 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I would like to participate. _Andy =20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Friday, May 11, 2012 12:36 PM To: m.kinne@radium.ncsc.mil; david.waltermire@nist.gov; = SCAP-DEV@nist.gov; sacm@ietf.org Subject: [sacm] Request for participants - Content Repository = Specification Development =20 Mike I love it when you tee something up like that.. ;-) Thank you. ;) =20 Mike wrote:=20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful = for everyone. We need to talk more. =20 If you are talking about a holistic, complete federated approach to a content repository, I some what agree. If you are talking about an organizational repository, I totally disagree. But you knew I would. ;) =20 Here is how I see the problem. There is an immediate need for SCAP and other related content to be served up inside an organization. Today we = have situation where the standards allow us to provide sites the capability = to have a single SCAP implemented policy they call official for their environment. Yes this is a rather simplistic since there are things such = as targeting specific platforms, specific operational use needs, but for = now lets agree SCAP is a massive improvement over the proprietary situations = of the past. While we have created this standard content so that sites can implement their local site security once and then assure they are = measuring all appropriately targeted devices the same way, we have failed to = support the operational needs of the sites. We have a situation where no two vendors distribute content the same way. This causes massive problems = for the administration staff when they need to incorporate a new SCAP = enabled product into their architecture. They need to discover how the new = product supports distributing SCAP content to it's various components. If they = have one product then they do this one and they are done. If they have = multiple products they will have to figure out how to minimize the impact by incorporating the update process for the new product into the existing = SCAP security content processes. Now when the inevitable happens and the site staff needs to make a change to their security policy, they have to make = the modifications to the benchmark or checks or both and then distribute = those updates across their network. For each SCAP enabled product they have = in place, they have doubled, tripled or more the work needed to make those updates available.=20 =20 There is another content repository problem and that is the Federated Content Distribution. If you think global DNS you have a general frame = of reference. The guidance authors need to be able to publish content in = an authoritative manner so their content is updated in a timely fashion. = This is a much harder problem to solve if there is no local organizational infrastructure to support it. ;) =20 So here is what I am thinking. We should consider addressing these as = two separate but integrated efforts. I believe the Organizational Content Repository is the more critical piece that is actually easier to = address. The Federated Content Distribution should be a subsequent effort = integrating / augmenting the Organizational repository specification.=20 =20 Mike, to your point that we need someone to build one first. That has happened already. I have one as do other vendors but what we don't have = is the access specification. Ours are focused on our specific product = needs. Additionally there is a company that has developed a commercial SCAP = content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I = was very impressed. Again, to your point, it has been done. What is needed = to address the initial operational problem is to develop a specification = that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site. =20 =20 TO THAT END.. =20 I am requesting participation from those in the community that see the = need and want to put in the work to make this specification happen. I have talked to a couple of you but I do not want to assume your = participation. If you are interested please contact me so we can get this started.=20 =20 Thanks! =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Michael A To: David Waltermire , SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Dave, I have no problem with webinars, I do want to keep developer days = actionable and use it to make decisions, and vote and accomplish things good or = bad. I do not want this to be an informational briefing conference. Thanks for the links. =20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful = for everyone. We need to talk more. =20 -Mike =20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 Regarding content management, we are building the prototype content repository for use in a production environment. As an open source = project, it will be free for use by anyone interested. My thinking is that this project can bridge the gap until commercial solutions are available to augment it. This is a similar path that was followed with DNS (bind) = and HTTP (apache). When it is ready for use, I am hoping to use it to host USGCB content. You would be welcome to use it for your needs. =20 It is good that OCIL is moving forward. This is an important piece of supporting risk management and aspects of continuous monitoring. I = would also like to see some discussion on OCIL at Developer Days. With the proposals we will likely have a sense of what needs to be discussed and = what we can achieve consensus on outside the meeting. =20 Remediation is a topic near and dear to my heart. I too would like to = see it move forward. =20 We just published the draft ASR specification for public comment. This specification supports enterprise aggregate reporting which greatly = reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR. = It can be used in continuous monitoring applications to support aggregate = data reporting needs (e.g. FISMA reporting, CyberScope). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are = still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred. As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF. = These are good and necessary discussions to have now, but we have a good deal = of work to do before we are ready to open up XCCDF. My suggestion is to = work on these related areas and then work up change proposals for XCCDF as needed. By that time we should be ready to work on a new revision of = XCCDF. =20 I am also looking forward to the discussions at the conference. It has = been too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]=20 Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 It's good to read your thoughts, and a realistic actionable approach is indeed needed. Since all the activity hasn't been on the lists a brief = 1=AE2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. =20 We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification = is today. I've been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is = a tough problem and will require funding with a tail, I'm not sure a specification will solve that problem. =20 We (DoD) have been putting a lot of effort into OCIL over the last year trying to make it useful in an enterprise environment and will be = posting our ideas to the list before developer days it should have already = started, we need to get consensus and a vote on how the community wishes to = proceed. =20 Remediation is stalled but I'm making every effort to get it kick = started from our perspective. I hope to assist in getting the draft ERI finished this year. We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can = do some automatic configuration fixes, part of a self healing network = concept. It is just a start but the best we can do at this point. =20 Enterprise reporting is an interesting subject, since XML adds size to = and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject. =20 I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to = wait. I didn't think that a move to internationalization should impede efforts = to move forward with use cases. =20 I look forward to talking with you at the conference. =20 v/r =20 Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov =20 =20 =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 I like what you are saying here. We are also in support of this type of approach. We would like to see some community discussion around what = are the key areas/priorities that the community would like to see discussed = at Dev Days. Your topics below look like a good start. The SACM list might = be a better venue than the OVAL list for this discussion. For each area we should focus the discussion around developing objectives for each = session. The sessions can be time boxed based on what would be a reasonable = amount of time to accomplish each objective. For example if continuous monitoring = is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that. We can also keep a few sessions = "on deck" if all the objectives are reached and we complete all the = scheduled sessions early. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 All, =20 I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. =20 I see this appears to follow a path we have discussed in the past as the = way not to hold a Dev Days event. We have been trying to get away from = 'Death by Powerpoint' and back to the type of event we held years ago when we = were highly productive. In the past we had a topic to be discussed and a = time box to work within. That allowed us to have very active brainstorming sessions in a high bandwidth environment. =20 At past Summer events we have got into a pattern of lots of powerpoint, = lots of status of the efforts and very little discussion about things that = need active discussions. We need to keep moving forward and making progress = as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. We = have a limited amount of time and all who are attending are investing a great = deal of time and money to be there. We should not be spending a great deal = of time reeducating everyone when we could be focused on advancing needed efforts. =20 The type of approach to a Dev Days event was discussed at the last = Summer Dev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in advance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas that need real work by the community 4. Efforts to be discussed should be based on needs of the security automation space to move existing efforts to completion. For example: =20 Continuous monitoring is a major direction the efforts are becoming = involved with. There are going to be things we need to do as a security = automation community to be able to accomplish what is listed in the CAESARS FE. = There are interfaces that need to be worked and established. That is one area that is not listed below. CM will have a major impact on all of us in = the next couple years and it is being ignored. We can't keep trying to = solve what has already been solved. We need to address the needed interface development now. This is an effort that could take nearly a whole day by itself. =20 Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +.) without the = site staff having to go to each of the individual products and figuring out = how to inject that new or updated policy into that products delivery = mechanisms. That is limiting sites from wanting to buy multiple focused SCAP = products since they are such a pain to manage from a content perspective. It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having = multiple SCAP products presents. We need to have at least an entire 1/2 a day on = the development of a Content Repository specification. =20 OCIL is a positive and a negative at the same time. It has real value = that is being underutilized and under implemented because of the limitations = of how it addresses uses in an enterprise environment. People don't need security automation to do things on/for a single host. They need = security automation to focus on the enterprise issues that reduce their costs and improve their efficiencies. OCIL is failing in the enterprise and we = all understand that. We need to address developing a definitive solution = for incorporating OCIL into the enterprise and that means into the existing specifications. Scheduling and tracking are key to it's success. We = need to make that happen. This too needs a focused brainstorming time box to discuss options. =20 I am really disappointed that Remediation is not on the list below. = Yes, last Summer Dev Days, the time spent on Remediation was wasted time but = that does not mean we should ignore it and not try to make some real = progress. As far as I am concerned we need to reboot the remediation effort. We cannot keep being the set of specifications / tools that act as the = little boy crying "Wolf" in the night. We need to be able to find and fix = issues if we are going to really make a difference in organizational security postures. But today we think it is too hard so we don't try ? I think = we need a couple hours to discuss the reboot of the effort even if that = means minimizing work already done. =20 A focused discussion on enterprise reporting is also critically needed. = For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of = the Federal Agencies. The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of thrashing = to put a kludgey 'solution' in place. Reality is all our customers need = roll up reporting and an infrastructure that supports it. A data call should = not be special to anyone other than the agencies responding. The tools = should be able to select the types of data needed and deliver that on a scheduled basis automatically. Enterprise Reporting pertains to commercial as = well as Federal customers. We need to focus some time on what that would = look like using the ARF and ASR as the foundational pieces. But there are missing pieces.. We need this discussed. =20 I would hope we can make this summer's SCAP Dev Days useful in advancing = the security automation efforts by addressing some of the more critical = issues our customers are facing now or will be facing in the very short term. Status presentations are not interesting to those active in the efforts. Let's try to do those before we get to Bedford so we can real make some progress while we are all in the same room. This is always a big event = for the 'consensus of the willing' that assemble and driven to see security automation make a difference. Let's see if we can have an event that, = when we all walk out the last day, we all feel that every minute was well = spent and moves us forward. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Frank; =20 We hope to have the registration site up next week. The event will be during the week of July 9 - starting Monday at 10:00 AM and ending on = Friday at 12:00. =20 Meanwhile, we are working on the agenda and are currently considering = this list of topics: =20 CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker _____ =20 From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 =20 This year's MITRE-hosted Security Automation Developer Days event will = be held during the week of July 9, 2012 at MITRE's facility in Bedford, MA. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 ------=_NextPart_000_0031_01CD303A.98645100 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

I would like to = participate.

_Andy

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Kent_Landfield@McAfee.com
Sent: Friday, May 11, 2012 12:36 = PM
To: m.kinne@radium.ncsc.mil; david.waltermire@nist.gov; = SCAP-DEV@nist.gov; sacm@ietf.org
Subject: [sacm] Request for = participants - Content Repository Specification = Development

 

Mike I love it when you = tee something up like that…. ;-)  Thank you. = ;)

 

Mike = wrote: 

I still think that any = specification for a repository is wishful thinking until someone builds = one and learns the lessons it will just be another whitepaper spec. =  I believe the DoD needs to incorporate a metadata repository as = part of it and other customizations that may not be useful for = everyone.

We need to talk = more…

 

If you are talking about a = holistic, complete federated approach to a content repository, I some = what agree.  If you are talking about an organizational repository, = I totally disagree. But you knew I would. ;)

 

Here is how I see the = problem.  There is an immediate need for SCAP and other related = content to be served up inside an organization.  Today we have = situation where the standards allow us to provide sites the capability = to have a single SCAP implemented policy they call official for their = environment. Yes this is a rather simplistic since there are things such = as targeting specific platforms, specific operational use needs, but for = now lets agree SCAP is a massive improvement over the proprietary = situations of the past. While we have created this standard content so = that sites can implement their local site security once and then assure = they are measuring all appropriately targeted devices the same way, we = have failed to support the operational needs of the sites.  We have = a situation where no two vendors distribute content the same way. =  This causes massive problems for the administration staff when = they need to incorporate a new SCAP enabled product into their = architecture.  They need to discover how the new product supports = distributing SCAP content to it's various components.  If they have = one product then they do this one and they are done.  If they have = multiple products they will have to figure out how to minimize the = impact by incorporating the update process for the new product into the = existing SCAP security content processes. Now when the inevitable = happens and the site staff needs to make a change to their security = policy, they have to make the modifications to the benchmark or checks = or both and then distribute those updates across their network. =  For each SCAP enabled product they have in place, they have = doubled, tripled or more the work needed to make those updates = available. 

 

There is another content = repository problem and that is the Federated Content Distribution. =  If you think global DNS you have a general frame of reference. =  The guidance authors need to be able to publish content in an = authoritative manner so their content is updated in a timely fashion. =  This is a much harder problem to solve if there is no local = organizational infrastructure to support it. ;)

 

So here is what I am = thinking…  We should consider addressing these as two = separate but integrated efforts.  I believe the Organizational = Content Repository is the more critical piece that is actually easier to = address.  The Federated Content Distribution should be a subsequent = effort integrating / augmenting the Organizational repository = specification. 

 

Mike, to your point that = we need someone to build one first… That has happened already. =  I have one as do other vendors but what we don’t have is the = access specification.  Ours are focused on our specific product = needs.  Additionally there is a company that has developed a = commercial SCAP content repository that will be announced later this = month. I won't steal their thunder but I was recently given a sneak peek = at it and I must admit I was very impressed.  Again, to your point, = it has been done. What is needed to address the initial operational = problem is to develop a specification that provides a consistent means = for all SCAP products to retrieve the appropriate content as configured = and managed but the site.  

 

TO THAT = END….

 

I am requesting = participation from those in the community that see the need and want to = put in the work to make this specification happen.  I have talked = to a couple of you but I do not want to assume your participation. =  If you are interested please contact me so we can get this = started. 

 

Thanks!

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

=

 

From: = <Kinney>, Michael A <m.kinne@radium.ncsc.mil>To: David Waltermire <david.waltermire@nist.gov&g= t;, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: = Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA

 

Dave,

I have no problem with webinars, I do want to = keep developer days actionable and use it to make decisions, and vote = and accomplish things good or bad.  I do not want this to be an = informational briefing conference.

Thanks for the links.

 

I still think that any specification for a = repository is wishful thinking until someone builds one and learns the = lessons it will just be another whitepaper spec.  I believe the DoD = needs to incorporate a metadata repository as part of it and other = customizations that may not be useful for everyone.

We need to talk more…

 

-Mike 

 

= From:= Waltermire, David A. [mailto:david.waltermire@nist.go= v]
Sent: Tuesday, May 08, 2012 10:44 AM
To: = Kinney, Michael A; SCAP-DEV; sacm@ietf.org
Subject: RE: = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-place of the 30 = minute briefs?

 

Regarding content management, we are building = the prototype content repository for use in a production = environment.  As an open source project, it will be free for use by = anyone interested.  My thinking is that this project can bridge the = gap until commercial solutions are available to augment it.  This = is a similar path that was followed with DNS (bind) and HTTP = (apache).  When it is ready for use, I am hoping to use it to host = USGCB content.  You would be welcome to use it for your = needs.

 

It is good that OCIL is moving forward.  = This is an important piece of supporting risk management and aspects of = continuous monitoring.  I would also like to see some discussion on = OCIL at Developer Days.  With the proposals we will likely have a = sense of what needs to be discussed and what we can achieve consensus on = outside the meeting.

 

Remediation is a topic near and dear to my = heart.  I too would like to see it move forward.

 

We just published the draft ASR specification = for public comment.  This specification supports enterprise = aggregate reporting which greatly reduces the data volumes needed verses = detailed host-based reports. This specification has been designed as a = more robust replacement for LASR.  It can be used in continuous = monitoring applications to support aggregate data reporting needs (e.g. = FISMA reporting,  CyberScope).

 

Here are the links:

 

http://csrc.ni= st.gov/publications/PubsDrafts.html

= http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

 

The primary reason we have suggested waiting on = XCCDF is not the internationalization issue. Many vendors have commented = that they are still working on implementing the XCCDF 1.2.1 = specification. We will be in a better place in a few months once more = development around XCCDF has occurred.  As we consider changes to = the SCAP stack to address OCIL and other issues, we will identify areas = that need improvement in XCCDF.  These are good and necessary = discussions to have now, but we have a good deal of work to do before we = are ready to open up XCCDF.  My suggestion is to work on these = related areas and then work up change proposals for XCCDF as = needed.  By that time we should be ready to work on a new revision = of XCCDF.

 

I am also looking forward to the discussions at = the conference.  It has been too long.

 

Sincerely,

Dave

 

 

Kent,

 

It’s good to read your thoughts, and a = realistic actionable approach is indeed needed.  Since all the = activity hasn’t been on the lists a brief 1=AE2 hour recap may be = in order to bring everyone up to speed since there has been a lot of = activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

 

We could write a content repository = specification, but without someone willing to stand one up it will be as = valuable as the CCSS specification is today.  I’ve been = trying for two years to get my management to get a coordinated effort = together for the DoD to stand up a repository, it is a tough problem and = will require funding with a tail, I’m not sure a specification = will solve that problem.

 

We (DoD) have been putting a lot of effort into = OCIL over the last year trying to make it useful in an enterprise = environment and will be posting our ideas to the list before developer = days it should have already started, we need to get consensus and a vote = on how the community wishes to proceed.

 

Remediation is stalled but I’m making = every effort to get it kick started from our perspective. I hope to = assist in getting the draft ERI finished this year.  We are writing = some new STIG content and intend to used the draft CRE specification to = insert CRE into the content so we (DoD) can do some automatic = configuration fixes, part of a self healing network concept. It is just = a start but the best we can do at this point.

 

Enterprise reporting is an interesting subject, = since XML adds size to and content to roll up reporting, in any = enterprise of size the problem gets greater, I look forward to your = thoughts on that subject.

 

I am concerned that the internationalization = efforts are detracting from efforts to meet use cases, we have some = things we would like changed in XCCDF to support our OCIl use case and I = have been told that I need to wait. I didn’t think that a move to = internationalization should impede efforts to move forward with use = cases.

 

I look forward to talking with you at the = conference.

 

v/r

 

Mike Kinney

Project Director

Computer Network Defense Research and Technology (CND R&T) = Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: = 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A.
Sent: Monday, May = 07, 2012 7:09 PM
To: Multiple recipients of = list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation = Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

I like what you are saying here.  We are = also in support of this type of approach.  We would like to see = some community discussion around what are the key areas/priorities that = the community would like to see discussed at Dev Days.  Your topics = below look like a good start. The SACM list might be a better venue than = the OVAL list for this discussion.  For each area we should focus = the discussion around developing objectives for each session.  The = sessions can be time boxed based on what would be a reasonable amount of = time to accomplish each objective.  For example if continuous = monitoring is a priority and collectively it takes 3 days to work = through all the objectives, I see no problem with that.  We can = also keep a few sessions “on deck” if all the objectives are = reached and we complete all the scheduled sessions early.

 

Thoughts?

 

Sincerely,

 

David = Waltermire

SCAP = Architect

National Institute of = Standards and Technology

(301) 975-3390

david.waltermire@nist.gov

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.comSent: Monday, May 07, 2012 4:25 PM
To: = SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

All,

 

I would like to discuss = the format for the SCAP Developer Days that seems to be listed = below.

 

I see this appears to = follow a path we have discussed in the past as the way not to hold a Dev = Days event.  We have been trying to get away from 'Death by = Powerpoint' and back to the type of event we held years ago when we were = highly productive.  In the past we had a topic to be discussed and = a time box to work within.  That allowed us to have very active = brainstorming sessions in a high bandwidth = environment.

 

At past Summer events we = have got into a pattern of lots of powerpoint, lots of status of the = efforts and very little discussion about things that need active = discussions.  We need to keep moving forward and making progress as = an effort. We can get status from various places such as the lists, a = presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. =  We have a limited amount of time and all who are attending are = investing a great deal of time and money to be there.  We should = not  be spending a great deal of time reeducating everyone when we = could be focused on advancing needed = efforts.

 

The type of approach to a = Dev Days event was discussed at the last Summer Dev Days.  I have = seen the following work quite well in other = efforts.

  1. Presentations are sent out to the attendees and = the lists a week in advance.
  2. Status for any effort is limited to 30 = minutes
  3. Focused brainstorming time should be established = for certain areas that need real work by the = community
  4. Efforts to be discussed should be based on needs = of the security automation space to move existing efforts to = completion.

For example:

 

Continuous monitoring is a = major direction the efforts are becoming involved with. There are going = to be things we need to do as a security automation community to be able = to accomplish what is listed in the CAESARS FE.  There are = interfaces that need to be worked and established.  That is one = area that is not listed below.  CM will have a major impact on all = of us in the next couple years and it is being ignored.  We can't = keep trying to solve what has already been solved.  We need to = address the needed interface development now. This is an effort that = could take nearly a whole day by = itself.

 

Operationally we have a = real need to be able to deliver SCAP content internally within an = organization. Today the SCAP vendors cannot share a single local site = security policy (XCCDF + OVAL + CPE +…) without the site staff = having to go to each of the individual products and figuring out how to = inject that new or updated policy into that products delivery = mechanisms.  That is limiting sites from wanting to buy multiple = focused SCAP products since they are such a pain to manage from a = content perspective.  It is easier to buy from one vendor that has = a single means for distributing content than it is to deal with the = management issues that having multiple SCAP products presents.  We = need to have at least an entire 1/2 a day on the development of a = Content Repository specification.

 

OCIL is a positive and a = negative at the same time. It has real value that is being underutilized = and under implemented because of the limitations of how it addresses = uses in an enterprise environment.  People don't need security = automation to do things on/for a single host.  They need security = automation to focus on the enterprise issues that reduce their costs and = improve their efficiencies.  OCIL is failing in the enterprise and = we all understand that.  We need to address developing a definitive = solution for incorporating OCIL into the enterprise and that means into = the existing specifications. Scheduling and tracking are key to it's = success.  We need to make that happen.  This too needs a = focused brainstorming time box to discuss = options.

 

I am really disappointed = that Remediation is not on the list below…  Yes, last Summer = Dev Days, the time spent on Remediation was wasted time but that does = not mean we should ignore it and not try to make some real progress. =  As far as I am concerned we need to reboot the remediation effort. =  We cannot keep being the set of specifications / tools that act as = the little boy crying "Wolf" in the night.  We need to be = able to find and fix issues if we are going to really make a difference = in organizational security postures.  But today we think it is too = hard so we don't try ?  I think we need a couple hours to discuss = the reboot of the effort even if that means minimizing work already = done.

 

A focused discussion on = enterprise reporting is also critically needed.  For the vendors = here, we have all gone through the Cyberscope goat rope, delivering = limited capabilities to specific data call requirements of the Federal = Agencies.  The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of = thrashing to put a kludgey 'solution' in place.  Reality is all our = customers need roll up reporting and an infrastructure that supports it. =  A data call should not be special to anyone other than the = agencies responding. The tools should be able to select the types of = data needed and deliver that on a scheduled basis automatically.   =  Enterprise Reporting pertains to commercial as well as Federal = customers.  We need to focus some time on what that would look like = using the ARF and ASR as the foundational pieces.  But there are = missing pieces….  We need this = discussed.

 

I would hope we can make = this summer's SCAP Dev Days useful in advancing the security automation = efforts by addressing some of the more critical issues our customers are = facing now or will be facing in the very short term.  Status = presentations are not interesting to those active in the efforts. =  Let's try to do those before we get to Bedford so we can real make = some progress while we are all in the same room.  This is always a = big event for the 'consensus of the willing' that assemble and driven to = see security automation make a difference.  Let's see if we can = have an event that, when we all walk out the last day, we all feel that = every minute was well spent and moves us = forward.

 

Thanks.

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

 

From: = <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply= -To: "OVAL Developer List (Closed Public Discussion)" = <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Frank;

 

We hope to have the registration site up next = week.  The event will be during the week of July 9 – starting = Monday at 10:00 AM and ending on Friday at 12:00.

 

Meanwhile, we are working on the agenda and are = currently considering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise = OCIL

CybOX/MAEC

Federated = Content Repository Spec

Endpoint = Reporting for Continuous Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for = SCAP

IF-MAP

SCAP = Releases

SCAP and IETF

NETCONF and = SCAP

 

Steve

 

= From:= Frank Lindsay Acker [mailto:afrank@NOVA.EDU] =
Sent: Tuesday, May 01, 2012 9:32 AM
To: = oval-developer-list OVAL Developer List/Closed Public = Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

= Steve....

Has there been any additional information regarding = this event?

Thanks,
Frank Acker

= From:= Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

Save the Date: week of July 9, = 2012

 

This year’s = MITRE-hosted Security Automation Developer Days event will be held = during the week of July 9, 2012 at MITRE’s facility in Bedford, = MA.

 

Details to = follow.

 

Regards,

    Steve

 

= ______________________________________________

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

------=_NextPart_000_0031_01CD303A.98645100-- From david.oliva@verizon.net Sat May 12 12:46: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 03BFC21F85E1 for ; Sat, 12 May 2012 12:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, MIME_HTML_ONLY=1.457, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSaG3LnQx2BW for ; Sat, 12 May 2012 12:46:08 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2F9A21F859F for ; Sat, 12 May 2012 12:46:07 -0700 (PDT) Received: from vznit170080pub.verizon.net ([unknown] [192.168.1.3]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M3X00GANDKS8S51@vms173017.mailsrvcs.net> for sacm@ietf.org; Sat, 12 May 2012 14:46:05 -0500 (CDT) Received: from 96.255.129.191 ([96.255.129.191]) by vznit170080 (Verizon Webmail) with HTTP; Sat, 12 May 2012 14:46:04 -0500 (CDT) Date: Sat, 12 May 2012 14:46:04 -0500 (CDT) From: david.oliva@verizon.net To: Kent_Landfield@McAfee.com, m.kinne@radium.ncsc.mil, david.waltermire@nist.gov, SCAP-DEV@nist.gov, sacm@ietf.org Message-id: <22541297.132421.1336851964583.JavaMail.root@vznit170080> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [96.255.129.191] Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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: Sat, 12 May 2012 19:46:10 -0000
To all:
 
I am interested in l= ocating content for SCAP 1.2.
In particular, content for the spec= ifications added after 1.0.
Are you all talking about SCAP 1.2 Co= ntent?
 
David Oliva
 
&n= bsp;
On 0= 5/11/12, Kent_Landfield@McAfee.com wrote:
 
=
Mike I love it when you tee something up like that= =E2=80=A6. ;-)  Thank you. ;)

<= P style=3D"MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri, sans-serif; COLOR: rg= b(0,0,0); FONT-SIZE: 11pt" class=3DMsoNormal>Mike wrote: 

I still think that any specifi= cation for a repository is wishful thinking until someone builds one and le= arns the lessons it will just be another whitepaper spec.  I believe t= he DoD needs to incorporate a metadata repository as part of it and other c= ustomizations that may not be useful for everyone.

We need to talk more=E2=80=A6


=

If you are talking about a holistic, complet= e federated approach to a content repository, I some what agree.  If y= ou are talking about an organizational repository, I totally disagree. But = you knew I would. ;)


Here is how I see the problem.  There is an i= mmediate need for SCAP and other related content to be served up inside an = organization.  Today we have situation where the standards allow us to= provide sites the capability to have a single SCAP implemented policy they= call official for their environment. Yes this is a rather simplistic since= there are things such as targeting specific platforms, specific operationa= l use needs, but for now lets agree SCAP is a massive improvement over the = proprietary situations of the past. While we have created this standard con= tent so that sites can implement their local site security once and then as= sure they are measuring all appropriately targeted devices the same way, we= have failed to support the operational needs of the sites.  We have a= situation where no two vendors distribute content the same way.  This= causes massive problems for the administration staff when they need to inc= orporate a new SCAP enabled product into their architecture.  They nee= d to discover how the new product supports distributing SCAP content to it'= s various components.  If they have one product then they do this one = and they are done.  If they have multiple products they will have to f= igure out how to minimize the impact by incorporating the update process fo= r the new product into the existing SCAP security content processes. Now wh= en the inevitable happens and the site staff needs to make a change to thei= r security policy, they have to make the modifications to the benchmark or = checks or both and then distribute those updates across their network. &nbs= p;For each SCAP enabled product they have in place, they have doubled, trip= led or more the work needed to make those updates available. 


The= re is another content repository problem and that is the Federated Content = Distribution.  If you think global DNS you have a general frame of ref= erence.  The guidance authors need to be able to publish content in an= authoritative manner so their content is updated in a timely fashion. &nbs= p;This is a much harder problem to solve if there is no local organizationa= l infrastructure to support it. ;)

So here is what I am thinking=E2=80= =A6  We should consider addressing these as two separate but integrate= d efforts.  I believe the Organizational Content Repository is the mor= e critical piece that is actually easier to address.  The Federated Co= ntent Distribution should be a subsequent effort integrating / augmenting t= he Organizational repository specification. 


Mike, to your point t= hat we need someone to build one first=E2=80=A6 That has happened already. =  I have one as do other vendors but what we don=E2=80=99t have is the = access specification.  Ours are focused on our specific product needs.=  Additionally there is a company that has developed a commercial SCAP= content repository that will be announced later this month. I won't steal = their thunder but I was recently given a sneak peek at it and I must admit = I was very impressed.  Again, to your point, it has been done. What is= needed to address the initial operational problem is to develop a specific= ation that provides a consistent means for all SCAP products to retrieve th= e appropriate content as configured and managed but the site.  =


TO= THAT END=E2=80=A6.


I am requesting participation from those in the com= munity that see the need and want to put in the work to make this specifica= tion happen.  I have talked to a couple of you but I do not want to as= sume your participation.  If you are interested please contact me so w= e can get this started. 


Thanks!


Kent Landfield
Director Content Strategy, = Architecture and Standards
McAfee= | An Intel Company
= 5000 Headquarters Dr.
Plano, = Texas 75024
<= /SPAN>
Direct: +1.972.963.7096 =
Mobile: +1.817.637.8026
Web: ww= w.mcafee.com

From: <Ki= nney>, Michael A <m.kinne@radium.ncsc.mil>
To: David Waltermire <david.waltermi= re@nist.gov>, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" &l= t;sacm= @ietf.org>
Subject: Re: = [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 201= 2 at MITRE in Bedford, MA

Dave,

I have no problem with webinars, I do want to keep deve= loper days actionable and use it to make decisions, and vote and accomplish= things good or bad.  I do not want this to be an informational briefi= ng conference.

 

I still think that any specification for a repository is wishful think= ing until someone builds one and learns the lessons it will just be another= whitepaper spec.  I believe the DoD needs to incorporate a metadata r= epository as part of it and other customizations that may not be useful for= everyone.

We need to tal= k more=E2=80=A6

 

-Mi= ke 

&nb= sp;

From: Waltermire, David A. [mailto:david.waltermire@nist= .gov]
Sent: Tuesday, May 08, 2012 10:44 AM
To: Kin= ney, Michael A; SCAP-DEV; sacm@ietf.org
Subject: RE: [OVAL-DEVELOPE= R-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford= , MA

 

Mike,

 

What about having webinars in-place of the 30 minute = briefs?

 = ;

Regarding c= ontent management, we are building the prototype content repository for use= in a production environment.  As an open source project, it will be f= ree for use by anyone interested.  My thinking is that this project ca= n bridge the gap until commercial solutions are available to augment it.&nb= sp; This is a similar path that was followed with DNS (bind) and HTTP (apac= he).  When it is ready for use, I am hoping to use it to host USGCB co= ntent.  You would be welcome to use it for your needs.

 

It is good that OCIL is moving for= ward.  This is an important piece of supporting risk management and as= pects of continuous monitoring.  I would also like to see some discuss= ion on OCIL at Developer Days.  With the proposals we will likely have= a sense of what needs to be discussed and what we can achieve consensus on= outside the meeting.

 

Remediation is a topic near and dear to my heart.  I too would like= to see it move forward.

 

We just published the draft ASR specification for public comment.&nbs= p; This specification supports enterprise aggregate reporting which greatly= reduces the data volumes needed verses detailed host-based reports. This s= pecification has been designed as a more robust replacement for LASR. = It can be used in continuous monitoring applications to support aggregate = data reporting needs (e.g. FISMA reporting,  CyberScope).

 

Here are the links:

<= P class=3DMsoNormal> 

http://csrc.nist.gov/public= ations/PubsDrafts.html

http://csrc.nist.gov/publications/PubsNISTIR= s.html#NIST-IR-7848

 

The primary reason we have suggested waiting on XCCDF is not the inter= nationalization issue. Many vendors have commented that they are still work= ing on implementing the XCCDF 1.2.1 specification. We will be in a better p= lace in a few months once more development around XCCDF has occurred. = As we consider changes to the SCAP stack to address OCIL and other issues,= we will identify areas that need improvement in XCCDF.  These are goo= d and necessary discussions to have now, but we have a good deal of work to= do before we are ready to open up XCCDF.  My suggestion is to work on= these related areas and then work up change proposals for XCCDF as needed.=   By that time we should be ready to work on a new revision of XCCDF.<= /SPAN>

 =

I am also looking f= orward to the discussions at the conference.  It has been too long.

 

Sincerely,

Dave

 

From:= Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]
Sent: Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: Walte= rmire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] Security Autom= ation Developer Days: Summer 2012 at MITRE in Bedford, MA

<= /DIV>

 

Kent,

 

= It=E2=80=99s good to read your thoughts, and a realistic actionable approac= h is indeed needed.  Since all the activity hasn=E2=80=99t been on the= lists a brief 1=C5=BD2 hour recap may be in order to bring everyone up to = speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX = CEE and others.

 

We = could write a content repository specification, but without someone willing= to stand one up it will be as valuable as the CCSS specification is today.=  I=E2=80=99ve been trying for two years to get my management to get a= coordinated effort together for the DoD to stand up a repository, it is a = tough problem and will require funding with a tail, I=E2=80=99m not sure a = specification will solve that problem.

 

We (DoD) have been putting a lot of effort into OCIL ov= er the last year trying to make it useful in an enterprise environment and = will be posting our ideas to the list before developer days it should have = already started, we need to get consensus and a vote on how the community w= ishes to proceed.

 

R= emediation is stalled but I=E2=80=99m making every effort to get it kick st= arted from our perspective. I hope to assist in getting the draft ERI finis= hed this year.  We are writing some new STIG content and intend to use= d the draft CRE specification to insert CRE into the content so we (DoD) ca= n do some automatic configuration fixes, part of a self healing network con= cept. It is just a start but the best we can do at this point.

 

Enterprise reporting is an inte= resting subject, since XML adds size to and content to roll up reporting, i= n any enterprise of size the problem gets greater, I look forward to your t= houghts on that subject.

 

I am concerned that the internationalization efforts are detracting f= rom efforts to meet use cases, we have some things we would like changed in= XCCDF to support our OCIl use case and I have been told that I need to wai= t. I didn=E2=80=99t think that a move to internationalization should impede= efforts to move forward with use cases.

 

I look forward to talking with you at the conference.=

 

v/r

 

Mike Kinney

Project Director

Computer Network Defense Research and Technology (= CND R&T) Office

9800 Savage = Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: 968-8886
Fax 410-85= 4-4681

makinn2@nsa.gov

 

 

 

From:scap-dev@nist.gov [mailto:scap-dev@n= ist.gov] On Behalf Of Waltermire, David A.
Sent: Monda= y, May 07, 2012 7:09 PM
To: Multiple recipients of list
Sub= ject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA

 

Kent,=

 

I like what you are sayin= g here.  We are also in support of this type of approach.  We wou= ld like to see some community discussion around what are the key areas/prio= rities that the community would like to see discussed at Dev Days.  Yo= ur topics below look like a good start. The SACM list might be a better ven= ue than the OVAL list for this discussion.  For each area we should fo= cus the discussion around developing objectives for each session.  The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective.  For example if continuous monitorin= g is a priority and collectively it takes 3 days to work through all the ob= jectives, I see no problem with that.  We can also keep a few sessions= =E2=80=9Con deck=E2=80=9D if all the objectives are reached and we complet= e all the scheduled sessions early.

 

Thoughts?

 

Sincerely,

 

David Waltermire

=

SCAP Architect

National Institute of= Standards and Technology

(301) 975-3390

david.walt= ermire@nist.gov

=  

From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]<= /A> On Behalf Of Kent_Landfield@mcafee.com
Sent:= Monday, May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re:= [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at M= ITRE in Bedford, MA

 

All,

 =

I w= ould like to discuss the format for the SCAP Developer Days that seems to b= e listed below.

 

I see this appears to follow a path we have discussed in the= past as the way not to hold a Dev Days event.  We have been trying to= get away from 'Death by Powerpoint' and back to the type of event we held = years ago when we were highly productive.  In the past we had a topic = to be discussed and a time box to work within.  That allowed us to hav= e very active brainstorming sessions in a high bandwidth environment.

 

At pas= t Summer events we have got into a pattern of lots of powerpoint, lots of s= tatus of the efforts and very little discussion about things that need acti= ve discussions.  We need to keep moving forward and making progress as= an effort. We can get status from various places such as the lists, a pres= entation being sent out in advance, a webinar if it is felt there will be q= uestions and answers from those that are new to the efforts.  We have = a limited amount of time and all who are attending are investing a great de= al of time and money to be there.  We should not  be spending a g= reat deal of time reeducating everyone when we could be focused on advancin= g needed efforts.

 

The type of approach to a Dev Days event was discussed at= the last Summer Dev Days.  I have seen the following work quite well = in other efforts.

  1. Presentations are sent out to the attendees and the = lists a week in advance.
  2. Status for any effort is limited to 30 minutes
  3. Focused brainstorming time should be establ= ished for certain areas that need real work by the community
  4. Efforts to be discussed should be= based on needs of the security automation space to move existing efforts t= o completion.

For example:

 

Continuous monitoring is a major direction the efforts are b= ecoming involved with. There are going to be things we need to do as a secu= rity automation community to be able to accomplish what is listed in the CA= ESARS FE.  There are interfaces that need to be worked and established= .  That is one area that is not listed below.  CM will have a maj= or impact on all of us in the next couple years and it is being ignored. &n= bsp;We can't keep trying to solve what has already been solved.  We ne= ed to address the needed interface development now. This is an effort that = could take nearly a whole day by itself.

 

Operationally we have a real need= to be able to deliver SCAP content internally within an organization. Toda= y the SCAP vendors cannot share a single local site security policy (XCCDF = + OVAL + CPE +=E2=80=A6) without the site staff having to go to each of the= individual products and figuring out how to inject that new or updated pol= icy into that products delivery mechanisms.  That is limiting sites fr= om wanting to buy multiple focused SCAP products since they are such a pain= to manage from a content perspective.  It is easier to buy from one v= endor that has a single means for distributing content than it is to deal w= ith the management issues that having multiple SCAP products presents. &nbs= p;We need to have at least an entire 1/2 a day on the development of a Cont= ent Repository specification.

 

= OCIL is a positive and a negative at the same = time. It has real value that is being underutilized and under implemented b= ecause of the limitations of how it addresses uses in an enterprise environ= ment.  People don't need security automation to do things on/for a sin= gle host.  They need security automation to focus on the enterprise is= sues that reduce their costs and improve their efficiencies.  OCIL is = failing in the enterprise and we all understand that.  We need to addr= ess developing a definitive solution for incorporating OCIL into the enterp= rise and that means into the existing specifications. Scheduling and tracki= ng are key to it's success.  We need to make that happen.  This t= oo needs a focused brainstorming time box to discuss options.

 

=

I am really di= sappointed that Remediation is not on the list below=E2=80=A6  Yes, la= st Summer Dev Days, the time spent on Remediation was wasted time but that = does not mean we should ignore it and not try to make some real progress. &= nbsp;As far as I am concerned we need to reboot the remediation effort. &nb= sp;We cannot keep being the set of specifications / tools that act as the l= ittle boy crying "Wolf" in the night.  We need to be able to find and = fix issues if we are going to really make a difference in organizational se= curity postures.  But today we think it is too hard so we don't try ? =  I think we need a couple hours to discuss the reboot of the effort ev= en if that means minimizing work already done.

 

A focused discussion on enter= prise reporting is also critically needed.  For the vendors here, we h= ave all gone through the Cyberscope goat rope, delivering limited capabilit= ies to specific data call requirements of the Federal Agencies.  The i= nitial effort was a mess, did little more than prove it was possible and ca= use the vendor community a great deal of thrashing to put a kludgey 'soluti= on' in place.  Reality is all our customers need roll up reporting and= an infrastructure that supports it.  A data call should not be specia= l to anyone other than the agencies responding. The tools should be able to= select the types of data needed and deliver that on a scheduled basis auto= matically.    Enterprise Reporting pertains to commercial as well= as Federal customers.  We need to focus some time on what that would = look like using the ARF and ASR as the foundational pieces.  But there= are missing pieces=E2=80=A6.  We need this discussed.

 

I would hope we = can make this summer's SCAP Dev Days useful in advancing the security autom= ation efforts by addressing some of the more critical issues our customers = are facing now or will be facing in the very short term.  Status prese= ntations are not interesting to those active in the efforts.  Let's tr= y to do those before we get to Bedford so we can real make some progress wh= ile we are all in the same room.  This is always a big event for the '= consensus of the willing' that assemble and driven to see security automati= on make a difference.  Let's see if we can have an event that, when we= all walk out the last day, we all feel that every minute was well spent an= d moves us forward.

 

Thanks.

 

Kent Landfield
Director Content Strategy, Architecture and Stand= ards

M= cAfee | An Intel Company
= 5000 Headquarters Dr.
Plano, Texas= 75024

Direct: +1.972.963.7096=  
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

Frank;

 

We hope to have the registration site up next week.  The event will b= e during the week of July 9 =E2=80=93 starting Monday at 10:00 AM and endin= g on Friday at 12:00.

 

= Meanwhile, we are working on the agenda and are currently considering this = list of topics:

 

CCE

CPE/SWID

CEE=

XCCDF

OVAL

ASR

Enterpri= se OCIL

CybOX/MAEC

Federated Content Repositor= y Spec

Endpoint Reporti= ng for Continuous Monitoring and Compliance (ERCC)

MILE=

TAXII

IF-M fo= r SCAP

IF-MAP

SCAP Releases

SCAP and IETF

NETCONF and SCAP

 

Steve

 

From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]
Sent:= Tuesday, May 01, 2012 9:32 AM
To: oval-developer-list OVAL Devel= oper List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-L= IST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, M= A

 

Steve....<= BR>
Has there been any additional information regarding this event?
<= BR>Thanks,
Frank Acker

From: Boczenowski, Steve [sboczeno@MITRE.= ORG]
Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Subject: [OVAL-= DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in= Bedford, MA

=

Save the Date: week of July 9, 2012

 

= This year=E2=80=99s MITRE-hosted Security Automation Developer Days event w= ill be held during the week of July 9, 2012 at MITRE=E2=80=99s facility in = Bedford, MA.

 

Details to follow.

 

Regards,

    Steve<= /SPAN>

 

<= SPAN style=3D"FONT-FAMILY: Arial, sans-serif; COLOR: rgb(31,73,125); FONT-S= IZE: 8pt">______________________________________________

= Steph= en P. Boczenowski

<= SPAN style=3D"FONT-FAMILY: Arial, sans-serif; COLOR: rgb(31,73,125); FONT-S= IZE: 10pt">      The MITRE Corp= oration

      Office: (7= 81) 271-7682

      Cell:= (978) 302-3849

     sboc= zeno@mitre.org

&nbs= p;

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG<= /A> with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you hav= e difficulties, write to OVAL-DEVELOPER-LIST-reques= t@LISTS.MITRE.ORG.

T= o unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG w= ith SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have dif= ficulties, write to OVAL-DEVELOPER-LIST-request@LIS= TS.MITRE.ORG.

To unsubscribe, send an email message to LISTSE= RV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the = message. If you have difficulties, write to OVAL-DE= VELOPER-LIST-request@LISTS.MITRE.ORG.



_____________= __________________________________
sacm mailing list
sacm@ietf.org
<= A class=3DparsedLink href=3D"https://www.ietf.org/mailman/listinfo/sacm" ta= rget=3D_blank>https://www.ietf.org/mailman/listinfo/sacm
From david.waltermire@nist.gov Mon May 14 12:03: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 2AC0921F8767 for ; Mon, 14 May 2012 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.456 X-Spam-Level: X-Spam-Status: No, score=-5.456 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn3nE9Y+TD9e for ; Mon, 14 May 2012 12:03:41 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id F2F2421F8763 for ; Mon, 14 May 2012 12:03:39 -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.355.2; Mon, 14 May 2012 15:03:25 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 14 May 2012 15:03:38 -0400 From: "Waltermire, David A." To: "Kinney, Michael A" , "david.oliva@verizon.net" , "Kent_Landfield@McAfee.com" , SCAP-DEV , "sacm@ietf.org" Date: Mon, 14 May 2012 15:03:35 -0400 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0wd+CS9svKA/9zTuS3t0cuM7bijQBSSCkwABC1WoA= Message-ID: References: <22541297.132421.1336851964583.JavaMail.root@vznit170080> <15D0981C9BE53042A4C9D0F3D0B6826B290130@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: <15D0981C9BE53042A4C9D0F3D0B6826B290130@MSIS-GH1-UEA10.corp.nsa.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_D7A0423E5E193F40BE6E94126930C4930B993245C7MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 19:03:45 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B993245C7MBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCg0KSSBhbSB3b3JraW5nIHRvIGdldCBhIHNlc3Npb24gb24gdGhlIGFnZW5kYSBhdCBE ZXYgRGF5cyB0byBkaXNjdXNzIHZhcmlvdXMgYXNwZWN0cyBvZiBjb250ZW50IHJlcG9zaXRvcnkg ZnVuY3Rpb24uICBJIHNlZSB0aGlzIGFzIGFuIGFyZWEgdGhhdCBoYXMgYnJvYWQgYXBwZWFsIHRo YXQgbWlnaHQgYmUgYSBnb29kIGNvbnNpZGVyYXRpb24gZm9yIG9uZSBvZiB0aGUgaW5pdGlhbCB3 b3JrIGl0ZW1zIGZvciBTQUNNLg0KDQpTaW5jZXJlbHksDQpEYXZlDQoNCkZyb206IEtpbm5leSwg TWljaGFlbCBBIFttYWlsdG86bS5raW5uZUByYWRpdW0ubmNzYy5taWxdDQpTZW50OiBNb25kYXks IE1heSAxNCwgMjAxMiA3OjEwIEFNDQpUbzogZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ7IEtlbnRf TGFuZGZpZWxkQE1jQWZlZS5jb207IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBTQ0FQLURFVjsgc2Fj bUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzYWNtXSBSZXF1ZXN0IGZvciBwYXJ0aWNpcGFudHMg LSBDb250ZW50IFJlcG9zaXRvcnkgU3BlY2lmaWNhdGlvbiBEZXZlbG9wbWVudA0KDQpLZW50LCBJ IHJlLXJlYWQgeW91ciBjb21tZW50cywgYW5kIHVuZGVyc3RhbmQgeW91ciBwb2ludHMuIEdsYWQg c29tZW9uZSBpcyBzZXR0aW5nIHVwIGFub3RoZXIgU0NBUCByZXBvc2l0b3J5LCBJIHdvdWxkIGxp a2UgdG8gYmUgaW5jbHVkZWQsIHNvIHdpbGwgdGhpcyBiZSBkaXNjdXNzZWQgYXQgZGV2ZWxvcGVy IGRheXMsIG9yIFNBQ00sIG9yIHdpbGwgaXMgc29tZW9uZSBnb2luZyB0byBzZXR1cCBhbm90aGVy IHdvcmtpbmcgZ3JvdXA/DQpJdCB3aWxsIGJlIGludGVyZXN0aW5nIHRvIGdldCBldmVyeW9uZSB0 byBjcmVhdGUgYW5kIHNoYXJlIGNvbnRlbnQsIGFyZSB5b3Ugb2ZmZXJpbmcgdXAgc2hhcmluZyBv ZiBNY0FmZWUgY29udGVudD8NCg0KLU1pa2UNCg0KRnJvbTogZGF2aWQub2xpdmFAdmVyaXpvbi5u ZXQ8bWFpbHRvOmRhdmlkLm9saXZhQHZlcml6b24ubmV0PiBbbWFpbHRvOmRhdmlkLm9saXZhQHZl cml6b24ubmV0XTxtYWlsdG86W21haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldF0+DQpTZW50 OiBTYXR1cmRheSwgTWF5IDEyLCAyMDEyIDM6NDYgUE0NClRvOiBLZW50X0xhbmRmaWVsZEBNY0Fm ZWUuY29tPG1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPjsgS2lubmV5LCBNaWNoYWVs IEE7IGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8bWFpbHRvOmRhdmlkLndhbHRlcm1pcmVAbmlz dC5nb3Y+OyBTQ0FQLURFVkBuaXN0LmdvdjxtYWlsdG86U0NBUC1ERVZAbmlzdC5nb3Y+OyBzYWNt QGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzYWNtXSBSZXF1 ZXN0IGZvciBwYXJ0aWNpcGFudHMgLSBDb250ZW50IFJlcG9zaXRvcnkgU3BlY2lmaWNhdGlvbiBE ZXZlbG9wbWVudA0KDQpUbyBhbGw6DQoNCkkgYW0gaW50ZXJlc3RlZCBpbiBsb2NhdGluZyBjb250 ZW50IGZvciBTQ0FQIDEuMi4NCkluIHBhcnRpY3VsYXIsIGNvbnRlbnQgZm9yIHRoZSBzcGVjaWZp Y2F0aW9ucyBhZGRlZCBhZnRlciAxLjAuDQpBcmUgeW91IGFsbCB0YWxraW5nIGFib3V0IFNDQVAg MS4yIENvbnRlbnQ/DQoNCkRhdmlkIE9saXZhDQoNCg0KT24gMDUvMTEvMTIsIEtlbnRfTGFuZGZp ZWxkQE1jQWZlZS5jb208bWFpbHRvOktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb20+IHdyb3RlOg0K DQpNaWtlIEkgbG92ZSBpdCB3aGVuIHlvdSB0ZWUgc29tZXRoaW5nIHVwIGxpa2UgdGhhdOKApi4g Oy0pICBUaGFuayB5b3UuIDspDQoNCk1pa2Ugd3JvdGU6DQpJIHN0aWxsIHRoaW5rIHRoYXQgYW55 IHNwZWNpZmljYXRpb24gZm9yIGEgcmVwb3NpdG9yeSBpcyB3aXNoZnVsIHRoaW5raW5nIHVudGls IHNvbWVvbmUgYnVpbGRzIG9uZSBhbmQgbGVhcm5zIHRoZSBsZXNzb25zIGl0IHdpbGwganVzdCBi ZSBhbm90aGVyIHdoaXRlcGFwZXIgc3BlYy4gIEkgYmVsaWV2ZSB0aGUgRG9EIG5lZWRzIHRvIGlu Y29ycG9yYXRlIGEgbWV0YWRhdGEgcmVwb3NpdG9yeSBhcyBwYXJ0IG9mIGl0IGFuZCBvdGhlciBj dXN0b21pemF0aW9ucyB0aGF0IG1heSBub3QgYmUgdXNlZnVsIGZvciBldmVyeW9uZS4NCldlIG5l ZWQgdG8gdGFsayBtb3Jl4oCmDQoNCklmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBhIGhvbGlzdGlj LCBjb21wbGV0ZSBmZWRlcmF0ZWQgYXBwcm9hY2ggdG8gYSBjb250ZW50IHJlcG9zaXRvcnksIEkg c29tZSB3aGF0IGFncmVlLiAgSWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGFuIG9yZ2FuaXphdGlv bmFsIHJlcG9zaXRvcnksIEkgdG90YWxseSBkaXNhZ3JlZS4gQnV0IHlvdSBrbmV3IEkgd291bGQu IDspDQoNCkhlcmUgaXMgaG93IEkgc2VlIHRoZSBwcm9ibGVtLiAgVGhlcmUgaXMgYW4gaW1tZWRp YXRlIG5lZWQgZm9yIFNDQVAgYW5kIG90aGVyIHJlbGF0ZWQgY29udGVudCB0byBiZSBzZXJ2ZWQg dXAgaW5zaWRlIGFuIG9yZ2FuaXphdGlvbi4gIFRvZGF5IHdlIGhhdmUgc2l0dWF0aW9uIHdoZXJl IHRoZSBzdGFuZGFyZHMgYWxsb3cgdXMgdG8gcHJvdmlkZSBzaXRlcyB0aGUgY2FwYWJpbGl0eSB0 byBoYXZlIGEgc2luZ2xlIFNDQVAgaW1wbGVtZW50ZWQgcG9saWN5IHRoZXkgY2FsbCBvZmZpY2lh bCBmb3IgdGhlaXIgZW52aXJvbm1lbnQuIFllcyB0aGlzIGlzIGEgcmF0aGVyIHNpbXBsaXN0aWMg c2luY2UgdGhlcmUgYXJlIHRoaW5ncyBzdWNoIGFzIHRhcmdldGluZyBzcGVjaWZpYyBwbGF0Zm9y bXMsIHNwZWNpZmljIG9wZXJhdGlvbmFsIHVzZSBuZWVkcywgYnV0IGZvciBub3cgbGV0cyBhZ3Jl ZSBTQ0FQIGlzIGEgbWFzc2l2ZSBpbXByb3ZlbWVudCBvdmVyIHRoZSBwcm9wcmlldGFyeSBzaXR1 YXRpb25zIG9mIHRoZSBwYXN0LiBXaGlsZSB3ZSBoYXZlIGNyZWF0ZWQgdGhpcyBzdGFuZGFyZCBj b250ZW50IHNvIHRoYXQgc2l0ZXMgY2FuIGltcGxlbWVudCB0aGVpciBsb2NhbCBzaXRlIHNlY3Vy aXR5IG9uY2UgYW5kIHRoZW4gYXNzdXJlIHRoZXkgYXJlIG1lYXN1cmluZyBhbGwgYXBwcm9wcmlh dGVseSB0YXJnZXRlZCBkZXZpY2VzIHRoZSBzYW1lIHdheSwgd2UgaGF2ZSBmYWlsZWQgdG8gc3Vw cG9ydCB0aGUgb3BlcmF0aW9uYWwgbmVlZHMgb2YgdGhlIHNpdGVzLiAgV2UgaGF2ZSBhIHNpdHVh dGlvbiB3aGVyZSBubyB0d28gdmVuZG9ycyBkaXN0cmlidXRlIGNvbnRlbnQgdGhlIHNhbWUgd2F5 LiAgVGhpcyBjYXVzZXMgbWFzc2l2ZSBwcm9ibGVtcyBmb3IgdGhlIGFkbWluaXN0cmF0aW9uIHN0 YWZmIHdoZW4gdGhleSBuZWVkIHRvIGluY29ycG9yYXRlIGEgbmV3IFNDQVAgZW5hYmxlZCBwcm9k dWN0IGludG8gdGhlaXIgYXJjaGl0ZWN0dXJlLiAgVGhleSBuZWVkIHRvIGRpc2NvdmVyIGhvdyB0 aGUgbmV3IHByb2R1Y3Qgc3VwcG9ydHMgZGlzdHJpYnV0aW5nIFNDQVAgY29udGVudCB0byBpdCdz IHZhcmlvdXMgY29tcG9uZW50cy4gIElmIHRoZXkgaGF2ZSBvbmUgcHJvZHVjdCB0aGVuIHRoZXkg ZG8gdGhpcyBvbmUgYW5kIHRoZXkgYXJlIGRvbmUuICBJZiB0aGV5IGhhdmUgbXVsdGlwbGUgcHJv ZHVjdHMgdGhleSB3aWxsIGhhdmUgdG8gZmlndXJlIG91dCBob3cgdG8gbWluaW1pemUgdGhlIGlt cGFjdCBieSBpbmNvcnBvcmF0aW5nIHRoZSB1cGRhdGUgcHJvY2VzcyBmb3IgdGhlIG5ldyBwcm9k dWN0IGludG8gdGhlIGV4aXN0aW5nIFNDQVAgc2VjdXJpdHkgY29udGVudCBwcm9jZXNzZXMuIE5v dyB3aGVuIHRoZSBpbmV2aXRhYmxlIGhhcHBlbnMgYW5kIHRoZSBzaXRlIHN0YWZmIG5lZWRzIHRv IG1ha2UgYSBjaGFuZ2UgdG8gdGhlaXIgc2VjdXJpdHkgcG9saWN5LCB0aGV5IGhhdmUgdG8gbWFr ZSB0aGUgbW9kaWZpY2F0aW9ucyB0byB0aGUgYmVuY2htYXJrIG9yIGNoZWNrcyBvciBib3RoIGFu ZCB0aGVuIGRpc3RyaWJ1dGUgdGhvc2UgdXBkYXRlcyBhY3Jvc3MgdGhlaXIgbmV0d29yay4gIEZv ciBlYWNoIFNDQVAgZW5hYmxlZCBwcm9kdWN0IHRoZXkgaGF2ZSBpbiBwbGFjZSwgdGhleSBoYXZl IGRvdWJsZWQsIHRyaXBsZWQgb3IgbW9yZSB0aGUgd29yayBuZWVkZWQgdG8gbWFrZSB0aG9zZSB1 cGRhdGVzIGF2YWlsYWJsZS4NCg0KVGhlcmUgaXMgYW5vdGhlciBjb250ZW50IHJlcG9zaXRvcnkg cHJvYmxlbSBhbmQgdGhhdCBpcyB0aGUgRmVkZXJhdGVkIENvbnRlbnQgRGlzdHJpYnV0aW9uLiAg SWYgeW91IHRoaW5rIGdsb2JhbCBETlMgeW91IGhhdmUgYSBnZW5lcmFsIGZyYW1lIG9mIHJlZmVy ZW5jZS4gIFRoZSBndWlkYW5jZSBhdXRob3JzIG5lZWQgdG8gYmUgYWJsZSB0byBwdWJsaXNoIGNv bnRlbnQgaW4gYW4gYXV0aG9yaXRhdGl2ZSBtYW5uZXIgc28gdGhlaXIgY29udGVudCBpcyB1cGRh dGVkIGluIGEgdGltZWx5IGZhc2hpb24uICBUaGlzIGlzIGEgbXVjaCBoYXJkZXIgcHJvYmxlbSB0 byBzb2x2ZSBpZiB0aGVyZSBpcyBubyBsb2NhbCBvcmdhbml6YXRpb25hbCBpbmZyYXN0cnVjdHVy ZSB0byBzdXBwb3J0IGl0LiA7KQ0KDQpTbyBoZXJlIGlzIHdoYXQgSSBhbSB0aGlua2luZ+KApiAg V2Ugc2hvdWxkIGNvbnNpZGVyIGFkZHJlc3NpbmcgdGhlc2UgYXMgdHdvIHNlcGFyYXRlIGJ1dCBp bnRlZ3JhdGVkIGVmZm9ydHMuICBJIGJlbGlldmUgdGhlIE9yZ2FuaXphdGlvbmFsIENvbnRlbnQg UmVwb3NpdG9yeSBpcyB0aGUgbW9yZSBjcml0aWNhbCBwaWVjZSB0aGF0IGlzIGFjdHVhbGx5IGVh c2llciB0byBhZGRyZXNzLiAgVGhlIEZlZGVyYXRlZCBDb250ZW50IERpc3RyaWJ1dGlvbiBzaG91 bGQgYmUgYSBzdWJzZXF1ZW50IGVmZm9ydCBpbnRlZ3JhdGluZyAvIGF1Z21lbnRpbmcgdGhlIE9y Z2FuaXphdGlvbmFsIHJlcG9zaXRvcnkgc3BlY2lmaWNhdGlvbi4NCg0KTWlrZSwgdG8geW91ciBw b2ludCB0aGF0IHdlIG5lZWQgc29tZW9uZSB0byBidWlsZCBvbmUgZmlyc3TigKYgVGhhdCBoYXMg aGFwcGVuZWQgYWxyZWFkeS4gIEkgaGF2ZSBvbmUgYXMgZG8gb3RoZXIgdmVuZG9ycyBidXQgd2hh dCB3ZSBkb27igJl0IGhhdmUgaXMgdGhlIGFjY2VzcyBzcGVjaWZpY2F0aW9uLiAgT3VycyBhcmUg Zm9jdXNlZCBvbiBvdXIgc3BlY2lmaWMgcHJvZHVjdCBuZWVkcy4gIEFkZGl0aW9uYWxseSB0aGVy ZSBpcyBhIGNvbXBhbnkgdGhhdCBoYXMgZGV2ZWxvcGVkIGEgY29tbWVyY2lhbCBTQ0FQIGNvbnRl bnQgcmVwb3NpdG9yeSB0aGF0IHdpbGwgYmUgYW5ub3VuY2VkIGxhdGVyIHRoaXMgbW9udGguIEkg d29uJ3Qgc3RlYWwgdGhlaXIgdGh1bmRlciBidXQgSSB3YXMgcmVjZW50bHkgZ2l2ZW4gYSBzbmVh ayBwZWVrIGF0IGl0IGFuZCBJIG11c3QgYWRtaXQgSSB3YXMgdmVyeSBpbXByZXNzZWQuICBBZ2Fp biwgdG8geW91ciBwb2ludCwgaXQgaGFzIGJlZW4gZG9uZS4gV2hhdCBpcyBuZWVkZWQgdG8gYWRk cmVzcyB0aGUgaW5pdGlhbCBvcGVyYXRpb25hbCBwcm9ibGVtIGlzIHRvIGRldmVsb3AgYSBzcGVj aWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBjb25zaXN0ZW50IG1lYW5zIGZvciBhbGwgU0NBUCBw cm9kdWN0cyB0byByZXRyaWV2ZSB0aGUgYXBwcm9wcmlhdGUgY29udGVudCBhcyBjb25maWd1cmVk IGFuZCBtYW5hZ2VkIGJ1dCB0aGUgc2l0ZS4NCg0KVE8gVEhBVCBFTkTigKYuDQoNCkkgYW0gcmVx dWVzdGluZyBwYXJ0aWNpcGF0aW9uIGZyb20gdGhvc2UgaW4gdGhlIGNvbW11bml0eSB0aGF0IHNl ZSB0aGUgbmVlZCBhbmQgd2FudCB0byBwdXQgaW4gdGhlIHdvcmsgdG8gbWFrZSB0aGlzIHNwZWNp ZmljYXRpb24gaGFwcGVuLiAgSSBoYXZlIHRhbGtlZCB0byBhIGNvdXBsZSBvZiB5b3UgYnV0IEkg ZG8gbm90IHdhbnQgdG8gYXNzdW1lIHlvdXIgcGFydGljaXBhdGlvbi4gIElmIHlvdSBhcmUgaW50 ZXJlc3RlZCBwbGVhc2UgY29udGFjdCBtZSBzbyB3ZSBjYW4gZ2V0IHRoaXMgc3RhcnRlZC4NCg0K VGhhbmtzIQ0KDQpLZW50IExhbmRmaWVsZA0KRGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJj aGl0ZWN0dXJlIGFuZCBTdGFuZGFyZHMNCg0KTWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueQ0KNTAw MCBIZWFkcXVhcnRlcnMgRHIuDQpQbGFubywgVGV4YXMgNzUwMjQNCg0KRGlyZWN0OiArMS45NzIu OTYzLjcwOTYNCk1vYmlsZTogKzEuODE3LjYzNy44MDI2DQpXZWI6IHd3dy5tY2FmZWUuY29tPGh0 dHA6Ly93d3cubWNhZmVlLmNvbS8+DQoNCkZyb206IDxLaW5uZXk+LCBNaWNoYWVsIEEgPG0ua2lu bmVAcmFkaXVtLm5jc2MubWlsPG1haWx0bzptLmtpbm5lQHJhZGl1bS5uY3NjLm1pbD4+DQpUbzog RGF2aWQgV2FsdGVybWlyZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjxtYWlsdG86ZGF2aWQu d2FsdGVybWlyZUBuaXN0Lmdvdj4+LCBTQ0FQLURFViA8U0NBUC1ERVZAbmlzdC5nb3Y8bWFpbHRv OlNDQVAtREVWQG5pc3QuZ292Pj4sICJzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3Jn PiIgPHNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtz YWNtXSBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2VjdXJpdHkgQXV0b21hdGlvbiBEZXZlbG9wZXIg RGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwgTUENCg0KRGF2ZSwNCkkgaGF2 ZSBubyBwcm9ibGVtIHdpdGggd2ViaW5hcnMsIEkgZG8gd2FudCB0byBrZWVwIGRldmVsb3BlciBk YXlzIGFjdGlvbmFibGUgYW5kIHVzZSBpdCB0byBtYWtlIGRlY2lzaW9ucywgYW5kIHZvdGUgYW5k IGFjY29tcGxpc2ggdGhpbmdzIGdvb2Qgb3IgYmFkLiAgSSBkbyBub3Qgd2FudCB0aGlzIHRvIGJl IGFuIGluZm9ybWF0aW9uYWwgYnJpZWZpbmcgY29uZmVyZW5jZS4NClRoYW5rcyBmb3IgdGhlIGxp bmtzLg0KDQpJIHN0aWxsIHRoaW5rIHRoYXQgYW55IHNwZWNpZmljYXRpb24gZm9yIGEgcmVwb3Np dG9yeSBpcyB3aXNoZnVsIHRoaW5raW5nIHVudGlsIHNvbWVvbmUgYnVpbGRzIG9uZSBhbmQgbGVh cm5zIHRoZSBsZXNzb25zIGl0IHdpbGwganVzdCBiZSBhbm90aGVyIHdoaXRlcGFwZXIgc3BlYy4g IEkgYmVsaWV2ZSB0aGUgRG9EIG5lZWRzIHRvIGluY29ycG9yYXRlIGEgbWV0YWRhdGEgcmVwb3Np dG9yeSBhcyBwYXJ0IG9mIGl0IGFuZCBvdGhlciBjdXN0b21pemF0aW9ucyB0aGF0IG1heSBub3Qg YmUgdXNlZnVsIGZvciBldmVyeW9uZS4NCldlIG5lZWQgdG8gdGFsayBtb3Jl4oCmDQoNCi1NaWtl DQoNCkZyb206IFdhbHRlcm1pcmUsIERhdmlkIEEuIFttYWlsdG86ZGF2aWQud2FsdGVybWlyZUBu aXN0Lmdvdl0NClNlbnQ6IFR1ZXNkYXksIE1heSAwOCwgMjAxMiAxMDo0NCBBTQ0KVG86IEtpbm5l eSwgTWljaGFlbCBBOyBTQ0FQLURFVjsgc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJFOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2VjdXJpdHkgQXV0b21hdGlv biBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwgTUENCg0K TWlrZSwNCg0KV2hhdCBhYm91dCBoYXZpbmcgd2ViaW5hcnMgaW4tcGxhY2Ugb2YgdGhlIDMwIG1p bnV0ZSBicmllZnM/DQoNClJlZ2FyZGluZyBjb250ZW50IG1hbmFnZW1lbnQsIHdlIGFyZSBidWls ZGluZyB0aGUgcHJvdG90eXBlIGNvbnRlbnQgcmVwb3NpdG9yeSBmb3IgdXNlIGluIGEgcHJvZHVj dGlvbiBlbnZpcm9ubWVudC4gIEFzIGFuIG9wZW4gc291cmNlIHByb2plY3QsIGl0IHdpbGwgYmUg ZnJlZSBmb3IgdXNlIGJ5IGFueW9uZSBpbnRlcmVzdGVkLiAgTXkgdGhpbmtpbmcgaXMgdGhhdCB0 aGlzIHByb2plY3QgY2FuIGJyaWRnZSB0aGUgZ2FwIHVudGlsIGNvbW1lcmNpYWwgc29sdXRpb25z IGFyZSBhdmFpbGFibGUgdG8gYXVnbWVudCBpdC4gIFRoaXMgaXMgYSBzaW1pbGFyIHBhdGggdGhh dCB3YXMgZm9sbG93ZWQgd2l0aCBETlMgKGJpbmQpIGFuZCBIVFRQIChhcGFjaGUpLiAgV2hlbiBp dCBpcyByZWFkeSBmb3IgdXNlLCBJIGFtIGhvcGluZyB0byB1c2UgaXQgdG8gaG9zdCBVU0dDQiBj b250ZW50LiAgWW91IHdvdWxkIGJlIHdlbGNvbWUgdG8gdXNlIGl0IGZvciB5b3VyIG5lZWRzLg0K DQpJdCBpcyBnb29kIHRoYXQgT0NJTCBpcyBtb3ZpbmcgZm9yd2FyZC4gIFRoaXMgaXMgYW4gaW1w b3J0YW50IHBpZWNlIG9mIHN1cHBvcnRpbmcgcmlzayBtYW5hZ2VtZW50IGFuZCBhc3BlY3RzIG9m IGNvbnRpbnVvdXMgbW9uaXRvcmluZy4gIEkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSBzb21lIGRp c2N1c3Npb24gb24gT0NJTCBhdCBEZXZlbG9wZXIgRGF5cy4gIFdpdGggdGhlIHByb3Bvc2FscyB3 ZSB3aWxsIGxpa2VseSBoYXZlIGEgc2Vuc2Ugb2Ygd2hhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQg YW5kIHdoYXQgd2UgY2FuIGFjaGlldmUgY29uc2Vuc3VzIG9uIG91dHNpZGUgdGhlIG1lZXRpbmcu DQoNClJlbWVkaWF0aW9uIGlzIGEgdG9waWMgbmVhciBhbmQgZGVhciB0byBteSBoZWFydC4gIEkg dG9vIHdvdWxkIGxpa2UgdG8gc2VlIGl0IG1vdmUgZm9yd2FyZC4NCg0KV2UganVzdCBwdWJsaXNo ZWQgdGhlIGRyYWZ0IEFTUiBzcGVjaWZpY2F0aW9uIGZvciBwdWJsaWMgY29tbWVudC4gIFRoaXMg c3BlY2lmaWNhdGlvbiBzdXBwb3J0cyBlbnRlcnByaXNlIGFnZ3JlZ2F0ZSByZXBvcnRpbmcgd2hp Y2ggZ3JlYXRseSByZWR1Y2VzIHRoZSBkYXRhIHZvbHVtZXMgbmVlZGVkIHZlcnNlcyBkZXRhaWxl ZCBob3N0LWJhc2VkIHJlcG9ydHMuIFRoaXMgc3BlY2lmaWNhdGlvbiBoYXMgYmVlbiBkZXNpZ25l ZCBhcyBhIG1vcmUgcm9idXN0IHJlcGxhY2VtZW50IGZvciBMQVNSLiAgSXQgY2FuIGJlIHVzZWQg aW4gY29udGludW91cyBtb25pdG9yaW5nIGFwcGxpY2F0aW9ucyB0byBzdXBwb3J0IGFnZ3JlZ2F0 ZSBkYXRhIHJlcG9ydGluZyBuZWVkcyAoZS5nLiBGSVNNQSByZXBvcnRpbmcsICBDeWJlclNjb3Bl KS4NCg0KSGVyZSBhcmUgdGhlIGxpbmtzOg0KDQpodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNh dGlvbnMvUHVic0RyYWZ0cy5odG1sDQpodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMv UHVic05JU1RJUnMuaHRtbCNOSVNULUlSLTc4NDgNCg0KVGhlIHByaW1hcnkgcmVhc29uIHdlIGhh dmUgc3VnZ2VzdGVkIHdhaXRpbmcgb24gWENDREYgaXMgbm90IHRoZSBpbnRlcm5hdGlvbmFsaXph dGlvbiBpc3N1ZS4gTWFueSB2ZW5kb3JzIGhhdmUgY29tbWVudGVkIHRoYXQgdGhleSBhcmUgc3Rp bGwgd29ya2luZyBvbiBpbXBsZW1lbnRpbmcgdGhlIFhDQ0RGIDEuMi4xIHNwZWNpZmljYXRpb24u IFdlIHdpbGwgYmUgaW4gYSBiZXR0ZXIgcGxhY2UgaW4gYSBmZXcgbW9udGhzIG9uY2UgbW9yZSBk ZXZlbG9wbWVudCBhcm91bmQgWENDREYgaGFzIG9jY3VycmVkLiAgQXMgd2UgY29uc2lkZXIgY2hh bmdlcyB0byB0aGUgU0NBUCBzdGFjayB0byBhZGRyZXNzIE9DSUwgYW5kIG90aGVyIGlzc3Vlcywg d2Ugd2lsbCBpZGVudGlmeSBhcmVhcyB0aGF0IG5lZWQgaW1wcm92ZW1lbnQgaW4gWENDREYuICBU aGVzZSBhcmUgZ29vZCBhbmQgbmVjZXNzYXJ5IGRpc2N1c3Npb25zIHRvIGhhdmUgbm93LCBidXQg d2UgaGF2ZSBhIGdvb2QgZGVhbCBvZiB3b3JrIHRvIGRvIGJlZm9yZSB3ZSBhcmUgcmVhZHkgdG8g b3BlbiB1cCBYQ0NERi4gIE15IHN1Z2dlc3Rpb24gaXMgdG8gd29yayBvbiB0aGVzZSByZWxhdGVk IGFyZWFzIGFuZCB0aGVuIHdvcmsgdXAgY2hhbmdlIHByb3Bvc2FscyBmb3IgWENDREYgYXMgbmVl ZGVkLiAgQnkgdGhhdCB0aW1lIHdlIHNob3VsZCBiZSByZWFkeSB0byB3b3JrIG9uIGEgbmV3IHJl dmlzaW9uIG9mIFhDQ0RGLg0KDQpJIGFtIGFsc28gbG9va2luZyBmb3J3YXJkIHRvIHRoZSBkaXNj dXNzaW9ucyBhdCB0aGUgY29uZmVyZW5jZS4gIEl0IGhhcyBiZWVuIHRvbyBsb25nLg0KDQpTaW5j ZXJlbHksDQpEYXZlDQoNCkZyb206IEtpbm5leSwgTWljaGFlbCBBIFttYWlsdG86bS5raW5uZUBy YWRpdW0ubmNzYy5taWxdDQpTZW50OiBUdWVzZGF5LCBNYXkgMDgsIDIwMTIgNzowOSBBTQ0KVG86 IFNDQVAtREVWDQpDYzogV2FsdGVybWlyZSwgRGF2aWQgQS4NClN1YmplY3Q6IFJFOiBbT1ZBTC1E RVZFTE9QRVItTElTVF0gU2VjdXJpdHkgQXV0b21hdGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVy IDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwgTUENCg0KS2VudCwNCg0KSXTigJlzIGdvb2QgdG8g cmVhZCB5b3VyIHRob3VnaHRzLCBhbmQgYSByZWFsaXN0aWMgYWN0aW9uYWJsZSBhcHByb2FjaCBp cyBpbmRlZWQgbmVlZGVkLiAgU2luY2UgYWxsIHRoZSBhY3Rpdml0eSBoYXNu4oCZdCBiZWVuIG9u IHRoZSBsaXN0cyBhIGJyaWVmIDHFvTIgaG91ciByZWNhcCBtYXkgYmUgaW4gb3JkZXIgdG8gYnJp bmcgZXZlcnlvbmUgdXAgdG8gc3BlZWQgc2luY2UgdGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2YgYWN0 aXZpdHkgb24gQ1BFL1NXSUQsIE9DSWwsIE1BRUMvQ3liT1ggQ0VFIGFuZCBvdGhlcnMuDQoNCldl IGNvdWxkIHdyaXRlIGEgY29udGVudCByZXBvc2l0b3J5IHNwZWNpZmljYXRpb24sIGJ1dCB3aXRo b3V0IHNvbWVvbmUgd2lsbGluZyB0byBzdGFuZCBvbmUgdXAgaXQgd2lsbCBiZSBhcyB2YWx1YWJs ZSBhcyB0aGUgQ0NTUyBzcGVjaWZpY2F0aW9uIGlzIHRvZGF5LiAgSeKAmXZlIGJlZW4gdHJ5aW5n IGZvciB0d28geWVhcnMgdG8gZ2V0IG15IG1hbmFnZW1lbnQgdG8gZ2V0IGEgY29vcmRpbmF0ZWQg ZWZmb3J0IHRvZ2V0aGVyIGZvciB0aGUgRG9EIHRvIHN0YW5kIHVwIGEgcmVwb3NpdG9yeSwgaXQg aXMgYSB0b3VnaCBwcm9ibGVtIGFuZCB3aWxsIHJlcXVpcmUgZnVuZGluZyB3aXRoIGEgdGFpbCwg SeKAmW0gbm90IHN1cmUgYSBzcGVjaWZpY2F0aW9uIHdpbGwgc29sdmUgdGhhdCBwcm9ibGVtLg0K DQpXZSAoRG9EKSBoYXZlIGJlZW4gcHV0dGluZyBhIGxvdCBvZiBlZmZvcnQgaW50byBPQ0lMIG92 ZXIgdGhlIGxhc3QgeWVhciB0cnlpbmcgdG8gbWFrZSBpdCB1c2VmdWwgaW4gYW4gZW50ZXJwcmlz ZSBlbnZpcm9ubWVudCBhbmQgd2lsbCBiZSBwb3N0aW5nIG91ciBpZGVhcyB0byB0aGUgbGlzdCBi ZWZvcmUgZGV2ZWxvcGVyIGRheXMgaXQgc2hvdWxkIGhhdmUgYWxyZWFkeSBzdGFydGVkLCB3ZSBu ZWVkIHRvIGdldCBjb25zZW5zdXMgYW5kIGEgdm90ZSBvbiBob3cgdGhlIGNvbW11bml0eSB3aXNo ZXMgdG8gcHJvY2VlZC4NCg0KUmVtZWRpYXRpb24gaXMgc3RhbGxlZCBidXQgSeKAmW0gbWFraW5n IGV2ZXJ5IGVmZm9ydCB0byBnZXQgaXQga2ljayBzdGFydGVkIGZyb20gb3VyIHBlcnNwZWN0aXZl LiBJIGhvcGUgdG8gYXNzaXN0IGluIGdldHRpbmcgdGhlIGRyYWZ0IEVSSSBmaW5pc2hlZCB0aGlz IHllYXIuICBXZSBhcmUgd3JpdGluZyBzb21lIG5ldyBTVElHIGNvbnRlbnQgYW5kIGludGVuZCB0 byB1c2VkIHRoZSBkcmFmdCBDUkUgc3BlY2lmaWNhdGlvbiB0byBpbnNlcnQgQ1JFIGludG8gdGhl IGNvbnRlbnQgc28gd2UgKERvRCkgY2FuIGRvIHNvbWUgYXV0b21hdGljIGNvbmZpZ3VyYXRpb24g Zml4ZXMsIHBhcnQgb2YgYSBzZWxmIGhlYWxpbmcgbmV0d29yayBjb25jZXB0LiBJdCBpcyBqdXN0 IGEgc3RhcnQgYnV0IHRoZSBiZXN0IHdlIGNhbiBkbyBhdCB0aGlzIHBvaW50Lg0KDQpFbnRlcnBy aXNlIHJlcG9ydGluZyBpcyBhbiBpbnRlcmVzdGluZyBzdWJqZWN0LCBzaW5jZSBYTUwgYWRkcyBz aXplIHRvIGFuZCBjb250ZW50IHRvIHJvbGwgdXAgcmVwb3J0aW5nLCBpbiBhbnkgZW50ZXJwcmlz ZSBvZiBzaXplIHRoZSBwcm9ibGVtIGdldHMgZ3JlYXRlciwgSSBsb29rIGZvcndhcmQgdG8geW91 ciB0aG91Z2h0cyBvbiB0aGF0IHN1YmplY3QuDQoNCkkgYW0gY29uY2VybmVkIHRoYXQgdGhlIGlu dGVybmF0aW9uYWxpemF0aW9uIGVmZm9ydHMgYXJlIGRldHJhY3RpbmcgZnJvbSBlZmZvcnRzIHRv IG1lZXQgdXNlIGNhc2VzLCB3ZSBoYXZlIHNvbWUgdGhpbmdzIHdlIHdvdWxkIGxpa2UgY2hhbmdl ZCBpbiBYQ0NERiB0byBzdXBwb3J0IG91ciBPQ0lsIHVzZSBjYXNlIGFuZCBJIGhhdmUgYmVlbiB0 b2xkIHRoYXQgSSBuZWVkIHRvIHdhaXQuIEkgZGlkbuKAmXQgdGhpbmsgdGhhdCBhIG1vdmUgdG8g aW50ZXJuYXRpb25hbGl6YXRpb24gc2hvdWxkIGltcGVkZSBlZmZvcnRzIHRvIG1vdmUgZm9yd2Fy ZCB3aXRoIHVzZSBjYXNlcy4NCg0KSSBsb29rIGZvcndhcmQgdG8gdGFsa2luZyB3aXRoIHlvdSBh dCB0aGUgY29uZmVyZW5jZS4NCg0Kdi9yDQoNCk1pa2UgS2lubmV5DQpQcm9qZWN0IERpcmVjdG9y DQpDb21wdXRlciBOZXR3b3JrIERlZmVuc2UgUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgKENORCBS JlQpIE9mZmljZQ0KOTgwMCBTYXZhZ2UgUm9hZCBTdGUgNjc2Nw0KRnQgTWVhZGUsIE1EIDIwNzU1 LTY3NjcNClBob25lOiA0MTAtODU0LTQ0MjINCk5TVFM6IDk2OC04ODg2DQpGYXggNDEwLTg1NC00 NjgxDQptYWtpbm4yQG5zYS5nb3Y8bWFpbHRvOk0ua2lubmVAcmFkaXVtLm5jc2MubWlsPg0KDQoN Cg0KRnJvbTpzY2FwLWRldkBuaXN0LmdvdjxtYWlsdG86c2NhcC1kZXZAbmlzdC5nb3Y+IFttYWls dG86c2NhcC1kZXZAbmlzdC5nb3ZdPG1haWx0bzpbbWFpbHRvOnNjYXAtZGV2QG5pc3QuZ292XT4g T24gQmVoYWxmIE9mIFdhbHRlcm1pcmUsIERhdmlkIEEuDQpTZW50OiBNb25kYXksIE1heSAwNywg MjAxMiA3OjA5IFBNDQpUbzogTXVsdGlwbGUgcmVjaXBpZW50cyBvZiBsaXN0DQpTdWJqZWN0OiBS RTogW09WQUwtREVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERh eXM6IFN1bW1lciAyMDEyIGF0IE1JVFJFIGluIEJlZGZvcmQsIE1BDQoNCktlbnQsDQoNCkkgbGlr ZSB3aGF0IHlvdSBhcmUgc2F5aW5nIGhlcmUuICBXZSBhcmUgYWxzbyBpbiBzdXBwb3J0IG9mIHRo aXMgdHlwZSBvZiBhcHByb2FjaC4gIFdlIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUgY29tbXVuaXR5 IGRpc2N1c3Npb24gYXJvdW5kIHdoYXQgYXJlIHRoZSBrZXkgYXJlYXMvcHJpb3JpdGllcyB0aGF0 IHRoZSBjb21tdW5pdHkgd291bGQgbGlrZSB0byBzZWUgZGlzY3Vzc2VkIGF0IERldiBEYXlzLiAg WW91ciB0b3BpY3MgYmVsb3cgbG9vayBsaWtlIGEgZ29vZCBzdGFydC4gVGhlIFNBQ00gbGlzdCBt aWdodCBiZSBhIGJldHRlciB2ZW51ZSB0aGFuIHRoZSBPVkFMIGxpc3QgZm9yIHRoaXMgZGlzY3Vz c2lvbi4gIEZvciBlYWNoIGFyZWEgd2Ugc2hvdWxkIGZvY3VzIHRoZSBkaXNjdXNzaW9uIGFyb3Vu ZCBkZXZlbG9waW5nIG9iamVjdGl2ZXMgZm9yIGVhY2ggc2Vzc2lvbi4gIFRoZSBzZXNzaW9ucyBj YW4gYmUgdGltZSBib3hlZCBiYXNlZCBvbiB3aGF0IHdvdWxkIGJlIGEgcmVhc29uYWJsZSBhbW91 bnQgb2YgdGltZSB0byBhY2NvbXBsaXNoIGVhY2ggb2JqZWN0aXZlLiAgRm9yIGV4YW1wbGUgaWYg Y29udGludW91cyBtb25pdG9yaW5nIGlzIGEgcHJpb3JpdHkgYW5kIGNvbGxlY3RpdmVseSBpdCB0 YWtlcyAzIGRheXMgdG8gd29yayB0aHJvdWdoIGFsbCB0aGUgb2JqZWN0aXZlcywgSSBzZWUgbm8g cHJvYmxlbSB3aXRoIHRoYXQuICBXZSBjYW4gYWxzbyBrZWVwIGEgZmV3IHNlc3Npb25zIOKAnG9u IGRlY2vigJ0gaWYgYWxsIHRoZSBvYmplY3RpdmVzIGFyZSByZWFjaGVkIGFuZCB3ZSBjb21wbGV0 ZSBhbGwgdGhlIHNjaGVkdWxlZCBzZXNzaW9ucyBlYXJseS4NCg0KVGhvdWdodHM/DQoNClNpbmNl cmVseSwNCg0KRGF2aWQgV2FsdGVybWlyZQ0KU0NBUCBBcmNoaXRlY3QNCk5hdGlvbmFsIEluc3Rp dHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kNCigzMDEpIDk3NS0zMzkwDQpkYXZpZC53 YWx0ZXJtaXJlQG5pc3QuZ292PG1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Pg0KDQpG cm9tOnNjYXAtZGV2QG5pc3QuZ292PG1haWx0bzpzY2FwLWRldkBuaXN0Lmdvdj4gW21haWx0bzpz Y2FwLWRldkBuaXN0Lmdvdl08bWFpbHRvOlttYWlsdG86c2NhcC1kZXZAbmlzdC5nb3ZdPiBPbiBC ZWhhbGYgT2YgS2VudF9MYW5kZmllbGRAbWNhZmVlLmNvbTxtYWlsdG86S2VudF9MYW5kZmllbGRA bWNhZmVlLmNvbT4NClNlbnQ6IE1vbmRheSwgTWF5IDA3LCAyMDEyIDQ6MjUgUE0NClRvOiBTQ0FQ LURFVg0KU3ViamVjdDogUmU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0 aW9uIERldmVsb3BlciBEYXlzOiBTdW1tZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQQ0K DQpBbGwsDQoNCkkgd291bGQgbGlrZSB0byBkaXNjdXNzIHRoZSBmb3JtYXQgZm9yIHRoZSBTQ0FQ IERldmVsb3BlciBEYXlzIHRoYXQgc2VlbXMgdG8gYmUgbGlzdGVkIGJlbG93Lg0KDQpJIHNlZSB0 aGlzIGFwcGVhcnMgdG8gZm9sbG93IGEgcGF0aCB3ZSBoYXZlIGRpc2N1c3NlZCBpbiB0aGUgcGFz dCBhcyB0aGUgd2F5IG5vdCB0byBob2xkIGEgRGV2IERheXMgZXZlbnQuICBXZSBoYXZlIGJlZW4g dHJ5aW5nIHRvIGdldCBhd2F5IGZyb20gJ0RlYXRoIGJ5IFBvd2VycG9pbnQnIGFuZCBiYWNrIHRv IHRoZSB0eXBlIG9mIGV2ZW50IHdlIGhlbGQgeWVhcnMgYWdvIHdoZW4gd2Ugd2VyZSBoaWdobHkg cHJvZHVjdGl2ZS4gIEluIHRoZSBwYXN0IHdlIGhhZCBhIHRvcGljIHRvIGJlIGRpc2N1c3NlZCBh bmQgYSB0aW1lIGJveCB0byB3b3JrIHdpdGhpbi4gIFRoYXQgYWxsb3dlZCB1cyB0byBoYXZlIHZl cnkgYWN0aXZlIGJyYWluc3Rvcm1pbmcgc2Vzc2lvbnMgaW4gYSBoaWdoIGJhbmR3aWR0aCBlbnZp cm9ubWVudC4NCg0KQXQgcGFzdCBTdW1tZXIgZXZlbnRzIHdlIGhhdmUgZ290IGludG8gYSBwYXR0 ZXJuIG9mIGxvdHMgb2YgcG93ZXJwb2ludCwgbG90cyBvZiBzdGF0dXMgb2YgdGhlIGVmZm9ydHMg YW5kIHZlcnkgbGl0dGxlIGRpc2N1c3Npb24gYWJvdXQgdGhpbmdzIHRoYXQgbmVlZCBhY3RpdmUg ZGlzY3Vzc2lvbnMuICBXZSBuZWVkIHRvIGtlZXAgbW92aW5nIGZvcndhcmQgYW5kIG1ha2luZyBw cm9ncmVzcyBhcyBhbiBlZmZvcnQuIFdlIGNhbiBnZXQgc3RhdHVzIGZyb20gdmFyaW91cyBwbGFj ZXMgc3VjaCBhcyB0aGUgbGlzdHMsIGEgcHJlc2VudGF0aW9uIGJlaW5nIHNlbnQgb3V0IGluIGFk dmFuY2UsIGEgd2ViaW5hciBpZiBpdCBpcyBmZWx0IHRoZXJlIHdpbGwgYmUgcXVlc3Rpb25zIGFu ZCBhbnN3ZXJzIGZyb20gdGhvc2UgdGhhdCBhcmUgbmV3IHRvIHRoZSBlZmZvcnRzLiAgV2UgaGF2 ZSBhIGxpbWl0ZWQgYW1vdW50IG9mIHRpbWUgYW5kIGFsbCB3aG8gYXJlIGF0dGVuZGluZyBhcmUg aW52ZXN0aW5nIGEgZ3JlYXQgZGVhbCBvZiB0aW1lIGFuZCBtb25leSB0byBiZSB0aGVyZS4gIFdl IHNob3VsZCBub3QgIGJlIHNwZW5kaW5nIGEgZ3JlYXQgZGVhbCBvZiB0aW1lIHJlZWR1Y2F0aW5n IGV2ZXJ5b25lIHdoZW4gd2UgY291bGQgYmUgZm9jdXNlZCBvbiBhZHZhbmNpbmcgbmVlZGVkIGVm Zm9ydHMuDQoNClRoZSB0eXBlIG9mIGFwcHJvYWNoIHRvIGEgRGV2IERheXMgZXZlbnQgd2FzIGRp c2N1c3NlZCBhdCB0aGUgbGFzdCBTdW1tZXIgRGV2IERheXMuICBJIGhhdmUgc2VlbiB0aGUgZm9s bG93aW5nIHdvcmsgcXVpdGUgd2VsbCBpbiBvdGhlciBlZmZvcnRzLg0KDQogMS4gIFByZXNlbnRh dGlvbnMgYXJlIHNlbnQgb3V0IHRvIHRoZSBhdHRlbmRlZXMgYW5kIHRoZSBsaXN0cyBhIHdlZWsg aW4gYWR2YW5jZS4NCiAyLiAgU3RhdHVzIGZvciBhbnkgZWZmb3J0IGlzIGxpbWl0ZWQgdG8gMzAg bWludXRlcw0KIDMuICBGb2N1c2VkIGJyYWluc3Rvcm1pbmcgdGltZSBzaG91bGQgYmUgZXN0YWJs aXNoZWQgZm9yIGNlcnRhaW4gYXJlYXMgdGhhdCBuZWVkIHJlYWwgd29yayBieSB0aGUgY29tbXVu aXR5DQogNC4gIEVmZm9ydHMgdG8gYmUgZGlzY3Vzc2VkIHNob3VsZCBiZSBiYXNlZCBvbiBuZWVk cyBvZiB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBzcGFjZSB0byBtb3ZlIGV4aXN0aW5nIGVmZm9y dHMgdG8gY29tcGxldGlvbi4NCkZvciBleGFtcGxlOg0KDQpDb250aW51b3VzIG1vbml0b3Jpbmcg aXMgYSBtYWpvciBkaXJlY3Rpb24gdGhlIGVmZm9ydHMgYXJlIGJlY29taW5nIGludm9sdmVkIHdp dGguIFRoZXJlIGFyZSBnb2luZyB0byBiZSB0aGluZ3Mgd2UgbmVlZCB0byBkbyBhcyBhIHNlY3Vy aXR5IGF1dG9tYXRpb24gY29tbXVuaXR5IHRvIGJlIGFibGUgdG8gYWNjb21wbGlzaCB3aGF0IGlz IGxpc3RlZCBpbiB0aGUgQ0FFU0FSUyBGRS4gIFRoZXJlIGFyZSBpbnRlcmZhY2VzIHRoYXQgbmVl ZCB0byBiZSB3b3JrZWQgYW5kIGVzdGFibGlzaGVkLiAgVGhhdCBpcyBvbmUgYXJlYSB0aGF0IGlz IG5vdCBsaXN0ZWQgYmVsb3cuICBDTSB3aWxsIGhhdmUgYSBtYWpvciBpbXBhY3Qgb24gYWxsIG9m IHVzIGluIHRoZSBuZXh0IGNvdXBsZSB5ZWFycyBhbmQgaXQgaXMgYmVpbmcgaWdub3JlZC4gIFdl IGNhbid0IGtlZXAgdHJ5aW5nIHRvIHNvbHZlIHdoYXQgaGFzIGFscmVhZHkgYmVlbiBzb2x2ZWQu ICBXZSBuZWVkIHRvIGFkZHJlc3MgdGhlIG5lZWRlZCBpbnRlcmZhY2UgZGV2ZWxvcG1lbnQgbm93 LiBUaGlzIGlzIGFuIGVmZm9ydCB0aGF0IGNvdWxkIHRha2UgbmVhcmx5IGEgd2hvbGUgZGF5IGJ5 IGl0c2VsZi4NCg0KT3BlcmF0aW9uYWxseSB3ZSBoYXZlIGEgcmVhbCBuZWVkIHRvIGJlIGFibGUg dG8gZGVsaXZlciBTQ0FQIGNvbnRlbnQgaW50ZXJuYWxseSB3aXRoaW4gYW4gb3JnYW5pemF0aW9u LiBUb2RheSB0aGUgU0NBUCB2ZW5kb3JzIGNhbm5vdCBzaGFyZSBhIHNpbmdsZSBsb2NhbCBzaXRl IHNlY3VyaXR5IHBvbGljeSAoWENDREYgKyBPVkFMICsgQ1BFICvigKYpIHdpdGhvdXQgdGhlIHNp dGUgc3RhZmYgaGF2aW5nIHRvIGdvIHRvIGVhY2ggb2YgdGhlIGluZGl2aWR1YWwgcHJvZHVjdHMg YW5kIGZpZ3VyaW5nIG91dCBob3cgdG8gaW5qZWN0IHRoYXQgbmV3IG9yIHVwZGF0ZWQgcG9saWN5 IGludG8gdGhhdCBwcm9kdWN0cyBkZWxpdmVyeSBtZWNoYW5pc21zLiAgVGhhdCBpcyBsaW1pdGlu ZyBzaXRlcyBmcm9tIHdhbnRpbmcgdG8gYnV5IG11bHRpcGxlIGZvY3VzZWQgU0NBUCBwcm9kdWN0 cyBzaW5jZSB0aGV5IGFyZSBzdWNoIGEgcGFpbiB0byBtYW5hZ2UgZnJvbSBhIGNvbnRlbnQgcGVy c3BlY3RpdmUuICBJdCBpcyBlYXNpZXIgdG8gYnV5IGZyb20gb25lIHZlbmRvciB0aGF0IGhhcyBh IHNpbmdsZSBtZWFucyBmb3IgZGlzdHJpYnV0aW5nIGNvbnRlbnQgdGhhbiBpdCBpcyB0byBkZWFs IHdpdGggdGhlIG1hbmFnZW1lbnQgaXNzdWVzIHRoYXQgaGF2aW5nIG11bHRpcGxlIFNDQVAgcHJv ZHVjdHMgcHJlc2VudHMuICBXZSBuZWVkIHRvIGhhdmUgYXQgbGVhc3QgYW4gZW50aXJlIDEvMiBh IGRheSBvbiB0aGUgZGV2ZWxvcG1lbnQgb2YgYSBDb250ZW50IFJlcG9zaXRvcnkgc3BlY2lmaWNh dGlvbi4NCg0KT0NJTCBpcyBhIHBvc2l0aXZlIGFuZCBhIG5lZ2F0aXZlIGF0IHRoZSBzYW1lIHRp bWUuIEl0IGhhcyByZWFsIHZhbHVlIHRoYXQgaXMgYmVpbmcgdW5kZXJ1dGlsaXplZCBhbmQgdW5k ZXIgaW1wbGVtZW50ZWQgYmVjYXVzZSBvZiB0aGUgbGltaXRhdGlvbnMgb2YgaG93IGl0IGFkZHJl c3NlcyB1c2VzIGluIGFuIGVudGVycHJpc2UgZW52aXJvbm1lbnQuICBQZW9wbGUgZG9uJ3QgbmVl ZCBzZWN1cml0eSBhdXRvbWF0aW9uIHRvIGRvIHRoaW5ncyBvbi9mb3IgYSBzaW5nbGUgaG9zdC4g IFRoZXkgbmVlZCBzZWN1cml0eSBhdXRvbWF0aW9uIHRvIGZvY3VzIG9uIHRoZSBlbnRlcnByaXNl IGlzc3VlcyB0aGF0IHJlZHVjZSB0aGVpciBjb3N0cyBhbmQgaW1wcm92ZSB0aGVpciBlZmZpY2ll bmNpZXMuICBPQ0lMIGlzIGZhaWxpbmcgaW4gdGhlIGVudGVycHJpc2UgYW5kIHdlIGFsbCB1bmRl cnN0YW5kIHRoYXQuICBXZSBuZWVkIHRvIGFkZHJlc3MgZGV2ZWxvcGluZyBhIGRlZmluaXRpdmUg c29sdXRpb24gZm9yIGluY29ycG9yYXRpbmcgT0NJTCBpbnRvIHRoZSBlbnRlcnByaXNlIGFuZCB0 aGF0IG1lYW5zIGludG8gdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zLiBTY2hlZHVsaW5nIGFu ZCB0cmFja2luZyBhcmUga2V5IHRvIGl0J3Mgc3VjY2Vzcy4gIFdlIG5lZWQgdG8gbWFrZSB0aGF0 IGhhcHBlbi4gIFRoaXMgdG9vIG5lZWRzIGEgZm9jdXNlZCBicmFpbnN0b3JtaW5nIHRpbWUgYm94 IHRvIGRpc2N1c3Mgb3B0aW9ucy4NCg0KSSBhbSByZWFsbHkgZGlzYXBwb2ludGVkIHRoYXQgUmVt ZWRpYXRpb24gaXMgbm90IG9uIHRoZSBsaXN0IGJlbG934oCmICBZZXMsIGxhc3QgU3VtbWVyIERl diBEYXlzLCB0aGUgdGltZSBzcGVudCBvbiBSZW1lZGlhdGlvbiB3YXMgd2FzdGVkIHRpbWUgYnV0 IHRoYXQgZG9lcyBub3QgbWVhbiB3ZSBzaG91bGQgaWdub3JlIGl0IGFuZCBub3QgdHJ5IHRvIG1h a2Ugc29tZSByZWFsIHByb2dyZXNzLiAgQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkIHdlIG5lZWQg dG8gcmVib290IHRoZSByZW1lZGlhdGlvbiBlZmZvcnQuICBXZSBjYW5ub3Qga2VlcCBiZWluZyB0 aGUgc2V0IG9mIHNwZWNpZmljYXRpb25zIC8gdG9vbHMgdGhhdCBhY3QgYXMgdGhlIGxpdHRsZSBi b3kgY3J5aW5nICJXb2xmIiBpbiB0aGUgbmlnaHQuICBXZSBuZWVkIHRvIGJlIGFibGUgdG8gZmlu ZCBhbmQgZml4IGlzc3VlcyBpZiB3ZSBhcmUgZ29pbmcgdG8gcmVhbGx5IG1ha2UgYSBkaWZmZXJl bmNlIGluIG9yZ2FuaXphdGlvbmFsIHNlY3VyaXR5IHBvc3R1cmVzLiAgQnV0IHRvZGF5IHdlIHRo aW5rIGl0IGlzIHRvbyBoYXJkIHNvIHdlIGRvbid0IHRyeSA/ICBJIHRoaW5rIHdlIG5lZWQgYSBj b3VwbGUgaG91cnMgdG8gZGlzY3VzcyB0aGUgcmVib290IG9mIHRoZSBlZmZvcnQgZXZlbiBpZiB0 aGF0IG1lYW5zIG1pbmltaXppbmcgd29yayBhbHJlYWR5IGRvbmUuDQoNCkEgZm9jdXNlZCBkaXNj dXNzaW9uIG9uIGVudGVycHJpc2UgcmVwb3J0aW5nIGlzIGFsc28gY3JpdGljYWxseSBuZWVkZWQu ICBGb3IgdGhlIHZlbmRvcnMgaGVyZSwgd2UgaGF2ZSBhbGwgZ29uZSB0aHJvdWdoIHRoZSBDeWJl cnNjb3BlIGdvYXQgcm9wZSwgZGVsaXZlcmluZyBsaW1pdGVkIGNhcGFiaWxpdGllcyB0byBzcGVj aWZpYyBkYXRhIGNhbGwgcmVxdWlyZW1lbnRzIG9mIHRoZSBGZWRlcmFsIEFnZW5jaWVzLiAgVGhl IGluaXRpYWwgZWZmb3J0IHdhcyBhIG1lc3MsIGRpZCBsaXR0bGUgbW9yZSB0aGFuIHByb3ZlIGl0 IHdhcyBwb3NzaWJsZSBhbmQgY2F1c2UgdGhlIHZlbmRvciBjb21tdW5pdHkgYSBncmVhdCBkZWFs IG9mIHRocmFzaGluZyB0byBwdXQgYSBrbHVkZ2V5ICdzb2x1dGlvbicgaW4gcGxhY2UuICBSZWFs aXR5IGlzIGFsbCBvdXIgY3VzdG9tZXJzIG5lZWQgcm9sbCB1cCByZXBvcnRpbmcgYW5kIGFuIGlu ZnJhc3RydWN0dXJlIHRoYXQgc3VwcG9ydHMgaXQuICBBIGRhdGEgY2FsbCBzaG91bGQgbm90IGJl IHNwZWNpYWwgdG8gYW55b25lIG90aGVyIHRoYW4gdGhlIGFnZW5jaWVzIHJlc3BvbmRpbmcuIFRo ZSB0b29scyBzaG91bGQgYmUgYWJsZSB0byBzZWxlY3QgdGhlIHR5cGVzIG9mIGRhdGEgbmVlZGVk IGFuZCBkZWxpdmVyIHRoYXQgb24gYSBzY2hlZHVsZWQgYmFzaXMgYXV0b21hdGljYWxseS4gICAg RW50ZXJwcmlzZSBSZXBvcnRpbmcgcGVydGFpbnMgdG8gY29tbWVyY2lhbCBhcyB3ZWxsIGFzIEZl ZGVyYWwgY3VzdG9tZXJzLiAgV2UgbmVlZCB0byBmb2N1cyBzb21lIHRpbWUgb24gd2hhdCB0aGF0 IHdvdWxkIGxvb2sgbGlrZSB1c2luZyB0aGUgQVJGIGFuZCBBU1IgYXMgdGhlIGZvdW5kYXRpb25h bCBwaWVjZXMuICBCdXQgdGhlcmUgYXJlIG1pc3NpbmcgcGllY2Vz4oCmLiAgV2UgbmVlZCB0aGlz IGRpc2N1c3NlZC4NCg0KSSB3b3VsZCBob3BlIHdlIGNhbiBtYWtlIHRoaXMgc3VtbWVyJ3MgU0NB UCBEZXYgRGF5cyB1c2VmdWwgaW4gYWR2YW5jaW5nIHRoZSBzZWN1cml0eSBhdXRvbWF0aW9uIGVm Zm9ydHMgYnkgYWRkcmVzc2luZyBzb21lIG9mIHRoZSBtb3JlIGNyaXRpY2FsIGlzc3VlcyBvdXIg Y3VzdG9tZXJzIGFyZSBmYWNpbmcgbm93IG9yIHdpbGwgYmUgZmFjaW5nIGluIHRoZSB2ZXJ5IHNo b3J0IHRlcm0uICBTdGF0dXMgcHJlc2VudGF0aW9ucyBhcmUgbm90IGludGVyZXN0aW5nIHRvIHRo b3NlIGFjdGl2ZSBpbiB0aGUgZWZmb3J0cy4gIExldCdzIHRyeSB0byBkbyB0aG9zZSBiZWZvcmUg d2UgZ2V0IHRvIEJlZGZvcmQgc28gd2UgY2FuIHJlYWwgbWFrZSBzb21lIHByb2dyZXNzIHdoaWxl IHdlIGFyZSBhbGwgaW4gdGhlIHNhbWUgcm9vbS4gIFRoaXMgaXMgYWx3YXlzIGEgYmlnIGV2ZW50 IGZvciB0aGUgJ2NvbnNlbnN1cyBvZiB0aGUgd2lsbGluZycgdGhhdCBhc3NlbWJsZSBhbmQgZHJp dmVuIHRvIHNlZSBzZWN1cml0eSBhdXRvbWF0aW9uIG1ha2UgYSBkaWZmZXJlbmNlLiAgTGV0J3Mg c2VlIGlmIHdlIGNhbiBoYXZlIGFuIGV2ZW50IHRoYXQsIHdoZW4gd2UgYWxsIHdhbGsgb3V0IHRo ZSBsYXN0IGRheSwgd2UgYWxsIGZlZWwgdGhhdCBldmVyeSBtaW51dGUgd2FzIHdlbGwgc3BlbnQg YW5kIG1vdmVzIHVzIGZvcndhcmQuDQoNClRoYW5rcy4NCg0KS2VudCBMYW5kZmllbGQNCkRpcmVj dG9yIENvbnRlbnQgU3RyYXRlZ3ksIEFyY2hpdGVjdHVyZSBhbmQgU3RhbmRhcmRzDQoNCk1jQWZl ZSB8IEFuIEludGVsIENvbXBhbnkNCjUwMDAgSGVhZHF1YXJ0ZXJzIERyLg0KUGxhbm8sIFRleGFz IDc1MDI0DQoNCkRpcmVjdDogKzEuOTcyLjk2My43MDk2DQpNb2JpbGU6ICsxLjgxNy42MzcuODAy Ng0KV2ViOiB3d3cubWNhZmVlLmNvbTxodHRwOi8vd3d3Lm1jYWZlZS5jb20vPg0KDQpGcm9tOiA8 Qm9jemVub3dza2k+LCBTdGV2ZSA8c2JvY3plbm9ATUlUUkUuT1JHPG1haWx0bzpzYm9jemVub0BN SVRSRS5PUkc+Pg0KUmVwbHktVG86ICJPVkFMIERldmVsb3BlciBMaXN0IChDbG9zZWQgUHVibGlj IERpc2N1c3Npb24pIiA8T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8bWFpbHRv Ok9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPj4NClRvOiAiT1ZBTC1ERVZFTE9Q RVItTElTVEBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMu TUlUUkUuT1JHPiIgPE9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPG1haWx0bzpP VkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRz4+DQpTdWJqZWN0OiBSZTogW09WQUwt REVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1bW1l ciAyMDEyIGF0IE1JVFJFIGluIEJlZGZvcmQsIE1BDQoNCkZyYW5rOw0KDQpXZSBob3BlIHRvIGhh dmUgdGhlIHJlZ2lzdHJhdGlvbiBzaXRlIHVwIG5leHQgd2Vlay4gIFRoZSBldmVudCB3aWxsIGJl IGR1cmluZyB0aGUgd2VlayBvZiBKdWx5IDkg4oCTIHN0YXJ0aW5nIE1vbmRheSBhdCAxMDowMCBB TSBhbmQgZW5kaW5nIG9uIEZyaWRheSBhdCAxMjowMC4NCg0KTWVhbndoaWxlLCB3ZSBhcmUgd29y a2luZyBvbiB0aGUgYWdlbmRhIGFuZCBhcmUgY3VycmVudGx5IGNvbnNpZGVyaW5nIHRoaXMgbGlz dCBvZiB0b3BpY3M6DQoNCkNDRQ0KQ1BFL1NXSUQNCkNFRQ0KWENDREYNCk9WQUwNCkFTUg0KRW50 ZXJwcmlzZSBPQ0lMDQpDeWJPWC9NQUVDDQpGZWRlcmF0ZWQgQ29udGVudCBSZXBvc2l0b3J5IFNw ZWMNCkVuZHBvaW50IFJlcG9ydGluZyBmb3IgQ29udGludW91cyBNb25pdG9yaW5nIGFuZCBDb21w bGlhbmNlIChFUkNDKQ0KTUlMRQ0KVEFYSUkNCklGLU0gZm9yIFNDQVANCklGLU1BUA0KU0NBUCBS ZWxlYXNlcw0KU0NBUCBhbmQgSUVURg0KTkVUQ09ORiBhbmQgU0NBUA0KDQpTdGV2ZQ0KDQpGcm9t OiBGcmFuayBMaW5kc2F5IEFja2VyIFttYWlsdG86YWZyYW5rQE5PVkEuRURVXQ0KU2VudDogVHVl c2RheSwgTWF5IDAxLCAyMDEyIDk6MzIgQU0NClRvOiBvdmFsLWRldmVsb3Blci1saXN0IE9WQUwg RGV2ZWxvcGVyIExpc3QvQ2xvc2VkIFB1YmxpYyBEaXNjdXNzaW9uDQpTdWJqZWN0OiBSZTogW09W QUwtREVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1 bW1lciAyMDEyIGF0IE1JVFJFIGluIEJlZGZvcmQsIE1BDQoNClN0ZXZlLi4uLg0KDQpIYXMgdGhl cmUgYmVlbiBhbnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhpcyBldmVudD8N Cg0KVGhhbmtzLA0KRnJhbmsgQWNrZXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpGcm9tOiBCb2N6ZW5vd3NraSwgU3RldmUgW3Nib2N6ZW5vQE1JVFJFLk9SRzxtYWlsdG86c2Jv Y3plbm9ATUlUUkUuT1JHPl0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDE2OjM4DQpU bzogT1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOk9WQUwtREVWRUxP UEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPg0KU3ViamVjdDogW09WQUwtREVWRUxPUEVSLUxJU1Rd IFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1JVFJF IGluIEJlZGZvcmQsIE1BDQpTYXZlIHRoZSBEYXRlOiB3ZWVrIG9mIEp1bHkgOSwgMjAxMg0KDQpU aGlzIHllYXLigJlzIE1JVFJFLWhvc3RlZCBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBE YXlzIGV2ZW50IHdpbGwgYmUgaGVsZCBkdXJpbmcgdGhlIHdlZWsgb2YgSnVseSA5LCAyMDEyIGF0 IE1JVFJF4oCZcyBmYWNpbGl0eSBpbiBCZWRmb3JkLCBNQS4NCg0KRGV0YWlscyB0byBmb2xsb3cu DQoNClJlZ2FyZHMsDQogICAgU3RldmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KU3RlcGhlbiBQLiBCb2N6ZW5vd3NraQ0KICAgICAgVGhlIE1JVFJF IENvcnBvcmF0aW9uDQogICAgICBPZmZpY2U6ICg3ODEpIDI3MS03NjgyDQogICAgICBDZWxsOiAo OTc4KSAzMDItMzg0OQ0KICAgICBzYm9jemVub0BtaXRyZS5vcmc8bWFpbHRvOnNib2N6ZW5vQG1p dHJlLm9yZz4NCg0KVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byBMSVNU U0VSVkBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRz4gd2l0 aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2Uu IElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUgdG8gT1ZBTC1ERVZFTE9QRVItTElTVC1y ZXF1ZXN0QExJU1RTLk1JVFJFLk9SRzxtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0 QExJU1RTLk1JVFJFLk9SRz4uDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdl IHRvIExJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzxtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUu T1JHPiB3aXRoIFNJR05PRkYgT1ZBTC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUg bWVzc2FnZS4gSWYgeW91IGhhdmUgZGlmZmljdWx0aWVzLCB3cml0ZSB0byBPVkFMLURFVkVMT1BF Ui1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPG1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNU LXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPi4NClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFuIGVtYWls IG1lc3NhZ2UgdG8gTElTVFNFUlZATElTVFMuTUlUUkUuT1JHPG1haWx0bzpMSVNUU0VSVkBMSVNU Uy5NSVRSRS5PUkc+IHdpdGggU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZ IG9mIHRoZSBtZXNzYWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIE9WQUwt REVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8bWFpbHRvOk9WQUwtREVWRUxP UEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc+Lg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2FjbSBtYWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCg== --_000_D7A0423E5E193F40BE6E94126930C4930B993245C7MBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNSVRSRTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBw bGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyMTIzMDE3NzI7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi05NzMxODU2NDI7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTc5ODkxMjI0OTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQ3NTg5MDY0ODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk1pa2UsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5JIGFtIHdvcmtpbmcgdG8gZ2V0IGEgc2Vzc2lvbiBvbiB0aGUgYWdl bmRhIGF0IERldiBEYXlzIHRvIGRpc2N1c3MgdmFyaW91cyBhc3BlY3RzIG9mIGNvbnRlbnQgcmVw b3NpdG9yeSBmdW5jdGlvbi7CoCBJIHNlZSB0aGlzIGFzIGFuIGFyZWEgdGhhdCBoYXMgYnJvYWQg YXBwZWFsIHRoYXQgbWlnaHQgYmUgYSBnb29kIGNvbnNpZGVyYXRpb24gZm9yIG9uZSBvZiB0aGUg aW5pdGlhbCB3b3JrIGl0ZW1zIGZvciBTQUNNLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TaW5j ZXJlbHksPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBLaW5uZXksIE1pY2hhZWwgQSBbbWFpbHRvOm0u a2lubmVAcmFkaXVtLm5jc2MubWlsXSA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDE0LCAy MDEyIDc6MTAgQU08YnI+PGI+VG86PC9iPiBkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDsgS2VudF9M YW5kZmllbGRATWNBZmVlLmNvbTsgV2FsdGVybWlyZSwgRGF2aWQgQS47IFNDQVAtREVWOyBzYWNt QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW3NhY21dIFJlcXVlc3QgZm9yIHBhcnRp Y2lwYW50cyAtIENvbnRlbnQgUmVwb3NpdG9yeSBTcGVjaWZpY2F0aW9uIERldmVsb3BtZW50PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5L ZW50LCBJIHJlLXJlYWQgeW91ciBjb21tZW50cywgYW5kIHVuZGVyc3RhbmQgeW91ciBwb2ludHMu IEdsYWQgc29tZW9uZSBpcyBzZXR0aW5nIHVwIGFub3RoZXIgU0NBUCByZXBvc2l0b3J5LCBJIHdv dWxkIGxpa2UgdG8gYmUgaW5jbHVkZWQsIHNvIHdpbGwgdGhpcyBiZSBkaXNjdXNzZWQgYXQgZGV2 ZWxvcGVyIGRheXMsIG9yIFNBQ00sIG9yIHdpbGwgaXMgc29tZW9uZSBnb2luZyB0byBzZXR1cCBh bm90aGVyIHdvcmtpbmcgZ3JvdXA/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IHdpbGwgYmUgaW50ZXJlc3RpbmcgdG8gZ2V0 IGV2ZXJ5b25lIHRvIGNyZWF0ZSBhbmQgc2hhcmUgY29udGVudCwgYXJlIHlvdSBvZmZlcmluZyB1 cCBzaGFyaW5nIG9mIE1jQWZlZSBjb250ZW50PyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi1NaWtl PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29O b3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRv OmRhdmlkLm9saXZhQHZlcml6b24ubmV0Ij5kYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDwvYT4gPGEg aHJlZj0ibWFpbHRvOlttYWlsdG86ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXRdIj5bbWFpbHRvOmRh dmlkLm9saXZhQHZlcml6b24ubmV0XTwvYT4gPGJyPjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWF5 IDEyLCAyMDEyIDM6NDYgUE08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86S2VudF9MYW5k ZmllbGRATWNBZmVlLmNvbSI+S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTwvYT47IEtpbm5leSwg TWljaGFlbCBBOyA8YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiI+ZGF2 aWQud2FsdGVybWlyZUBuaXN0LmdvdjwvYT47IDxhIGhyZWY9Im1haWx0bzpTQ0FQLURFVkBuaXN0 LmdvdiI+U0NBUC1ERVZAbmlzdC5nb3Y8L2E+OyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9y ZyI+c2FjbUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbc2FjbV0gUmVxdWVz dCBmb3IgcGFydGljaXBhbnRzIC0gQ29udGVudCBSZXBvc2l0b3J5IFNwZWNpZmljYXRpb24gRGV2 ZWxvcG1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+VG8gYWxsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SSBh bSBpbnRlcmVzdGVkIGluIGxvY2F0aW5nIGNvbnRlbnQgZm9yIFNDQVAgMS4yLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5JbiBwYXJ0aWN1bGFyLCBjb250ZW50IGZvciB0aGUgc3BlY2lmaWNhdGlvbnMgYWRkZWQgYWZ0 ZXIgMS4wLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz5BcmUgeW91IGFsbCB0YWxraW5nIGFib3V0IFNDQVAgMS4yIENv bnRlbnQ/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5EYXZpZCBPbGl2YTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5PbiAwNS8xMS8xMiwgPGEgaHJl Zj0ibWFpbHRvOktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb20iPktlbnRfTGFuZGZpZWxkQE1jQWZl ZS5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5NaWtlIEkgbG92ZSBpdCB3aGVuIHlvdSB0ZWUgc29tZXRoaW5nIHVwIGxpa2UgdGhh dOKApi4gOy0pICZuYnNwO1RoYW5rIHlvdS4gOyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5NaWtlIHdyb3RlOiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SSBzdGlsbCB0aGluayB0aGF0IGFueSBzcGVjaWZpY2F0aW9uIGZvciBhIHJl cG9zaXRvcnkgaXMgd2lzaGZ1bCB0aGlua2luZyB1bnRpbCBzb21lb25lIGJ1aWxkcyBvbmUgYW5k IGxlYXJucyB0aGUgbGVzc29ucyBpdCB3aWxsIGp1c3QgYmUgYW5vdGhlciB3aGl0ZXBhcGVyIHNw ZWMuICZuYnNwO0kgYmVsaWV2ZSB0aGUgRG9EIG5lZWRzIHRvIGluY29ycG9yYXRlIGEgbWV0YWRh dGEgcmVwb3NpdG9yeSBhcyBwYXJ0IG9mIGl0IGFuZCBvdGhlciBjdXN0b21pemF0aW9ucyB0aGF0 IG1heSBub3QgYmUgdXNlZnVsIGZvciBldmVyeW9uZS48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPldlIG5lZWQgdG8gdGFsayBtb3Jl4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPklmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBhIGhvbGlz dGljLCBjb21wbGV0ZSBmZWRlcmF0ZWQgYXBwcm9hY2ggdG8gYSBjb250ZW50IHJlcG9zaXRvcnks IEkgc29tZSB3aGF0IGFncmVlLiAmbmJzcDtJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgYW4gb3Jn YW5pemF0aW9uYWwgcmVwb3NpdG9yeSwgSSB0b3RhbGx5IGRpc2FncmVlLiBCdXQgeW91IGtuZXcg SSB3b3VsZC4gOyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkhlcmUgaXMgaG93IEkgc2VlIHRo ZSBwcm9ibGVtLiAmbmJzcDtUaGVyZSBpcyBhbiBpbW1lZGlhdGUgbmVlZCBmb3IgU0NBUCBhbmQg b3RoZXIgcmVsYXRlZCBjb250ZW50IHRvIGJlIHNlcnZlZCB1cCBpbnNpZGUgYW4gb3JnYW5pemF0 aW9uLiAmbmJzcDtUb2RheSB3ZSBoYXZlIHNpdHVhdGlvbiB3aGVyZSB0aGUgc3RhbmRhcmRzIGFs bG93IHVzIHRvIHByb3ZpZGUgc2l0ZXMgdGhlIGNhcGFiaWxpdHkgdG8gaGF2ZSBhIHNpbmdsZSBT Q0FQIGltcGxlbWVudGVkIHBvbGljeSB0aGV5IGNhbGwgb2ZmaWNpYWwgZm9yIHRoZWlyIGVudmly b25tZW50LiBZZXMgdGhpcyBpcyBhIHJhdGhlciBzaW1wbGlzdGljIHNpbmNlIHRoZXJlIGFyZSB0 aGluZ3Mgc3VjaCBhcyB0YXJnZXRpbmcgc3BlY2lmaWMgcGxhdGZvcm1zLCBzcGVjaWZpYyBvcGVy YXRpb25hbCB1c2UgbmVlZHMsIGJ1dCBmb3Igbm93IGxldHMgYWdyZWUgU0NBUCBpcyBhIG1hc3Np dmUgaW1wcm92ZW1lbnQgb3ZlciB0aGUgcHJvcHJpZXRhcnkgc2l0dWF0aW9ucyBvZiB0aGUgcGFz dC4gV2hpbGUgd2UgaGF2ZSBjcmVhdGVkIHRoaXMgc3RhbmRhcmQgY29udGVudCBzbyB0aGF0IHNp dGVzIGNhbiBpbXBsZW1lbnQgdGhlaXIgbG9jYWwgc2l0ZSBzZWN1cml0eSBvbmNlIGFuZCB0aGVu IGFzc3VyZSB0aGV5IGFyZSBtZWFzdXJpbmcgYWxsIGFwcHJvcHJpYXRlbHkgdGFyZ2V0ZWQgZGV2 aWNlcyB0aGUgc2FtZSB3YXksIHdlIGhhdmUgZmFpbGVkIHRvIHN1cHBvcnQgdGhlIG9wZXJhdGlv bmFsIG5lZWRzIG9mIHRoZSBzaXRlcy4gJm5ic3A7V2UgaGF2ZSBhIHNpdHVhdGlvbiB3aGVyZSBu byB0d28gdmVuZG9ycyBkaXN0cmlidXRlIGNvbnRlbnQgdGhlIHNhbWUgd2F5LiAmbmJzcDtUaGlz IGNhdXNlcyBtYXNzaXZlIHByb2JsZW1zIGZvciB0aGUgYWRtaW5pc3RyYXRpb24gc3RhZmYgd2hl biB0aGV5IG5lZWQgdG8gaW5jb3Jwb3JhdGUgYSBuZXcgU0NBUCBlbmFibGVkIHByb2R1Y3QgaW50 byB0aGVpciBhcmNoaXRlY3R1cmUuICZuYnNwO1RoZXkgbmVlZCB0byBkaXNjb3ZlciBob3cgdGhl IG5ldyBwcm9kdWN0IHN1cHBvcnRzIGRpc3RyaWJ1dGluZyBTQ0FQIGNvbnRlbnQgdG8gaXQncyB2 YXJpb3VzIGNvbXBvbmVudHMuICZuYnNwO0lmIHRoZXkgaGF2ZSBvbmUgcHJvZHVjdCB0aGVuIHRo ZXkgZG8gdGhpcyBvbmUgYW5kIHRoZXkgYXJlIGRvbmUuICZuYnNwO0lmIHRoZXkgaGF2ZSBtdWx0 aXBsZSBwcm9kdWN0cyB0aGV5IHdpbGwgaGF2ZSB0byBmaWd1cmUgb3V0IGhvdyB0byBtaW5pbWl6 ZSB0aGUgaW1wYWN0IGJ5IGluY29ycG9yYXRpbmcgdGhlIHVwZGF0ZSBwcm9jZXNzIGZvciB0aGUg bmV3IHByb2R1Y3QgaW50byB0aGUgZXhpc3RpbmcgU0NBUCBzZWN1cml0eSBjb250ZW50IHByb2Nl c3Nlcy4gTm93IHdoZW4gdGhlIGluZXZpdGFibGUgaGFwcGVucyBhbmQgdGhlIHNpdGUgc3RhZmYg bmVlZHMgdG8gbWFrZSBhIGNoYW5nZSB0byB0aGVpciBzZWN1cml0eSBwb2xpY3ksIHRoZXkgaGF2 ZSB0byBtYWtlIHRoZSBtb2RpZmljYXRpb25zIHRvIHRoZSBiZW5jaG1hcmsgb3IgY2hlY2tzIG9y IGJvdGggYW5kIHRoZW4gZGlzdHJpYnV0ZSB0aG9zZSB1cGRhdGVzIGFjcm9zcyB0aGVpciBuZXR3 b3JrLiAmbmJzcDtGb3IgZWFjaCBTQ0FQIGVuYWJsZWQgcHJvZHVjdCB0aGV5IGhhdmUgaW4gcGxh Y2UsIHRoZXkgaGF2ZSBkb3VibGVkLCB0cmlwbGVkIG9yIG1vcmUgdGhlIHdvcmsgbmVlZGVkIHRv IG1ha2UgdGhvc2UgdXBkYXRlcyBhdmFpbGFibGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5UaGVyZSBpcyBhbm90aGVyIGNvbnRlbnQgcmVwb3NpdG9yeSBwcm9ibGVtIGFuZCB0aGF0 IGlzIHRoZSBGZWRlcmF0ZWQgQ29udGVudCBEaXN0cmlidXRpb24uICZuYnNwO0lmIHlvdSB0aGlu ayBnbG9iYWwgRE5TIHlvdSBoYXZlIGEgZ2VuZXJhbCBmcmFtZSBvZiByZWZlcmVuY2UuICZuYnNw O1RoZSBndWlkYW5jZSBhdXRob3JzIG5lZWQgdG8gYmUgYWJsZSB0byBwdWJsaXNoIGNvbnRlbnQg aW4gYW4gYXV0aG9yaXRhdGl2ZSBtYW5uZXIgc28gdGhlaXIgY29udGVudCBpcyB1cGRhdGVkIGlu IGEgdGltZWx5IGZhc2hpb24uICZuYnNwO1RoaXMgaXMgYSBtdWNoIGhhcmRlciBwcm9ibGVtIHRv IHNvbHZlIGlmIHRoZXJlIGlzIG5vIGxvY2FsIG9yZ2FuaXphdGlvbmFsIGluZnJhc3RydWN0dXJl IHRvIHN1cHBvcnQgaXQuIDspPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TbyBoZXJlIGlzIHdo YXQgSSBhbSB0aGlua2luZ+KApiAmbmJzcDtXZSBzaG91bGQgY29uc2lkZXIgYWRkcmVzc2luZyB0 aGVzZSBhcyB0d28gc2VwYXJhdGUgYnV0IGludGVncmF0ZWQgZWZmb3J0cy4gJm5ic3A7SSBiZWxp ZXZlIHRoZSBPcmdhbml6YXRpb25hbCBDb250ZW50IFJlcG9zaXRvcnkgaXMgdGhlIG1vcmUgY3Jp dGljYWwgcGllY2UgdGhhdCBpcyBhY3R1YWxseSBlYXNpZXIgdG8gYWRkcmVzcy4gJm5ic3A7VGhl IEZlZGVyYXRlZCBDb250ZW50IERpc3RyaWJ1dGlvbiBzaG91bGQgYmUgYSBzdWJzZXF1ZW50IGVm Zm9ydCBpbnRlZ3JhdGluZyAvIGF1Z21lbnRpbmcgdGhlIE9yZ2FuaXphdGlvbmFsIHJlcG9zaXRv cnkgc3BlY2lmaWNhdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk1pa2UsIHRv IHlvdXIgcG9pbnQgdGhhdCB3ZSBuZWVkIHNvbWVvbmUgdG8gYnVpbGQgb25lIGZpcnN04oCmIFRo YXQgaGFzIGhhcHBlbmVkIGFscmVhZHkuICZuYnNwO0kgaGF2ZSBvbmUgYXMgZG8gb3RoZXIgdmVu ZG9ycyBidXQgd2hhdCB3ZSBkb27igJl0IGhhdmUgaXMgdGhlIGFjY2VzcyBzcGVjaWZpY2F0aW9u LiAmbmJzcDtPdXJzIGFyZSBmb2N1c2VkIG9uIG91ciBzcGVjaWZpYyBwcm9kdWN0IG5lZWRzLiAm bmJzcDtBZGRpdGlvbmFsbHkgdGhlcmUgaXMgYSBjb21wYW55IHRoYXQgaGFzIGRldmVsb3BlZCBh IGNvbW1lcmNpYWwgU0NBUCBjb250ZW50IHJlcG9zaXRvcnkgdGhhdCB3aWxsIGJlIGFubm91bmNl ZCBsYXRlciB0aGlzIG1vbnRoLiBJIHdvbid0IHN0ZWFsIHRoZWlyIHRodW5kZXIgYnV0IEkgd2Fz IHJlY2VudGx5IGdpdmVuIGEgc25lYWsgcGVlayBhdCBpdCBhbmQgSSBtdXN0IGFkbWl0IEkgd2Fz IHZlcnkgaW1wcmVzc2VkLiAmbmJzcDtBZ2FpbiwgdG8geW91ciBwb2ludCwgaXQgaGFzIGJlZW4g ZG9uZS4gV2hhdCBpcyBuZWVkZWQgdG8gYWRkcmVzcyB0aGUgaW5pdGlhbCBvcGVyYXRpb25hbCBw cm9ibGVtIGlzIHRvIGRldmVsb3AgYSBzcGVjaWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBjb25z aXN0ZW50IG1lYW5zIGZvciBhbGwgU0NBUCBwcm9kdWN0cyB0byByZXRyaWV2ZSB0aGUgYXBwcm9w cmlhdGUgY29udGVudCBhcyBjb25maWd1cmVkIGFuZCBtYW5hZ2VkIGJ1dCB0aGUgc2l0ZS4gJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UTyBUSEFUIEVOROKApi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPkkgYW0gcmVxdWVzdGluZyBwYXJ0aWNpcGF0aW9uIGZyb20gdGhvc2UgaW4g dGhlIGNvbW11bml0eSB0aGF0IHNlZSB0aGUgbmVlZCBhbmQgd2FudCB0byBwdXQgaW4gdGhlIHdv cmsgdG8gbWFrZSB0aGlzIHNwZWNpZmljYXRpb24gaGFwcGVuLiAmbmJzcDtJIGhhdmUgdGFsa2Vk IHRvIGEgY291cGxlIG9mIHlvdSBidXQgSSBkbyBub3Qgd2FudCB0byBhc3N1bWUgeW91ciBwYXJ0 aWNpcGF0aW9uLiAmbmJzcDtJZiB5b3UgYXJlIGludGVyZXN0ZWQgcGxlYXNlIGNvbnRhY3QgbWUg c28gd2UgY2FuIGdldCB0aGlzIHN0YXJ0ZWQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjA2QTcxJz5LZW50 IExhbmRmaWVsZDwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPjxicj48c3BhbiBj bGFzcz1hcHBsZS1zdHlsZS1zcGFuPkRpcmVjdG9yIENvbnRlbnQgU3RyYXRlZ3ksIEFyY2hpdGVj dHVyZSBhbmQgU3RhbmRhcmRzPC9zcGFuPjxicj48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnk8 L3NwYW4+PC9zdHJvbmc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+NTAwMCBIZWFk cXVhcnRlcnMgRHIuPC9zcGFuPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPlBsYW5v LCBUZXhhcyA3NTAyNDwvc3Bhbj48YnI+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+ RGlyZWN0OiArMS45NzIuOTYzLjcwOTYmbmJzcDs8L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxl LXN0eWxlLXNwYW4+TW9iaWxlOiArMS44MTcuNjM3LjgwMjY8L3NwYW4+PGJyPjxzdHJvbmc+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5XZWI6Jm5ic3A7PC9z cGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PGEgaHJlZj0iaHR0cDov L3d3dy5tY2FmZWUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5tY2FmZWUuY29tPC9hPjwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZsdDtLaW5uZXkmZ3Q7 LCBNaWNoYWVsIEEgJmx0OzxhIGhyZWY9Im1haWx0bzptLmtpbm5lQHJhZGl1bS5uY3NjLm1pbCIg dGFyZ2V0PSJfYmxhbmsiPm0ua2lubmVAcmFkaXVtLm5jc2MubWlsPC9hPiZndDs8YnI+PGI+VG86 IDwvYj5EYXZpZCBXYWx0ZXJtaXJlICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVybWly ZUBuaXN0LmdvdiIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8L2E+ Jmd0OywgU0NBUC1ERVYgJmx0OzxhIGhyZWY9Im1haWx0bzpTQ0FQLURFVkBuaXN0LmdvdiIgdGFy Z2V0PSJfYmxhbmsiPlNDQVAtREVWQG5pc3QuZ292PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzpzYWNtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2FjbUBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Fj bUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6IDwvYj5SZTogW3NhY21dIFtPVkFMLURF VkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlzOiBTdW1tZXIg MjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCcgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz5EYXZlLDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+SSBoYXZlIG5vIHByb2JsZW0gd2l0aCB3ZWJpbmFycywgSSBkbyB3YW50IHRvIGtlZXAgZGV2 ZWxvcGVyIGRheXMgYWN0aW9uYWJsZSBhbmQgdXNlIGl0IHRvIG1ha2UgZGVjaXNpb25zLCBhbmQg dm90ZSBhbmQgYWNjb21wbGlzaCB0aGluZ3MgZ29vZCBvciBiYWQuJm5ic3A7IEkgZG8gbm90IHdh bnQgdGhpcyB0byBiZSBhbiBpbmZvcm1hdGlvbmFsIGJyaWVmaW5nIGNvbmZlcmVuY2UuPC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGFua3MgZm9yIHRoZSBs aW5rcy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSBzdGlsbCB0 aGluayB0aGF0IGFueSBzcGVjaWZpY2F0aW9uIGZvciBhIHJlcG9zaXRvcnkgaXMgd2lzaGZ1bCB0 aGlua2luZyB1bnRpbCBzb21lb25lIGJ1aWxkcyBvbmUgYW5kIGxlYXJucyB0aGUgbGVzc29ucyBp dCB3aWxsIGp1c3QgYmUgYW5vdGhlciB3aGl0ZXBhcGVyIHNwZWMuICZuYnNwO0kgYmVsaWV2ZSB0 aGUgRG9EIG5lZWRzIHRvIGluY29ycG9yYXRlIGEgbWV0YWRhdGEgcmVwb3NpdG9yeSBhcyBwYXJ0 IG9mIGl0IGFuZCBvdGhlciBjdXN0b21pemF0aW9ucyB0aGF0IG1heSBub3QgYmUgdXNlZnVsIGZv ciBldmVyeW9uZS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PldlIG5lZWQgdG8gdGFsayBtb3Jl4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPi1NaWtlJm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+IFdhbHRlcm1pcmUsIERhdmlkIEEuIFs8YSBocmVmPSJtYWlsdG86ZGF2aWQu d2FsdGVybWlyZUBuaXN0LmdvdiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpkYXZpZC53YWx0ZXJt aXJlQG5pc3QuZ292PC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMDgsIDIwMTIg MTA6NDQgQU08YnI+PGI+VG86PC9iPiBLaW5uZXksIE1pY2hhZWwgQTsgU0NBUC1ERVY7IDxhIGhy ZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2FjbUBpZXRmLm9yZzwv YT48YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2VjdXJpdHkg QXV0b21hdGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9y ZCwgTUE8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk1pa2UsPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPldoYXQgYWJvdXQgaGF2aW5nIHdlYmluYXJzIGluLXBsYWNlIG9mIHRo ZSAzMCBtaW51dGUgYnJpZWZzPzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz5SZWdhcmRpbmcgY29udGVudCBtYW5hZ2VtZW50LCB3ZSBhcmUgYnVpbGRpbmcgdGhlIHBy b3RvdHlwZSBjb250ZW50IHJlcG9zaXRvcnkgZm9yIHVzZSBpbiBhIHByb2R1Y3Rpb24gZW52aXJv bm1lbnQuJm5ic3A7IEFzIGFuIG9wZW4gc291cmNlIHByb2plY3QsIGl0IHdpbGwgYmUgZnJlZSBm b3IgdXNlIGJ5IGFueW9uZSBpbnRlcmVzdGVkLiZuYnNwOyBNeSB0aGlua2luZyBpcyB0aGF0IHRo aXMgcHJvamVjdCBjYW4gYnJpZGdlIHRoZSBnYXAgdW50aWwgY29tbWVyY2lhbCBzb2x1dGlvbnMg YXJlIGF2YWlsYWJsZSB0byBhdWdtZW50IGl0LiZuYnNwOyBUaGlzIGlzIGEgc2ltaWxhciBwYXRo IHRoYXQgd2FzIGZvbGxvd2VkIHdpdGggRE5TIChiaW5kKSBhbmQgSFRUUCAoYXBhY2hlKS4mbmJz cDsgV2hlbiBpdCBpcyByZWFkeSBmb3IgdXNlLCBJIGFtIGhvcGluZyB0byB1c2UgaXQgdG8gaG9z dCBVU0dDQiBjb250ZW50LiZuYnNwOyBZb3Ugd291bGQgYmUgd2VsY29tZSB0byB1c2UgaXQgZm9y IHlvdXIgbmVlZHMuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkl0 IGlzIGdvb2QgdGhhdCBPQ0lMIGlzIG1vdmluZyBmb3J3YXJkLiZuYnNwOyBUaGlzIGlzIGFuIGlt cG9ydGFudCBwaWVjZSBvZiBzdXBwb3J0aW5nIHJpc2sgbWFuYWdlbWVudCBhbmQgYXNwZWN0cyBv ZiBjb250aW51b3VzIG1vbml0b3JpbmcuJm5ic3A7IEkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSBz b21lIGRpc2N1c3Npb24gb24gT0NJTCBhdCBEZXZlbG9wZXIgRGF5cy4mbmJzcDsgV2l0aCB0aGUg cHJvcG9zYWxzIHdlIHdpbGwgbGlrZWx5IGhhdmUgYSBzZW5zZSBvZiB3aGF0IG5lZWRzIHRvIGJl IGRpc2N1c3NlZCBhbmQgd2hhdCB3ZSBjYW4gYWNoaWV2ZSBjb25zZW5zdXMgb24gb3V0c2lkZSB0 aGUgbWVldGluZy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UmVt ZWRpYXRpb24gaXMgYSB0b3BpYyBuZWFyIGFuZCBkZWFyIHRvIG15IGhlYXJ0LiZuYnNwOyBJIHRv byB3b3VsZCBsaWtlIHRvIHNlZSBpdCBtb3ZlIGZvcndhcmQuPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPldlIGp1c3QgcHVibGlzaGVkIHRoZSBkcmFmdCBBU1Igc3Bl Y2lmaWNhdGlvbiBmb3IgcHVibGljIGNvbW1lbnQuJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBz dXBwb3J0cyBlbnRlcnByaXNlIGFnZ3JlZ2F0ZSByZXBvcnRpbmcgd2hpY2ggZ3JlYXRseSByZWR1 Y2VzIHRoZSBkYXRhIHZvbHVtZXMgbmVlZGVkIHZlcnNlcyBkZXRhaWxlZCBob3N0LWJhc2VkIHJl cG9ydHMuIFRoaXMgc3BlY2lmaWNhdGlvbiBoYXMgYmVlbiBkZXNpZ25lZCBhcyBhIG1vcmUgcm9i dXN0IHJlcGxhY2VtZW50IGZvciBMQVNSLiZuYnNwOyBJdCBjYW4gYmUgdXNlZCBpbiBjb250aW51 b3VzIG1vbml0b3JpbmcgYXBwbGljYXRpb25zIHRvIHN1cHBvcnQgYWdncmVnYXRlIGRhdGEgcmVw b3J0aW5nIG5lZWRzIChlLmcuIEZJU01BIHJlcG9ydGluZywgJm5ic3A7Q3liZXJTY29wZSkuPC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhlcmUgYXJlIHRoZSBsaW5r czo8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PGEgaHJlZj0iaHR0 cDovL2NzcmMubmlzdC5nb3YvcHVibGljYXRpb25zL1B1YnNEcmFmdHMuaHRtbCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9QdWJzRHJhZnRzLmh0bWw8 L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48YSBocmVm PSJodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMvUHVic05JU1RJUnMuaHRtbCNOSVNU LUlSLTc4NDgiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlv bnMvUHVic05JU1RJUnMuaHRtbCNOSVNULUlSLTc4NDg8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoZSBwcmltYXJ5IHJlYXNvbiB3ZSBoYXZlIHN1Z2dlc3Rl ZCB3YWl0aW5nIG9uIFhDQ0RGIGlzIG5vdCB0aGUgaW50ZXJuYXRpb25hbGl6YXRpb24gaXNzdWUu IE1hbnkgdmVuZG9ycyBoYXZlIGNvbW1lbnRlZCB0aGF0IHRoZXkgYXJlIHN0aWxsIHdvcmtpbmcg b24gaW1wbGVtZW50aW5nIHRoZSBYQ0NERiAxLjIuMSBzcGVjaWZpY2F0aW9uLiBXZSB3aWxsIGJl IGluIGEgYmV0dGVyIHBsYWNlIGluIGEgZmV3IG1vbnRocyBvbmNlIG1vcmUgZGV2ZWxvcG1lbnQg YXJvdW5kIFhDQ0RGIGhhcyBvY2N1cnJlZC4mbmJzcDsgQXMgd2UgY29uc2lkZXIgY2hhbmdlcyB0 byB0aGUgU0NBUCBzdGFjayB0byBhZGRyZXNzIE9DSUwgYW5kIG90aGVyIGlzc3Vlcywgd2Ugd2ls bCBpZGVudGlmeSBhcmVhcyB0aGF0IG5lZWQgaW1wcm92ZW1lbnQgaW4gWENDREYuJm5ic3A7IFRo ZXNlIGFyZSBnb29kIGFuZCBuZWNlc3NhcnkgZGlzY3Vzc2lvbnMgdG8gaGF2ZSBub3csIGJ1dCB3 ZSBoYXZlIGEgZ29vZCBkZWFsIG9mIHdvcmsgdG8gZG8gYmVmb3JlIHdlIGFyZSByZWFkeSB0byBv cGVuIHVwIFhDQ0RGLiZuYnNwOyBNeSBzdWdnZXN0aW9uIGlzIHRvIHdvcmsgb24gdGhlc2UgcmVs YXRlZCBhcmVhcyBhbmQgdGhlbiB3b3JrIHVwIGNoYW5nZSBwcm9wb3NhbHMgZm9yIFhDQ0RGIGFz IG5lZWRlZC4mbmJzcDsgQnkgdGhhdCB0aW1lIHdlIHNob3VsZCBiZSByZWFkeSB0byB3b3JrIG9u IGEgbmV3IHJldmlzaW9uIG9mIFhDQ0RGLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5JIGFtIGFsc28gbG9va2luZyBmb3J3YXJkIHRvIHRoZSBkaXNjdXNzaW9ucyBh dCB0aGUgY29uZmVyZW5jZS4mbmJzcDsgSXQgaGFzIGJlZW4gdG9vIGxvbmcuPC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+U2luY2VyZWx5LDwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+RGF2ZTwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IEtpbm5leSwgTWljaGFlbCBBIFs8 YSBocmVmPSJtYWlsdG86bS5raW5uZUByYWRpdW0ubmNzYy5taWwiIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86bS5raW5uZUByYWRpdW0ubmNzYy5taWw8L2E+XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNk YXksIE1heSAwOCwgMjAxMiA3OjA5IEFNPGJyPjxiPlRvOjwvYj4gU0NBUC1ERVY8YnI+PGI+Q2M6 PC9iPiBXYWx0ZXJtaXJlLCBEYXZpZCBBLjxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtPVkFMLURF VkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlzOiBTdW1tZXIg MjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+S2VudCw8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SXTigJlzIGdvb2QgdG8gcmVh ZCB5b3VyIHRob3VnaHRzLCBhbmQgYSByZWFsaXN0aWMgYWN0aW9uYWJsZSBhcHByb2FjaCBpcyBp bmRlZWQgbmVlZGVkLiAmbmJzcDtTaW5jZSBhbGwgdGhlIGFjdGl2aXR5IGhhc27igJl0IGJlZW4g b24gdGhlIGxpc3RzIGEgYnJpZWYgMcW9MiBob3VyIHJlY2FwIG1heSBiZSBpbiBvcmRlciB0byBi cmluZyBldmVyeW9uZSB1cCB0byBzcGVlZCBzaW5jZSB0aGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBh Y3Rpdml0eSBvbiBDUEUvU1dJRCwgT0NJbCwgTUFFQy9DeWJPWCBDRUUgYW5kIG90aGVycy48L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2UgY291bGQgd3JpdGUgYSBj b250ZW50IHJlcG9zaXRvcnkgc3BlY2lmaWNhdGlvbiwgYnV0IHdpdGhvdXQgc29tZW9uZSB3aWxs aW5nIHRvIHN0YW5kIG9uZSB1cCBpdCB3aWxsIGJlIGFzIHZhbHVhYmxlIGFzIHRoZSBDQ1NTIHNw ZWNpZmljYXRpb24gaXMgdG9kYXkuICZuYnNwO0nigJl2ZSBiZWVuIHRyeWluZyBmb3IgdHdvIHll YXJzIHRvIGdldCBteSBtYW5hZ2VtZW50IHRvIGdldCBhIGNvb3JkaW5hdGVkIGVmZm9ydCB0b2dl dGhlciBmb3IgdGhlIERvRCB0byBzdGFuZCB1cCBhIHJlcG9zaXRvcnksIGl0IGlzIGEgdG91Z2gg cHJvYmxlbSBhbmQgd2lsbCByZXF1aXJlIGZ1bmRpbmcgd2l0aCBhIHRhaWwsIEnigJltIG5vdCBz dXJlIGEgc3BlY2lmaWNhdGlvbiB3aWxsIHNvbHZlIHRoYXQgcHJvYmxlbS48L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2UgKERvRCkgaGF2ZSBiZWVuIHB1dHRpbmcg YSBsb3Qgb2YgZWZmb3J0IGludG8gT0NJTCBvdmVyIHRoZSBsYXN0IHllYXIgdHJ5aW5nIHRvIG1h a2UgaXQgdXNlZnVsIGluIGFuIGVudGVycHJpc2UgZW52aXJvbm1lbnQgYW5kIHdpbGwgYmUgcG9z dGluZyBvdXIgaWRlYXMgdG8gdGhlIGxpc3QgYmVmb3JlIGRldmVsb3BlciBkYXlzIGl0IHNob3Vs ZCBoYXZlIGFscmVhZHkgc3RhcnRlZCwgd2UgbmVlZCB0byBnZXQgY29uc2Vuc3VzIGFuZCBhIHZv dGUgb24gaG93IHRoZSBjb21tdW5pdHkgd2lzaGVzIHRvIHByb2NlZWQuPC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlJlbWVkaWF0aW9uIGlzIHN0YWxsZWQgYnV0IEni gJltIG1ha2luZyBldmVyeSBlZmZvcnQgdG8gZ2V0IGl0IGtpY2sgc3RhcnRlZCBmcm9tIG91ciBw ZXJzcGVjdGl2ZS4gSSBob3BlIHRvIGFzc2lzdCBpbiBnZXR0aW5nIHRoZSBkcmFmdCBFUkkgZmlu aXNoZWQgdGhpcyB5ZWFyLiAmbmJzcDtXZSBhcmUgd3JpdGluZyBzb21lIG5ldyBTVElHIGNvbnRl bnQgYW5kIGludGVuZCB0byB1c2VkIHRoZSBkcmFmdCBDUkUgc3BlY2lmaWNhdGlvbiB0byBpbnNl cnQgQ1JFIGludG8gdGhlIGNvbnRlbnQgc28gd2UgKERvRCkgY2FuIGRvIHNvbWUgYXV0b21hdGlj IGNvbmZpZ3VyYXRpb24gZml4ZXMsIHBhcnQgb2YgYSBzZWxmIGhlYWxpbmcgbmV0d29yayBjb25j ZXB0LiBJdCBpcyBqdXN0IGEgc3RhcnQgYnV0IHRoZSBiZXN0IHdlIGNhbiBkbyBhdCB0aGlzIHBv aW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5FbnRlcnByaXNl IHJlcG9ydGluZyBpcyBhbiBpbnRlcmVzdGluZyBzdWJqZWN0LCBzaW5jZSBYTUwgYWRkcyBzaXpl IHRvIGFuZCBjb250ZW50IHRvIHJvbGwgdXAgcmVwb3J0aW5nLCBpbiBhbnkgZW50ZXJwcmlzZSBv ZiBzaXplIHRoZSBwcm9ibGVtIGdldHMgZ3JlYXRlciwgSSBsb29rIGZvcndhcmQgdG8geW91ciB0 aG91Z2h0cyBvbiB0aGF0IHN1YmplY3QuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPkkgYW0gY29uY2VybmVkIHRoYXQgdGhlIGludGVybmF0aW9uYWxpemF0aW9uIGVm Zm9ydHMgYXJlIGRldHJhY3RpbmcgZnJvbSBlZmZvcnRzIHRvIG1lZXQgdXNlIGNhc2VzLCB3ZSBo YXZlIHNvbWUgdGhpbmdzIHdlIHdvdWxkIGxpa2UgY2hhbmdlZCBpbiBYQ0NERiB0byBzdXBwb3J0 IG91ciBPQ0lsIHVzZSBjYXNlIGFuZCBJIGhhdmUgYmVlbiB0b2xkIHRoYXQgSSBuZWVkIHRvIHdh aXQuIEkgZGlkbuKAmXQgdGhpbmsgdGhhdCBhIG1vdmUgdG8gaW50ZXJuYXRpb25hbGl6YXRpb24g c2hvdWxkIGltcGVkZSBlZmZvcnRzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHVzZSBjYXNlcy48L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSBsb29rIGZvcndhcmQgdG8g dGFsa2luZyB3aXRoIHlvdSBhdCB0aGUgY29uZmVyZW5jZS48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz52L3I8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk1pa2UgS2lubmV5 PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByb2plY3QgRGlyZWN0b3I8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q29tcHV0ZXIgTmV0d29yayBE ZWZlbnNlIFJlc2VhcmNoIGFuZCBUZWNobm9sb2d5IChDTkQgUiZhbXA7VCkgT2ZmaWNlPC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjk4MDAgU2F2YWdlIFJvYWQgU3RlIDY3 Njc8YnI+RnQgTWVhZGUsIE1EIDIwNzU1LTY3Njc8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QnPlBob25lOiA0MTAtODU0LTQ0MjI8YnI+TlNUUzog OTY4LTg4ODY8YnI+RmF4IDQxMC04NTQtNDY4MTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48YSBocmVmPSJtYWlsdG86TS5raW5uZUByYWRpdW0ubmNzYy5taWwiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6IzY2MDAwMCc+bWFraW5uMkBuc2EuZ292PC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48YSBocmVmPSJt YWlsdG86c2NhcC1kZXZAbmlzdC5nb3YiIHRhcmdldD0iX2JsYW5rIj5zY2FwLWRldkBuaXN0Lmdv djwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86c2NhcC1kZXZAbmlzdC5nb3ZdIiB0YXJnZXQ9 Il9ibGFuayI+W21haWx0bzpzY2FwLWRldkBuaXN0Lmdvdl08L2E+IDxiPk9uIEJlaGFsZiBPZiA8 L2I+V2FsdGVybWlyZSwgRGF2aWQgQS48YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDA3LCAy MDEyIDc6MDkgUE08YnI+PGI+VG86PC9iPiBNdWx0aXBsZSByZWNpcGllbnRzIG9mIGxpc3Q8YnI+ PGI+U3ViamVjdDo8L2I+IFJFOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2VjdXJpdHkgQXV0b21h dGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwgTUE8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPktlbnQsPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPkkgbGlrZSB3aGF0IHlvdSBhcmUgc2F5aW5nIGhlcmUuJm5ic3A7IFdlIGFyZSBh bHNvIGluIHN1cHBvcnQgb2YgdGhpcyB0eXBlIG9mIGFwcHJvYWNoLiZuYnNwOyBXZSB3b3VsZCBs aWtlIHRvIHNlZSBzb21lIGNvbW11bml0eSBkaXNjdXNzaW9uIGFyb3VuZCB3aGF0IGFyZSB0aGUg a2V5IGFyZWFzL3ByaW9yaXRpZXMgdGhhdCB0aGUgY29tbXVuaXR5IHdvdWxkIGxpa2UgdG8gc2Vl IGRpc2N1c3NlZCBhdCBEZXYgRGF5cy4mbmJzcDsgWW91ciB0b3BpY3MgYmVsb3cgbG9vayBsaWtl IGEgZ29vZCBzdGFydC4gVGhlIFNBQ00gbGlzdCBtaWdodCBiZSBhIGJldHRlciB2ZW51ZSB0aGFu IHRoZSBPVkFMIGxpc3QgZm9yIHRoaXMgZGlzY3Vzc2lvbi4mbmJzcDsgRm9yIGVhY2ggYXJlYSB3 ZSBzaG91bGQgZm9jdXMgdGhlIGRpc2N1c3Npb24gYXJvdW5kIGRldmVsb3Bpbmcgb2JqZWN0aXZl cyBmb3IgZWFjaCBzZXNzaW9uLiZuYnNwOyBUaGUgc2Vzc2lvbnMgY2FuIGJlIHRpbWUgYm94ZWQg YmFzZWQgb24gd2hhdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUgYW1vdW50IG9mIHRpbWUgdG8gYWNj b21wbGlzaCBlYWNoIG9iamVjdGl2ZS4mbmJzcDsgRm9yIGV4YW1wbGUgaWYgY29udGludW91cyBt b25pdG9yaW5nIGlzIGEgcHJpb3JpdHkgYW5kIGNvbGxlY3RpdmVseSBpdCB0YWtlcyAzIGRheXMg dG8gd29yayB0aHJvdWdoIGFsbCB0aGUgb2JqZWN0aXZlcywgSSBzZWUgbm8gcHJvYmxlbSB3aXRo IHRoYXQuJm5ic3A7IFdlIGNhbiBhbHNvIGtlZXAgYSBmZXcgc2Vzc2lvbnMg4oCcb24gZGVja+KA nSBpZiBhbGwgdGhlIG9iamVjdGl2ZXMgYXJlIHJlYWNoZWQgYW5kIHdlIGNvbXBsZXRlIGFsbCB0 aGUgc2NoZWR1bGVkIHNlc3Npb25zIGVhcmx5Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz5UaG91Z2h0cz88L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz5TaW5jZXJlbHksPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5EYXZpZCBXYWx0ZXJtaXJlPC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5TQ0FQIEFyY2hpdGVj dDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+TmF0aW9uYWwg SW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neTwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+KDMwMSkgOTc1LTMzOTA8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVy bWlyZUBuaXN0LmdvdiIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz48YSBocmVmPSJtYWlsdG86c2NhcC1kZXZAbmlzdC5nb3YiIHRhcmdl dD0iX2JsYW5rIj5zY2FwLWRldkBuaXN0LmdvdjwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86 c2NhcC1kZXZAbmlzdC5nb3ZdIiB0YXJnZXQ9Il9ibGFuayI+W21haWx0bzpzY2FwLWRldkBuaXN0 Lmdvdl08L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOktlbnRfTGFuZGZp ZWxkQG1jYWZlZS5jb20iIHRhcmdldD0iX2JsYW5rIj5LZW50X0xhbmRmaWVsZEBtY2FmZWUuY29t PC9hPjxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMDcsIDIwMTIgNDoyNSBQTTxicj48Yj5U bzo8L2I+IFNDQVAtREVWPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09WQUwtREVWRUxPUEVSLUxJ U1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1J VFJFIGluIEJlZGZvcmQsIE1BPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5B bGwsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkkg d291bGQgbGlrZSB0byBkaXNjdXNzIHRoZSBmb3JtYXQgZm9yIHRoZSBTQ0FQIERldmVsb3BlciBE YXlzIHRoYXQgc2VlbXMgdG8gYmUgbGlzdGVkIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JIHNlZSB0aGlzIGFwcGVhcnMgdG8gZm9sbG93 IGEgcGF0aCB3ZSBoYXZlIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCBhcyB0aGUgd2F5IG5vdCB0byBo b2xkIGEgRGV2IERheXMgZXZlbnQuICZuYnNwO1dlIGhhdmUgYmVlbiB0cnlpbmcgdG8gZ2V0IGF3 YXkgZnJvbSAnRGVhdGggYnkgUG93ZXJwb2ludCcgYW5kIGJhY2sgdG8gdGhlIHR5cGUgb2YgZXZl bnQgd2UgaGVsZCB5ZWFycyBhZ28gd2hlbiB3ZSB3ZXJlIGhpZ2hseSBwcm9kdWN0aXZlLiAmbmJz cDtJbiB0aGUgcGFzdCB3ZSBoYWQgYSB0b3BpYyB0byBiZSBkaXNjdXNzZWQgYW5kIGEgdGltZSBi b3ggdG8gd29yayB3aXRoaW4uICZuYnNwO1RoYXQgYWxsb3dlZCB1cyB0byBoYXZlIHZlcnkgYWN0 aXZlIGJyYWluc3Rvcm1pbmcgc2Vzc2lvbnMgaW4gYSBoaWdoIGJhbmR3aWR0aCBlbnZpcm9ubWVu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QXQg cGFzdCBTdW1tZXIgZXZlbnRzIHdlIGhhdmUgZ290IGludG8gYSBwYXR0ZXJuIG9mIGxvdHMgb2Yg cG93ZXJwb2ludCwgbG90cyBvZiBzdGF0dXMgb2YgdGhlIGVmZm9ydHMgYW5kIHZlcnkgbGl0dGxl IGRpc2N1c3Npb24gYWJvdXQgdGhpbmdzIHRoYXQgbmVlZCBhY3RpdmUgZGlzY3Vzc2lvbnMuICZu YnNwO1dlIG5lZWQgdG8ga2VlcCBtb3ZpbmcgZm9yd2FyZCBhbmQgbWFraW5nIHByb2dyZXNzIGFz IGFuIGVmZm9ydC4gV2UgY2FuIGdldCBzdGF0dXMgZnJvbSB2YXJpb3VzIHBsYWNlcyBzdWNoIGFz IHRoZSBsaXN0cywgYSBwcmVzZW50YXRpb24gYmVpbmcgc2VudCBvdXQgaW4gYWR2YW5jZSwgYSB3 ZWJpbmFyIGlmIGl0IGlzIGZlbHQgdGhlcmUgd2lsbCBiZSBxdWVzdGlvbnMgYW5kIGFuc3dlcnMg ZnJvbSB0aG9zZSB0aGF0IGFyZSBuZXcgdG8gdGhlIGVmZm9ydHMuICZuYnNwO1dlIGhhdmUgYSBs aW1pdGVkIGFtb3VudCBvZiB0aW1lIGFuZCBhbGwgd2hvIGFyZSBhdHRlbmRpbmcgYXJlIGludmVz dGluZyBhIGdyZWF0IGRlYWwgb2YgdGltZSBhbmQgbW9uZXkgdG8gYmUgdGhlcmUuICZuYnNwO1dl IHNob3VsZCBub3QgJm5ic3A7YmUgc3BlbmRpbmcgYSBncmVhdCBkZWFsIG9mIHRpbWUgcmVlZHVj YXRpbmcgZXZlcnlvbmUgd2hlbiB3ZSBjb3VsZCBiZSBmb2N1c2VkIG9uIGFkdmFuY2luZyBuZWVk ZWQgZWZmb3J0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+VGhlIHR5cGUgb2YgYXBwcm9hY2ggdG8gYSBEZXYgRGF5cyBldmVudCB3YXMgZGlzY3Vz c2VkIGF0IHRoZSBsYXN0IFN1bW1lciBEZXYgRGF5cy4gJm5ic3A7SSBoYXZlIHNlZW4gdGhlIGZv bGxvd2luZyB3b3JrIHF1aXRlIHdlbGwgaW4gb3RoZXIgZWZmb3J0cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PG9sIHN0YXJ0PTEgdHlwZT0xPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2NvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz5QcmVzZW50YXRpb25zIGFyZSBzZW50IG91 dCB0byB0aGUgYXR0ZW5kZWVzIGFuZCB0aGUgbGlzdHMgYSB3ZWVrIGluIGFkdmFuY2UuPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOmJsYWNrO21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm8zJz5TdGF0dXMgZm9yIGFueSBlZmZvcnQgaXMgbGltaXRlZCB0byAzMCBtaW51dGVz PG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOmJsYWNrO21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwxIGxldmVsMSBsZm8zJz5Gb2N1c2VkIGJyYWluc3Rvcm1pbmcgdGltZSBzaG91bGQgYmUgZXN0 YWJsaXNoZWQgZm9yIGNlcnRhaW4gYXJlYXMgdGhhdCBuZWVkIHJlYWwgd29yayBieSB0aGUgY29t bXVuaXR5PG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOmJs YWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwxIGxldmVsMSBsZm8zJz5FZmZvcnRzIHRvIGJlIGRpc2N1c3NlZCBzaG91bGQgYmUg YmFzZWQgb24gbmVlZHMgb2YgdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gc3BhY2UgdG8gbW92ZSBl eGlzdGluZyBlZmZvcnRzIHRvIGNvbXBsZXRpb24uPG86cD48L286cD48L2xpPjwvb2w+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkZvciBleGFtcGxl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5Db250 aW51b3VzIG1vbml0b3JpbmcgaXMgYSBtYWpvciBkaXJlY3Rpb24gdGhlIGVmZm9ydHMgYXJlIGJl Y29taW5nIGludm9sdmVkIHdpdGguIFRoZXJlIGFyZSBnb2luZyB0byBiZSB0aGluZ3Mgd2UgbmVl ZCB0byBkbyBhcyBhIHNlY3VyaXR5IGF1dG9tYXRpb24gY29tbXVuaXR5IHRvIGJlIGFibGUgdG8g YWNjb21wbGlzaCB3aGF0IGlzIGxpc3RlZCBpbiB0aGUgQ0FFU0FSUyBGRS4gJm5ic3A7VGhlcmUg YXJlIGludGVyZmFjZXMgdGhhdCBuZWVkIHRvIGJlIHdvcmtlZCBhbmQgZXN0YWJsaXNoZWQuICZu YnNwO1RoYXQgaXMgb25lIGFyZWEgdGhhdCBpcyBub3QgbGlzdGVkIGJlbG93LiAmbmJzcDtDTSB3 aWxsIGhhdmUgYSBtYWpvciBpbXBhY3Qgb24gYWxsIG9mIHVzIGluIHRoZSBuZXh0IGNvdXBsZSB5 ZWFycyBhbmQgaXQgaXMgYmVpbmcgaWdub3JlZC4gJm5ic3A7V2UgY2FuJ3Qga2VlcCB0cnlpbmcg dG8gc29sdmUgd2hhdCBoYXMgYWxyZWFkeSBiZWVuIHNvbHZlZC4gJm5ic3A7V2UgbmVlZCB0byBh ZGRyZXNzIHRoZSBuZWVkZWQgaW50ZXJmYWNlIGRldmVsb3BtZW50IG5vdy4gVGhpcyBpcyBhbiBl ZmZvcnQgdGhhdCBjb3VsZCB0YWtlIG5lYXJseSBhIHdob2xlIGRheSBieSBpdHNlbGYuPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk9wZXJhdGlvbmFs bHkgd2UgaGF2ZSBhIHJlYWwgbmVlZCB0byBiZSBhYmxlIHRvIGRlbGl2ZXIgU0NBUCBjb250ZW50 IGludGVybmFsbHkgd2l0aGluIGFuIG9yZ2FuaXphdGlvbi4gVG9kYXkgdGhlIFNDQVAgdmVuZG9y cyBjYW5ub3Qgc2hhcmUgYSBzaW5nbGUgbG9jYWwgc2l0ZSBzZWN1cml0eSBwb2xpY3kgKFhDQ0RG ICsgT1ZBTCArIENQRSAr4oCmKSB3aXRob3V0IHRoZSBzaXRlIHN0YWZmIGhhdmluZyB0byBnbyB0 byBlYWNoIG9mIHRoZSBpbmRpdmlkdWFsIHByb2R1Y3RzIGFuZCBmaWd1cmluZyBvdXQgaG93IHRv IGluamVjdCB0aGF0IG5ldyBvciB1cGRhdGVkIHBvbGljeSBpbnRvIHRoYXQgcHJvZHVjdHMgZGVs aXZlcnkgbWVjaGFuaXNtcy4gJm5ic3A7VGhhdCBpcyBsaW1pdGluZyBzaXRlcyBmcm9tIHdhbnRp bmcgdG8gYnV5IG11bHRpcGxlIGZvY3VzZWQgU0NBUCBwcm9kdWN0cyBzaW5jZSB0aGV5IGFyZSBz dWNoIGEgcGFpbiB0byBtYW5hZ2UgZnJvbSBhIGNvbnRlbnQgcGVyc3BlY3RpdmUuICZuYnNwO0l0 IGlzIGVhc2llciB0byBidXkgZnJvbSBvbmUgdmVuZG9yIHRoYXQgaGFzIGEgc2luZ2xlIG1lYW5z IGZvciBkaXN0cmlidXRpbmcgY29udGVudCB0aGFuIGl0IGlzIHRvIGRlYWwgd2l0aCB0aGUgbWFu YWdlbWVudCBpc3N1ZXMgdGhhdCBoYXZpbmcgbXVsdGlwbGUgU0NBUCBwcm9kdWN0cyBwcmVzZW50 cy4gJm5ic3A7V2UgbmVlZCB0byBoYXZlIGF0IGxlYXN0IGFuIGVudGlyZSAxLzIgYSBkYXkgb24g dGhlIGRldmVsb3BtZW50IG9mIGEgQ29udGVudCBSZXBvc2l0b3J5IHNwZWNpZmljYXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk9DSUwgaXMg YSBwb3NpdGl2ZSBhbmQgYSBuZWdhdGl2ZSBhdCB0aGUgc2FtZSB0aW1lLiBJdCBoYXMgcmVhbCB2 YWx1ZSB0aGF0IGlzIGJlaW5nIHVuZGVydXRpbGl6ZWQgYW5kIHVuZGVyIGltcGxlbWVudGVkIGJl Y2F1c2Ugb2YgdGhlIGxpbWl0YXRpb25zIG9mIGhvdyBpdCBhZGRyZXNzZXMgdXNlcyBpbiBhbiBl bnRlcnByaXNlIGVudmlyb25tZW50LiAmbmJzcDtQZW9wbGUgZG9uJ3QgbmVlZCBzZWN1cml0eSBh dXRvbWF0aW9uIHRvIGRvIHRoaW5ncyBvbi9mb3IgYSBzaW5nbGUgaG9zdC4gJm5ic3A7VGhleSBu ZWVkIHNlY3VyaXR5IGF1dG9tYXRpb24gdG8gZm9jdXMgb24gdGhlIGVudGVycHJpc2UgaXNzdWVz IHRoYXQgcmVkdWNlIHRoZWlyIGNvc3RzIGFuZCBpbXByb3ZlIHRoZWlyIGVmZmljaWVuY2llcy4g Jm5ic3A7T0NJTCBpcyBmYWlsaW5nIGluIHRoZSBlbnRlcnByaXNlIGFuZCB3ZSBhbGwgdW5kZXJz dGFuZCB0aGF0LiAmbmJzcDtXZSBuZWVkIHRvIGFkZHJlc3MgZGV2ZWxvcGluZyBhIGRlZmluaXRp dmUgc29sdXRpb24gZm9yIGluY29ycG9yYXRpbmcgT0NJTCBpbnRvIHRoZSBlbnRlcnByaXNlIGFu ZCB0aGF0IG1lYW5zIGludG8gdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zLiBTY2hlZHVsaW5n IGFuZCB0cmFja2luZyBhcmUga2V5IHRvIGl0J3Mgc3VjY2Vzcy4gJm5ic3A7V2UgbmVlZCB0byBt YWtlIHRoYXQgaGFwcGVuLiAmbmJzcDtUaGlzIHRvbyBuZWVkcyBhIGZvY3VzZWQgYnJhaW5zdG9y bWluZyB0aW1lIGJveCB0byBkaXNjdXNzIG9wdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkkgYW0gcmVhbGx5IGRpc2FwcG9pbnRlZCB0aGF0 IFJlbWVkaWF0aW9uIGlzIG5vdCBvbiB0aGUgbGlzdCBiZWxvd+KApiAmbmJzcDtZZXMsIGxhc3Qg U3VtbWVyIERldiBEYXlzLCB0aGUgdGltZSBzcGVudCBvbiBSZW1lZGlhdGlvbiB3YXMgd2FzdGVk IHRpbWUgYnV0IHRoYXQgZG9lcyBub3QgbWVhbiB3ZSBzaG91bGQgaWdub3JlIGl0IGFuZCBub3Qg dHJ5IHRvIG1ha2Ugc29tZSByZWFsIHByb2dyZXNzLiAmbmJzcDtBcyBmYXIgYXMgSSBhbSBjb25j ZXJuZWQgd2UgbmVlZCB0byByZWJvb3QgdGhlIHJlbWVkaWF0aW9uIGVmZm9ydC4gJm5ic3A7V2Ug Y2Fubm90IGtlZXAgYmVpbmcgdGhlIHNldCBvZiBzcGVjaWZpY2F0aW9ucyAvIHRvb2xzIHRoYXQg YWN0IGFzIHRoZSBsaXR0bGUgYm95IGNyeWluZyAmcXVvdDtXb2xmJnF1b3Q7IGluIHRoZSBuaWdo dC4gJm5ic3A7V2UgbmVlZCB0byBiZSBhYmxlIHRvIGZpbmQgYW5kIGZpeCBpc3N1ZXMgaWYgd2Ug YXJlIGdvaW5nIHRvIHJlYWxseSBtYWtlIGEgZGlmZmVyZW5jZSBpbiBvcmdhbml6YXRpb25hbCBz ZWN1cml0eSBwb3N0dXJlcy4gJm5ic3A7QnV0IHRvZGF5IHdlIHRoaW5rIGl0IGlzIHRvbyBoYXJk IHNvIHdlIGRvbid0IHRyeSA/ICZuYnNwO0kgdGhpbmsgd2UgbmVlZCBhIGNvdXBsZSBob3VycyB0 byBkaXNjdXNzIHRoZSByZWJvb3Qgb2YgdGhlIGVmZm9ydCBldmVuIGlmIHRoYXQgbWVhbnMgbWlu aW1pemluZyB3b3JrIGFscmVhZHkgZG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+QSBmb2N1c2VkIGRpc2N1c3Npb24gb24gZW50ZXJwcmlzZSBy ZXBvcnRpbmcgaXMgYWxzbyBjcml0aWNhbGx5IG5lZWRlZC4gJm5ic3A7Rm9yIHRoZSB2ZW5kb3Jz IGhlcmUsIHdlIGhhdmUgYWxsIGdvbmUgdGhyb3VnaCB0aGUgQ3liZXJzY29wZSBnb2F0IHJvcGUs IGRlbGl2ZXJpbmcgbGltaXRlZCBjYXBhYmlsaXRpZXMgdG8gc3BlY2lmaWMgZGF0YSBjYWxsIHJl cXVpcmVtZW50cyBvZiB0aGUgRmVkZXJhbCBBZ2VuY2llcy4gJm5ic3A7VGhlIGluaXRpYWwgZWZm b3J0IHdhcyBhIG1lc3MsIGRpZCBsaXR0bGUgbW9yZSB0aGFuIHByb3ZlIGl0IHdhcyBwb3NzaWJs ZSBhbmQgY2F1c2UgdGhlIHZlbmRvciBjb21tdW5pdHkgYSBncmVhdCBkZWFsIG9mIHRocmFzaGlu ZyB0byBwdXQgYSBrbHVkZ2V5ICdzb2x1dGlvbicgaW4gcGxhY2UuICZuYnNwO1JlYWxpdHkgaXMg YWxsIG91ciBjdXN0b21lcnMgbmVlZCByb2xsIHVwIHJlcG9ydGluZyBhbmQgYW4gaW5mcmFzdHJ1 Y3R1cmUgdGhhdCBzdXBwb3J0cyBpdC4gJm5ic3A7QSBkYXRhIGNhbGwgc2hvdWxkIG5vdCBiZSBz cGVjaWFsIHRvIGFueW9uZSBvdGhlciB0aGFuIHRoZSBhZ2VuY2llcyByZXNwb25kaW5nLiBUaGUg dG9vbHMgc2hvdWxkIGJlIGFibGUgdG8gc2VsZWN0IHRoZSB0eXBlcyBvZiBkYXRhIG5lZWRlZCBh bmQgZGVsaXZlciB0aGF0IG9uIGEgc2NoZWR1bGVkIGJhc2lzIGF1dG9tYXRpY2FsbHkuICZuYnNw OyAmbmJzcDtFbnRlcnByaXNlIFJlcG9ydGluZyBwZXJ0YWlucyB0byBjb21tZXJjaWFsIGFzIHdl bGwgYXMgRmVkZXJhbCBjdXN0b21lcnMuICZuYnNwO1dlIG5lZWQgdG8gZm9jdXMgc29tZSB0aW1l IG9uIHdoYXQgdGhhdCB3b3VsZCBsb29rIGxpa2UgdXNpbmcgdGhlIEFSRiBhbmQgQVNSIGFzIHRo ZSBmb3VuZGF0aW9uYWwgcGllY2VzLiAmbmJzcDtCdXQgdGhlcmUgYXJlIG1pc3NpbmcgcGllY2Vz 4oCmLiAmbmJzcDtXZSBuZWVkIHRoaXMgZGlzY3Vzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JIHdvdWxkIGhvcGUgd2UgY2FuIG1ha2UgdGhp cyBzdW1tZXIncyBTQ0FQIERldiBEYXlzIHVzZWZ1bCBpbiBhZHZhbmNpbmcgdGhlIHNlY3VyaXR5 IGF1dG9tYXRpb24gZWZmb3J0cyBieSBhZGRyZXNzaW5nIHNvbWUgb2YgdGhlIG1vcmUgY3JpdGlj YWwgaXNzdWVzIG91ciBjdXN0b21lcnMgYXJlIGZhY2luZyBub3cgb3Igd2lsbCBiZSBmYWNpbmcg aW4gdGhlIHZlcnkgc2hvcnQgdGVybS4gJm5ic3A7U3RhdHVzIHByZXNlbnRhdGlvbnMgYXJlIG5v dCBpbnRlcmVzdGluZyB0byB0aG9zZSBhY3RpdmUgaW4gdGhlIGVmZm9ydHMuICZuYnNwO0xldCdz IHRyeSB0byBkbyB0aG9zZSBiZWZvcmUgd2UgZ2V0IHRvIEJlZGZvcmQgc28gd2UgY2FuIHJlYWwg bWFrZSBzb21lIHByb2dyZXNzIHdoaWxlIHdlIGFyZSBhbGwgaW4gdGhlIHNhbWUgcm9vbS4gJm5i c3A7VGhpcyBpcyBhbHdheXMgYSBiaWcgZXZlbnQgZm9yIHRoZSAnY29uc2Vuc3VzIG9mIHRoZSB3 aWxsaW5nJyB0aGF0IGFzc2VtYmxlIGFuZCBkcml2ZW4gdG8gc2VlIHNlY3VyaXR5IGF1dG9tYXRp b24gbWFrZSBhIGRpZmZlcmVuY2UuICZuYnNwO0xldCdzIHNlZSBpZiB3ZSBjYW4gaGF2ZSBhbiBl dmVudCB0aGF0LCB3aGVuIHdlIGFsbCB3YWxrIG91dCB0aGUgbGFzdCBkYXksIHdlIGFsbCBmZWVs IHRoYXQgZXZlcnkgbWludXRlIHdhcyB3ZWxsIHNwZW50IGFuZCBtb3ZlcyB1cyBmb3J3YXJkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGFua3Mu PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjA2QTcx Jz5LZW50IExhbmRmaWVsZDwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPjxicj48 c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPkRpcmVjdG9yIENvbnRlbnQgU3RyYXRlZ3ksIEFy Y2hpdGVjdHVyZSBhbmQgU3RhbmRhcmRzPC9zcGFuPjxicj48YnI+PHN0cm9uZz48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPk1jQWZlZSB8IEFuIEludGVsIENv bXBhbnk8L3NwYW4+PC9zdHJvbmc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+NTAw MCBIZWFkcXVhcnRlcnMgRHIuPC9zcGFuPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFu PlBsYW5vLCBUZXhhcyA3NTAyNDwvc3Bhbj48YnI+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxl LXNwYW4+RGlyZWN0OiArMS45NzIuOTYzLjcwOTYmbmJzcDs8L3NwYW4+PGJyPjxzcGFuIGNsYXNz PWFwcGxlLXN0eWxlLXNwYW4+TW9iaWxlOiArMS44MTcuNjM3LjgwMjY8L3NwYW4+PGJyPjxzdHJv bmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5XZWI6Jm5i c3A7PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PGEgaHJlZj0i aHR0cDovL3d3dy5tY2FmZWUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5tY2FmZWUuY29tPC9h Pjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jmx0O0JvY3plbm93c2tpJmd0OywgU3RldmUgJmx0OzxhIGhyZWY9Im1haWx0 bzpzYm9jemVub0BNSVRSRS5PUkciIHRhcmdldD0iX2JsYW5rIj5zYm9jemVub0BNSVRSRS5PUkc8 L2E+Jmd0Ozxicj48Yj5SZXBseS1UbzogPC9iPiZxdW90O09WQUwgRGV2ZWxvcGVyIExpc3QgKENs b3NlZCBQdWJsaWMgRGlzY3Vzc2lvbikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpPVkFMLURF VkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRyIgdGFyZ2V0PSJfYmxhbmsiPk9WQUwtREVWRUxP UEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZndDs8YnI+PGI+VG86IDwvYj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkciIHRhcmdldD0i X2JsYW5rIj5PVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRyIgdGFy Z2V0PSJfYmxhbmsiPk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZndDs8 YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2VjdXJpdHkgQXV0 b21hdGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwg TUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRE RiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+RnJhbms7PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0MDYxJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPldlIGhvcGUgdG8gaGF2ZSB0aGUgcmVnaXN0cmF0 aW9uIHNpdGUgdXAgbmV4dCB3ZWVrLiZuYnNwOyBUaGUgZXZlbnQgd2lsbCBiZSBkdXJpbmcgdGhl IHdlZWsgb2YgSnVseSA5IOKAkyBzdGFydGluZyBNb25kYXkgYXQgMTA6MDAgQU0gYW5kIGVuZGlu ZyBvbiBGcmlkYXkgYXQgMTI6MDAuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xv cjojMjU0MDYxJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMy NTQwNjEnPk1lYW53aGlsZSwgd2UgYXJlIHdvcmtpbmcgb24gdGhlIGFnZW5kYSBhbmQgYXJlIGN1 cnJlbnRseSBjb25zaWRlcmluZyB0aGlzIGxpc3Qgb2YgdG9waWNzOjwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1pbmRlbnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPkNDRTwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0MDYxJz5DUEUv U1dJRDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xv cjojMjU0MDYxJz5DRUU8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nY29sb3I6IzI1NDA2MSc+WENDREY8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+T1ZBTDwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0MDYxJz5BU1I8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+RW50 ZXJwcmlzZSBPQ0lMPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2NvbG9yOiMyNTQwNjEnPkN5Yk9YL01BRUM8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+RmVkZXJhdGVkIENvbnRlbnQgUmVw b3NpdG9yeSBTcGVjPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2NvbG9yOiMyNTQwNjEnPkVuZHBvaW50IFJlcG9ydGluZyBmb3IgQ29udGludW91cyBNb25p dG9yaW5nIGFuZCBDb21wbGlhbmNlIChFUkNDKTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0MDYxJz5NSUxFPC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPlRBWElJPC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEn PklGLU0gZm9yIFNDQVA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nY29sb3I6IzI1NDA2MSc+SUYtTUFQPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPlNDQVAgUmVsZWFzZXM8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+U0NB UCBhbmQgSUVURjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdjb2xvcjojMjU0MDYxJz5ORVRDT05GIGFuZCBTQ0FQPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdjb2xvcjojMjU0MDYxJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2NvbG9yOiMyNTQwNjEnPlN0ZXZlPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMjU0MDYxJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoyLjBpbic+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gRnJhbmsgTGluZHNheSBBY2tlciBbPGEg aHJlZj0ibWFpbHRvOmFmcmFua0BOT1ZBLkVEVSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzphZnJh bmtATk9WQS5FRFU8L2E+XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAwMSwgMjAxMiA5 OjMyIEFNPGJyPjxiPlRvOjwvYj4gb3ZhbC1kZXZlbG9wZXItbGlzdCBPVkFMIERldmVsb3BlciBM aXN0L0Nsb3NlZCBQdWJsaWMgRGlzY3Vzc2lvbjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPVkFM LURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlzOiBTdW1t ZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlN0ZXZlLi4uLjxicj48YnI+SGFzIHRoZXJlIGJlZW4g YW55IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoaXMgZXZlbnQ/PGJyPjxicj5U aGFua3MsPGJyPkZyYW5rIEFja2VyPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PGRp diBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1j ZW50ZXI+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgaWQ9ZGl2UnBGOTU1MjM2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IEJvY3plbm93c2tpLCBTdGV2 ZSBbPGEgaHJlZj0ibWFpbHRvOnNib2N6ZW5vQE1JVFJFLk9SRyIgdGFyZ2V0PSJfYmxhbmsiPnNi b2N6ZW5vQE1JVFJFLk9SRzwvYT5dPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAyMCwg MjAxMiAxNjozODxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BFUi1M SVNUQExJU1RTLk1JVFJFLk9SRyIgdGFyZ2V0PSJfYmxhbmsiPk9WQUwtREVWRUxPUEVSLUxJU1RA TElTVFMuTUlUUkUuT1JHPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gW09WQUwtREVWRUxPUEVSLUxJ U1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1J VFJFIGluIEJlZGZvcmQsIE1BPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U2F2ZSB0aGUgRGF0ZTogd2Vl ayBvZiBKdWx5IDksIDIwMTI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhpcyB5ZWFy4oCZcyBNSVRSRS1ob3N0ZWQgU2VjdXJp dHkgQXV0b21hdGlvbiBEZXZlbG9wZXIgRGF5cyBldmVudCB3aWxsIGJlIGhlbGQgZHVyaW5nIHRo ZSB3ZWVrIG9mIEp1bHkgOSwgMjAxMiBhdCBNSVRSReKAmXMgZmFjaWxpdHkgaW4gQmVkZm9yZCwg TUEuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPkRldGFpbHMgdG8gZm9sbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN0ZXZlPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDozNDMuNXB0O21hcmdp bi1ib3R0b206NC4wcHQ7bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MzQzLjVwdDttYXJn aW4tYm90dG9tOjQuMHB0O21hcmdpbi1sZWZ0Oi41aW4nPjxpPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TdGVwaDwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ZW4gUC4gQm9jemVub3dza2k8L3NwYW4+PC9pPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MzQzLjVwdDtt YXJnaW4tYm90dG9tOjIuMHB0O21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1JVFJFO2NvbG9yOiMzMzY2RkYnPk1JVFJFPC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiBDb3Jwb3JhdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjM0My41cHQ7bWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPZmZpY2U6ICg3ODEp IDI3MS03NjgyPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjtt YXJnaW4tcmlnaHQ6MzQzLjVwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21h cmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENlbGw6ICg5NzgpIDMwMi0zODQ5PC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MzQzLjVwdDttYXJnaW4tYm90 dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRv OnNib2N6ZW5vQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNib2N6ZW5vQG1pdHJlLm9yZzwv YT48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VG8gdW5zdWJz Y3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byA8YSBocmVmPSJtYWlsdG86TElTVFNFUlZA TElTVFMuTUlUUkUuT1JHIiB0YXJnZXQ9Il9ibGFuayI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JH PC9hPiB3aXRoIFNJR05PRkYgT1ZBTC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUg bWVzc2FnZS4gSWYgeW91IGhhdmUgZGlmZmljdWx0aWVzLCB3cml0ZSB0byA8YSBocmVmPSJtYWls dG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRyIgdGFyZ2V0PSJf YmxhbmsiPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8L2E+LiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRvIHVuc3Vic2Ny aWJlLCBzZW5kIGFuIGVtYWlsIG1lc3NhZ2UgdG8gPGEgaHJlZj0ibWFpbHRvOkxJU1RTRVJWQExJ U1RTLk1JVFJFLk9SRyIgdGFyZ2V0PSJfYmxhbmsiPkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRzwv YT4gd2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1l c3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUgdG8gPGEgaHJlZj0ibWFpbHRv Ok9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkciIHRhcmdldD0iX2Js YW5rIj5PVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPC9hPi4gPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byA8YSBocmVm PSJtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHIiB0YXJnZXQ9Il9ibGFuayI+TElTVFNF UlZATElTVFMuTUlUUkUuT1JHPC9hPiB3aXRoIFNJR05PRkYgT1ZBTC1ERVZFTE9QRVItTElTVCBp biB0aGUgQk9EWSBvZiB0aGUgbWVzc2FnZS4gSWYgeW91IGhhdmUgZGlmZmljdWx0aWVzLCB3cml0 ZSB0byA8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1J VFJFLk9SRyIgdGFyZ2V0PSJfYmxhbmsiPk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNU Uy5NSVRSRS5PUkc8L2E+LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9j a3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgY2xhc3M9 TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPjxociBzaXplPTEgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5zYWNtIG1haWxpbmcgbGlzdDxi cj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNhY21AaWV0 Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FjbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9i b2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930B993245C7MBCLUSTERxcha_-- From david.waltermire@nist.gov Mon May 14 12:12: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 1008D21F841C for ; Mon, 14 May 2012 12:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.451 X-Spam-Level: X-Spam-Status: No, score=-5.451 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmrIuINyct5A for ; Mon, 14 May 2012 12:12:45 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 238EF21F846E for ; Mon, 14 May 2012 12:12:45 -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.355.2; Mon, 14 May 2012 15:12:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 14 May 2012 15:12:42 -0400 From: "Waltermire, David A." To: "bchandra@secpod.com" , SCAP-DEV , "sacm@ietf.org" Date: Mon, 14 May 2012 15:12:42 -0400 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: AQIK+AsmsxvscjAWr3S8jTQP4mAzmQJt5r4nAUXjM/wBLq8ZKJYjDpSAgAP32NA= Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <4FAD544D.2090601@ThreatGuard.com> <04a001cd300a$8c816970$a5843c50$@secpod.com> In-Reply-To: <04a001cd300a$8c816970$a5843c50$@secpod.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 19:12:48 -0000 One problem with SOAP web services is that they are often considered very h= eavy weight. From what I have seen, the IETF tends to prefer lighter weigh= t protocols (e.g. REST, standardized messages over HTTP, etc). Anyone else= have any insights on this? Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cha= ndrashekhar B Sent: Saturday, May 12, 2012 2:43 AM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development Having a standard access interface is really important for content reposito= ry. I had proposed a simple WSDL in a presentation I shared with Kent, last= year's ITSAC. We are looking forward to take active participation in it. Thanks, Chandra. www.secpod.com -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gun= nar Engelbach Sent: Friday, May 11, 2012 11:33 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development It would be great to have as many of these considerations as possible in mi= nd from the start as the actual work begins. As another example, I'd like = to see active participation from vendors that have commercial content repos= itories so those concerns also don't have to be later addressed with major = changes. But we also see a lot of these type of topics come up on the lists, get dis= cussed for a bit, then languish. If reducing the problem set is what it ta= kes to spur some action, let's get started. It kinda sounds like this is headed towards having a dedicated working grou= p to take it on, which is what I'd prefer to see, so I'm avoiding making sp= ecific comments until then. And my apologies to Dave: I'd like to see how much you've already addresse= d, but I just haven't had a chance to look through your draft yet. --gun ThreatGuard, Inc. On 5/11/2012 1:13 PM, Waltermire, David A. wrote: > Kent, > > I have already started work on a draft specification in this area. My > hope is that this work could be used as an initial draft within SACM > at the appropriate time. Count me in. > > I mostly agree with what you are describing below. The only area I > disagree with is in regards to federation. If we do not implement the > specification for an organizational repository in the right way, we > may need to make major changes to support federation. This is not > good for anyone. In my mind these two concepts cannot be decoupled. > We need to insure that any work towards supporting an organizational > repository provides a foundation for supporting a federated repository ne= twork. > Imagine if DNS was designed with a single organization mindset first > without thinking about federation. Top Level Domains (TLDs) and > subdomains would not likely exist as concepts. An individual DNS > server would likely not support caching, time-to-live and delegating > capabilities that are necessary for federation to happen. All of > these things would need to be retrofitted. To prevent this, we need > to address the building blocks of federation in the basic design. > > Sincerely, > > Dave > > *From:*Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] > *Sent:* Friday, May 11, 2012 12:36 PM > *To:* m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; sacm@ietf.org > *Subject:* Request for participants - Content Repository Specification > Development > > Mike I love it when you tee something up like that.. ;-) Thank you. ;) > > Mike wrote: > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will just > be another whitepaper spec. I believe the DoD needs to incorporate a > metadata repository as part of it and other customizations that may > not be useful for everyone. > > We need to talk more. > > If you are talking about a holistic, complete federated approach to a > content repository, I some what agree. If you are talking about an > organizational repository, I totally disagree. But you knew I would. > ;) > > Here is how I see the problem. There is an immediate need for SCAP and > other related content to be served up inside an organization. Today we > have situation where the standards allow us to provide sites the > capability to have a single SCAP implemented policy they call official > for their environment. Yes this is a rather simplistic since there are > things such as targeting specific platforms, specific operational use > needs, but for now lets agree SCAP is a massive improvement over the > proprietary situations of the past. While we have created this > standard content so that sites can implement their local site security > once and then assure they are measuring all appropriately targeted > devices the same way, we have failed to support the operational needs of = the sites. > We have a situation where no two vendors distribute content the same > way. This causes massive problems for the administration staff when > they need to incorporate a new SCAP enabled product into their architectu= re. > They need to discover how the new product supports distributing SCAP > content to it's various components. If they have one product then they > do this one and they are done. If they have multiple products they > will have to figure out how to minimize the impact by incorporating > the update process for the new product into the existing SCAP security > content processes. Now when the inevitable happens and the site staff > needs to make a change to their security policy, they have to make the > modifications to the benchmark or checks or both and then distribute > those updates across their network. For each SCAP enabled product they > have in place, they have doubled, tripled or more the work needed to > make those updates available. > > There is another content repository problem and that is the Federated > Content Distribution. If you think global DNS you have a general frame > of reference. The guidance authors need to be able to publish content > in an authoritative manner so their content is updated in a timely fashio= n. > This is a much harder problem to solve if there is no local > organizational infrastructure to support it. ;) > > So here is what I am thinking. We should consider addressing these as > two separate but integrated efforts. I believe the Organizational > Content Repository is the more critical piece that is actually easier > to address. The Federated Content Distribution should be a subsequent > effort integrating / augmenting the Organizational repository > specification. > > Mike, to your point that we need someone to build one first. That has > happened already. I have one as do other vendors but what we don't > have is the access specification. Ours are focused on our specific > product needs. Additionally there is a company that has developed a > commercial SCAP content repository that will be announced later this > month. I won't steal their thunder but I was recently given a sneak > peek at it and I must admit I was very impressed. Again, to your point, i= t has been done. > What is needed to address the initial operational problem is to > develop a specification that provides a consistent means for all SCAP > products to retrieve the appropriate content as configured and managed > but the site. > > TO THAT END.. > > I am requesting participation from those in the community that see the > need and want to put in the work to make this specification happen. I > have talked to a couple of you but I do not want to assume your > participation. If you are interested please contact me so we can get > this started. > > Thanks! > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Michael A > > *To: *David Waltermire >, SCAP-DEV >, "sacm@ietf.org " > > > *Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Dave, > > I have no problem with webinars, I do want to keep developer days > actionable and use it to make decisions, and vote and accomplish > things good or bad. I do not want this to be an informational > briefing conference. > > Thanks for the links. > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will > just be another whitepaper spec. I believe the DoD needs to > incorporate a metadata repository as part of it and other > customizations that may not be useful for everyone. > > We need to talk more. > > -Mike > > *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] > *Sent:* Tuesday, May 08, 2012 10:44 AM > *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Mike, > > What about having webinars in-place of the 30 minute briefs? > > Regarding content management, we are building the prototype content > repository for use in a production environment. As an open source > project, it will be free for use by anyone interested. My thinking > is that this project can bridge the gap until commercial solutions > are available to augment it. This is a similar path that was > followed with DNS (bind) and HTTP (apache). When it is ready for > use, I am hoping to use it to host USGCB content. You would be > welcome to use it for your needs. > > It is good that OCIL is moving forward. This is an important piece > of supporting risk management and aspects of continuous monitoring. > I would also like to see some discussion on OCIL at Developer Days. > With the proposals we will likely have a sense of what needs to be > discussed and what we can achieve consensus on outside the meeting. > > Remediation is a topic near and dear to my heart. I too would like > to see it move forward. > > We just published the draft ASR specification for public comment. > This specification supports enterprise aggregate reporting which > greatly reduces the data volumes needed verses detailed host-based > reports. This specification has been designed as a more robust > replacement for LASR. It can be used in continuous monitoring > applications to support aggregate data reporting needs (e.g. FISMA > reporting, CyberScope). > > Here are the links: > > http://csrc.nist.gov/publications/PubsDrafts.html > > http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 > > The primary reason we have suggested waiting on XCCDF is not the > internationalization issue. Many vendors have commented that they > are still working on implementing the XCCDF 1.2.1 specification. We > will be in a better place in a few months once more development > around XCCDF has occurred. As we consider changes to the SCAP stack > to address OCIL and other issues, we will identify areas that need > improvement in XCCDF. These are good and necessary discussions to > have now, but we have a good deal of work to do before we are ready > to open up XCCDF. My suggestion is to work on these related areas > and then work up change proposals for XCCDF as needed. By that time > we should be ready to work on a new revision of XCCDF. > > I am also looking forward to the discussions at the conference. It > has been too long. > > Sincerely, > > Dave > > *From:*Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] > *Sent:* Tuesday, May 08, 2012 7:09 AM > *To:* SCAP-DEV > *Cc:* Waltermire, David A. > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > It's good to read your thoughts, and a realistic actionable approach > is indeed needed. Since all the activity hasn't been on the lists a > brief 1=AE2 hour recap may be in order to bring everyone up to speed > since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX > CEE and others. > > We could write a content repository specification, but without > someone willing to stand one up it will be as valuable as the CCSS > specification is today. I've been trying for two years to get my > management to get a coordinated effort together for the DoD to stand > up a repository, it is a tough problem and will require funding with > a tail, I'm not sure a specification will solve that problem. > > We (DoD) have been putting a lot of effort into OCIL over the last > year trying to make it useful in an enterprise environment and will > be posting our ideas to the list before developer days it should > have already started, we need to get consensus and a vote on how the > community wishes to proceed. > > Remediation is stalled but I'm making every effort to get it kick > started from our perspective. I hope to assist in getting the draft > ERI finished this year. We are writing some new STIG content and > intend to used the draft CRE specification to insert CRE into the > content so we (DoD) can do some automatic configuration fixes, part > of a self healing network concept. It is just a start but the best > we can do at this point. > > Enterprise reporting is an interesting subject, since XML adds size > to and content to roll up reporting, in any enterprise of size the > problem gets greater, I look forward to your thoughts on that subject= . > > I am concerned that the internationalization efforts are detracting > from efforts to meet use cases, we have some things we would like > changed in XCCDF to support our OCIl use case and I have been told > that I need to wait. I didn't think that a move to > internationalization should impede efforts to move forward with use > cases. > > I look forward to talking with you at the conference. > > v/r > > Mike Kinney > > Project Director > > Computer Network Defense Research and Technology (CND R&T) Office > > 9800 Savage Road Ste 6767 > Ft Meade, MD 20755-6767 > Phone: 410-854-4422 > NSTS: 968-8886 > Fax 410-854-4681 > > makinn2@nsa.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Waltermire, David A. > *Sent:* Monday, May 07, 2012 7:09 PM > *To:* Multiple recipients of list > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > I like what you are saying here. We are also in support of this type > of approach. We would like to see some community discussion around > what are the key areas/priorities that the community would like to > see discussed at Dev Days. Your topics below look like a good start. > The SACM list might be a better venue than the OVAL list for this > discussion. For each area we should focus the discussion around > developing objectives for each session. The sessions can be time > boxed based on what would be a reasonable amount of time to > accomplish each objective. For example if continuous monitoring is a > priority and collectively it takes 3 days to work through all the > objectives, I see no problem with that. We can also keep a few > sessions "on deck" if all the objectives are reached and we complete > all the scheduled sessions early. > > Thoughts? > > Sincerely, > > David Waltermire > > SCAP Architect > > National Institute of Standards and Technology > > (301) 975-3390 > > david.waltermire@nist.gov > > *From:*scap-dev@nist.gov > [mailto:scap-dev@nist.gov] *On > Behalf Of *Kent_Landfield@mcafee.com > *Sent:* Monday, May 07, 2012 4:25 PM > *To:* SCAP-DEV > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > All, > > I would like to discuss the format for the SCAP Developer Days that > seems to be listed below. > > I see this appears to follow a path we have discussed in the past as > the way not to hold a Dev Days event. We have been trying to get > away from 'Death by Powerpoint' and back to the type of event we > held years ago when we were highly productive. In the past we had a > topic to be discussed and a time box to work within. That allowed us > to have very active brainstorming sessions in a high bandwidth > environment. > > At past Summer events we have got into a pattern of lots of > powerpoint, lots of status of the efforts and very little discussion > about things that need active discussions. We need to keep moving > forward and making progress as an effort. We can get status from > various places such as the lists, a presentation being sent out in > advance, a webinar if it is felt there will be questions and answers > from those that are new to the efforts. We have a limited amount of > time and all who are attending are investing a great deal of time > and money to be there. We should not be spending a great deal of > time reeducating everyone when we could be focused on advancing > needed efforts. > > The type of approach to a Dev Days event was discussed at the last > Summer Dev Days. I have seen the following work quite well in other > efforts. > > 1. Presentations are sent out to the attendees and the lists a week > in advance. > 2. Status for any effort is limited to 30 minutes > 3. Focused brainstorming time should be established for certain > areas that need real work by the community > 4. Efforts to be discussed should be based on needs of the security > automation space to move existing efforts to completion. > > For example: > > Continuous monitoring is a major direction the efforts are becoming > involved with. There are going to be things we need to do as a > security automation community to be able to accomplish what is > listed in the CAESARS FE. There are interfaces that need to be > worked and established. That is one area that is not listed below. > CM will have a major impact on all of us in the next couple years > and it is being ignored. We can't keep trying to solve what has > already been solved. We need to address the needed interface > development now. This is an effort that could take nearly a whole > day by itself. > > Operationally we have a real need to be able to deliver SCAP content > internally within an organization. Today the SCAP vendors cannot > share a single local site security policy (XCCDF + OVAL + CPE +.) > without the site staff having to go to each of the individual > products and figuring out how to inject that new or updated policy > into that products delivery mechanisms. That is limiting sites from > wanting to buy multiple focused SCAP products since they are such a > pain to manage from a content perspective. It is easier to buy from > one vendor that has a single means for distributing content than it > is to deal with the management issues that having multiple SCAP > products presents. We need to have at least an entire 1/2 a day on > the development of a Content Repository specification. > > OCIL is a positive and a negative at the same time. It has real > value that is being underutilized and under implemented because of > the limitations of how it addresses uses in an enterprise > environment. People don't need security automation to do things > on/for a single host. They need security automation to focus on the > enterprise issues that reduce their costs and improve their > efficiencies. OCIL is failing in the enterprise and we all > understand that. We need to address developing a definitive solution > for incorporating OCIL into the enterprise and that means into the > existing specifications. Scheduling and tracking are key to it's > success. We need to make that happen. This too needs a focused > brainstorming time box to discuss options. > > I am really disappointed that Remediation is not on the list below. > Yes, last Summer Dev Days, the time spent on Remediation was wasted > time but that does not mean we should ignore it and not try to make > some real progress. As far as I am concerned we need to reboot the > remediation effort. We cannot keep being the set of specifications / > tools that act as the little boy crying "Wolf" in the night. We need > to be able to find and fix issues if we are going to really make a > difference in organizational security postures. But today we think > it is too hard so we don't try ? I think we need a couple hours to > discuss the reboot of the effort even if that means minimizing work > already done. > > A focused discussion on enterprise reporting is also critically > needed. For the vendors here, we have all gone through the > Cyberscope goat rope, delivering limited capabilities to specific > data call requirements of the Federal Agencies. The initial effort > was a mess, did little more than prove it was possible and cause the > vendor community a great deal of thrashing to put a kludgey > 'solution' in place. Reality is all our customers need roll up > reporting and an infrastructure that supports it. A data call should > not be special to anyone other than the agencies responding. The > tools should be able to select the types of data needed and deliver > that on a scheduled basis automatically. Enterprise Reporting > pertains to commercial as well as Federal customers. We need to > focus some time on what that would look like using the ARF and ASR > as the foundational pieces. But there are missing pieces.. We need > this discussed. > > I would hope we can make this summer's SCAP Dev Days useful in > advancing the security automation efforts by addressing some of the > more critical issues our customers are facing now or will be facing > in the very short term. Status presentations are not interesting to > those active in the efforts. Let's try to do those before we get to > Bedford so we can real make some progress while we are all in the > same room. This is always a big event for the 'consensus of the > willing' that assemble and driven to see security automation make a > difference. Let's see if we can have an event that, when we all walk > out the last day, we all feel that every minute was well spent and > moves us forward. > > Thanks. > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, Steve > > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > > > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > " > > > *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Frank; > > We hope to have the registration site up next week. The event > will be during the week of July 9 - starting Monday at 10:00 AM > and ending on Friday at 12:00. > > Meanwhile, we are working on the agenda and are currently > considering this list of topics: > > CCE > > CPE/SWID > > CEE > > XCCDF > > OVAL > > ASR > > Enterprise OCIL > > CybOX/MAEC > > Federated Content Repository Spec > > Endpoint Reporting for Continuous Monitoring and Compliance > (ERCC) > > MILE > > TAXII > > IF-M for SCAP > > IF-MAP > > SCAP Releases > > SCAP and IETF > > NETCONF and SCAP > > Steve > > *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU] > *Sent:* Tuesday, May 01, 2012 9:32 AM > *To:* oval-developer-list OVAL Developer List/Closed Public > Discussion > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Steve.... > > Has there been any additional information regarding this event? > > Thanks, > Frank Acker > > ------------------------------------------------------------------------ > > *From:*Boczenowski, Steve [sboczeno@MITRE.ORG > ] > *Sent:* Tuesday, March 20, 2012 16:38 > *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > > *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > Save the Date: week of July 9, 2012 > > This year's MITRE-hosted Security Automation Developer Days > event will be held during the week of July 9, 2012 at MITRE's > facility in Bedford, MA. > > Details to follow. > > Regards, > > Steve > > ______________________________________________ > > /Stephen P. Boczenowski/ > > The MITRECorporation > > Office: (781) 271-7682 > > Cell: (978) 302-3849 > > sboczeno@mitre.org > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > have difficulties, write to > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > . > > > > _______________________________________________ > 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 Kent_Landfield@mcafee.com Mon May 14 12:19: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 250B321F884B for ; Mon, 14 May 2012 12:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rphn4QpSP-T3 for ; Mon, 14 May 2012 12:19:27 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 649EF21F884A for ; Mon, 14 May 2012 12:19:27 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 5fdc_1d7a_f86edc3b_38de_4729_847b_a631ee86356b; Mon, 14 May 2012 14:19:14 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Mon, 14 May 2012 14:17:24 -0500 From: To: , Date: Mon, 14 May 2012 14:18:04 -0500 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0yBjDhmleBud8vQimmQ49ffgHT1A== 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.1.120420 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD6C31D32F27kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 19:19:31 -0000 --_000_CBD6C31D32F27kentlandfieldmcafeecom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Mike, This discussion has been about getting a specification in place that will a= llow tools to access content centrally in an organization. It has not been= about any specific set of content. I appreciate your intent to clarify th= e situation but what exact content is served up will have to accommodate a = great deal of considerations. Nice try. ;-) I too believe this is an effor= t that should be driven through the IETF so we can get the more eyes on the= problem and we can create a more flexible / useful environment. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > To: "Kinney, Michael A" >, "david.oliva@verizon.net" >, Kent Landfield >, SCAP-DEV >, "sacm@ietf.org" > Subject: RE: [sacm] Request for participants - Content Repository Specifica= tion Development Mike, I am working to get a session on the agenda at Dev Days to discuss various = aspects of content repository function. I see this as an area that has bro= ad appeal that might be a good consideration for one of the initial work it= ems for SACM. Sincerely, Dave From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] Sent: Monday, May 14, 2012 7:10 AM To: david.oliva@verizon.net; Kent_Landfield= @McAfee.com; Waltermire, David A.; SCAP-D= EV; sacm@ietf.org Subject: RE: [sacm] Request for participants - Content Repository Specifica= tion Development Kent, I re-read your comments, and understand your points. Glad someone is = setting up another SCAP repository, I would like to be included, so will th= is be discussed at developer days, or SACM, or will is someone going to set= up another working group? It will be interesting to get everyone to create and share content, are you= offering up sharing of McAfee content? -Mike From: david.oliva@verizon.net [mailto:david= .oliva@verizon.net] Sent: Saturday, May 12, 2012 3:46 PM To: Kent_Landfield@McAfee.com; Kinney, Mi= chael A; david.waltermire@nist.gov; SCAP-= DEV@nist.gov; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development To all: I am interested in locating content for SCAP 1.2. In particular, content for the specifications added after 1.0. Are you all talking about SCAP 1.2 Content? David Oliva On 05/11/12, Kent_Landfield@McAfee.com wr= ote: Mike I love it when you tee something up like that=85. ;-) Thank you. ;) Mike wrote: I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more=85 If you are talking about a holistic, complete federated approach to a conte= nt repository, I some what agree. If you are talking about an organization= al repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and oth= er related content to be served up inside an organization. Today we have s= ituation where the standards allow us to provide sites the capability to ha= ve a single SCAP implemented policy they call official for their environmen= t. Yes this is a rather simplistic since there are things such as targeting= specific platforms, specific operational use needs, but for now lets agree= SCAP is a massive improvement over the proprietary situations of the past.= While we have created this standard content so that sites can implement th= eir local site security once and then assure they are measuring all appropr= iately targeted devices the same way, we have failed to support the operati= onal needs of the sites. We have a situation where no two vendors distribu= te content the same way. This causes massive problems for the administrati= on staff when they need to incorporate a new SCAP enabled product into thei= r architecture. They need to discover how the new product supports distrib= uting SCAP content to it's various components. If they have one product th= en they do this one and they are done. If they have multiple products they= will have to figure out how to minimize the impact by incorporating the up= date process for the new product into the existing SCAP security content pr= ocesses. Now when the inevitable happens and the site staff needs to make a= change to their security policy, they have to make the modifications to th= e benchmark or checks or both and then distribute those updates across thei= r network. For each SCAP enabled product they have in place, they have dou= bled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Conte= nt Distribution. If you think global DNS you have a general frame of refer= ence. The guidance authors need to be able to publish content in an author= itative manner so their content is updated in a timely fashion. This is a = much harder problem to solve if there is no local organizational infrastruc= ture to support it. ;) So here is what I am thinking=85 We should consider addressing these as tw= o separate but integrated efforts. I believe the Organizational Content Re= pository is the more critical piece that is actually easier to address. Th= e Federated Content Distribution should be a subsequent effort integrating = / augmenting the Organizational repository specification. Mike, to your point that we need someone to build one first=85 That has hap= pened already. I have one as do other vendors but what we don=92t have is = the access specification. Ours are focused on our specific product needs. = Additionally there is a company that has developed a commercial SCAP conte= nt repository that will be announced later this month. I won't steal their = thunder but I was recently given a sneak peek at it and I must admit I was = very impressed. Again, to your point, it has been done. What is needed to = address the initial operational problem is to develop a specification that = provides a consistent means for all SCAP products to retrieve the appropria= te content as configured and managed but the site. TO THAT END=85. I am requesting participation from those in the community that see the need= and want to put in the work to make this specification happen. I have tal= ked to a couple of you but I do not want to assume your participation. If = you are interested please contact me so we can get this started. Thanks! Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Michael A > To: David Waltermire >, SCAP-DEV >, "sacm@ietf= .org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionabl= e and use it to make decisions, and vote and accomplish things good or bad.= I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more=85 -Mike From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content reposit= ory for use in a production environment. As an open source project, it wil= l be free for use by anyone interested. My thinking is that this project c= an bridge the gap until commercial solutions are available to augment it. = This is a similar path that was followed with DNS (bind) and HTTP (apache).= When it is ready for use, I am hoping to use it to host USGCB content. Y= ou would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supp= orting risk management and aspects of continuous monitoring. I would also = like to see some discussion on OCIL at Developer Days. With the proposals = we will likely have a sense of what needs to be discussed and what we can a= chieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see = it move forward. We just published the draft ASR specification for public comment. This spe= cification supports enterprise aggregate reporting which greatly reduces th= e data volumes needed verses detailed host-based reports. This specificatio= n has been designed as a more robust replacement for LASR. It can be used = in continuous monitoring applications to support aggregate data reporting n= eeds (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internatio= nalization issue. Many vendors have commented that they are still working o= n implementing the XCCDF 1.2.1 specification. We will be in a better place = in a few months once more development around XCCDF has occurred. As we con= sider changes to the SCAP stack to address OCIL and other issues, we will i= dentify areas that need improvement in XCCDF. These are good and necessary= discussions to have now, but we have a good deal of work to do before we a= re ready to open up XCCDF. My suggestion is to work on these related areas= and then work up change proposals for XCCDF as needed. By that time we sh= ould be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has bee= n too long. Sincerely, Dave From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, It=92s good to read your thoughts, and a realistic actionable approach is i= ndeed needed. Since all the activity hasn=92t been on the lists a brief 1= =8E2 hour recap may be in order to bring everyone up to speed since there h= as been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone will= ing to stand one up it will be as valuable as the CCSS specification is tod= ay. I=92ve been trying for two years to get my management to get a coordin= ated effort together for the DoD to stand up a repository, it is a tough pr= oblem and will require funding with a tail, I=92m not sure a specification = will solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year try= ing to make it useful in an enterprise environment and will be posting our = ideas to the list before developer days it should have already started, we = need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I=92m making every effort to get it kick started= from our perspective. I hope to assist in getting the draft ERI finished t= his year. We are writing some new STIG content and intend to used the draf= t CRE specification to insert CRE into the content so we (DoD) can do some = automatic configuration fixes, part of a self healing network concept. It i= s just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and = content to roll up reporting, in any enterprise of size the problem gets gr= eater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from ef= forts to meet use cases, we have some things we would like changed in XCCDF= to support our OCIl use case and I have been told that I need to wait. I d= idn=92t think that a move to internationalization should impede efforts to = move forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of ap= proach. We would like to see some community discussion around what are the= key areas/priorities that the community would like to see discussed at Dev= Days. Your topics below look like a good start. The SACM list might be a = better venue than the OVAL list for this discussion. For each area we shou= ld focus the discussion around developing objectives for each session. The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective. For example if continuous monitoring is = a priority and collectively it takes 3 days to work through all the objecti= ves, I see no problem with that. We can also keep a few sessions =93on dec= k=94 if all the objectives are reached and we complete all the scheduled se= ssions early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.com<= mailto:Kent_Landfield@mcafee.com> Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation being sent out in advance, a webinar if it is felt there will be = questions and answers from those that are new to the efforts. We have a li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in ad= vance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas tha= t need real work by the community 4. Efforts to be discussed should be based on needs of the security autom= ation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d with. There are going to be things we need to do as a security automation= community to be able to accomplish what is listed in the CAESARS FE. Ther= e are interfaces that need to be worked and established. That is one area = that is not listed below. CM will have a major impact on all of us in the = next couple years and it is being ignored. We can't keep trying to solve w= hat has already been solved. We need to address the needed interface devel= opment now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +=85) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e they are such a pain to manage from a content perspective. It is easier = to buy from one vendor that has a single means for distributing content tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that = is being underutilized and under implemented because of the limitations of = how it addresses uses in an enterprise environment. People don't need secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. Scheduling and tracking are key to it's success. We need to make that= happen. This too needs a focused brainstorming time box to discuss option= s. I am really disappointed that Remediation is not on the list below=85 Yes,= last Summer Dev Days, the time spent on Remediation was wasted time but th= at does not mean we should ignore it and not try to make some real progress= . As far as I am concerned we need to reboot the remediation effort. We c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. But today we think it is too hard so we don't try ? I think we need = a couple hours to discuss the reboot of the effort even if that means minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al Agencies. The initial effort was a mess, did little more than prove it = was possible and cause the vendor community a great deal of thrashing to pu= t a kludgey 'solution' in place. Reality is all our customers need roll up= reporting and an infrastructure that supports it. A data call should not = be special to anyone other than the agencies responding. The tools should b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces=85. We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess while we are all in the same room. This is always a big event for the = 'consensus of the willing' that assemble and driven to see security automat= ion make a difference. Let's see if we can have an event that, when we all= walk out the last day, we all feel that every minute was well spent and mo= ves us forward. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng the week of July 9 =96 starting Monday at 10:00 AM and ending on Friday = at 12:00. Meanwhile, we are working on the agenda and are currently considering this = list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year=92s MITRE-hosted Security Automation Developer Days event will be= held during the week of July 9, 2012 at MITRE=92s facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. ________________________________ _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CBD6C31D32F27kentlandfieldmcafeecom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Mike,
=

This discussion has been about getting a specification = in place that will allow tools to access content centrally in an organizati= on.  It has not been about any specific set of content.  I apprec= iate your intent to clarify the situation but what exact content is served = up will have to accommodate a great deal of considerations. Nice try. ;-) &= nbsp;I too believe this is an effort that should be driven through the IETF= so we can get the more eyes on the problem and we can create a more flexib= le / useful environment.

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company= <= br>5000 He= adquarters Dr.
Pl= ano, Texas 75024
=
Direct= : +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

F= rom: <Waltermire>, David Waltermire <david.waltermire@nist.gov>
To: "Kinney, Michael A" <m.kinne@radium.ncsc.mil>, "david.oliva@verizon.net" &= lt;david.oliva@verizon.net&g= t;, Kent Landfield <Kent_La= ndfield@McAfee.com>, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@i= etf.org" <sacm@ietf.org>= ;
Subject: RE: [sacm] Request f= or participants - Content Repository Specification Development

Mike,

=  

I am w= orking to get a session on the agenda at Dev Days to discuss various aspect= s of content repository function.  I see this as an area that has broa= d appeal that might be a good consideration for one of the initial work ite= ms for SACM.

=  

S= incerely,

Dav= e

=  

From: Kinney, Mi= chael A [mailto:m.kinne@radium.n= csc.mil]
Sent: Monday, May 14, 2012 7:10 AM
To: david.oliva@verizon.net; Kent_Landfield@McAfee.com; Walt= ermire, David A.; SCAP-DEV; sacm@ietf.org<= /a>
Subject: RE: [sacm] Request for participants - Content Reposi= tory Specification Development

 

K= ent, I re-read your comments, and understand your points. Glad someone is s= etting up another SCAP repository, I would like to be included, so will thi= s be discussed at developer days, or SACM, or will is someone going to setu= p another working group?

It will be interesting to get everyone to create and share cont= ent, are you offering up sharing of McAfee content?

<= p class=3D"MsoNormal"> 

-Mike

 

From: david.oliva@verizon.net [mailto:david.oliva@verizon.net]
S= ent: Saturday, May 12, 2012 3:46 PM
To: Kent_Landfield@McAfee.com; Kinney, Michael A; <= a href=3D"mailto:david.waltermire@nist.gov">david.waltermire@nist.gov; = SCAP-DEV@nist.gov; sacm@ietf.org
Subject: Re: [sacm] Request f= or participants - Content Repository Specification Development

 

=

To all:

 

I am interested in locating content for SCAP 1.2.

In particular, content for the = specifications added after 1.0.

Are you all talking about SCAP 1.2 Content?

 

David Oliva

<= div>

 

 

On 05/11/12, Kent_Land= field@McAfee.com wrote:

 

Mike I love it when you tee something u= p like that=85. ;-)  Thank you. ;)

 

Mike wrote: 

I s= till think that any specification for a repository is wishful thinking unti= l someone builds one and learns the lessons it will just be another whitepa= per spec.  I believe the DoD needs to incorporate a metadata repositor= y as part of it and other customizations that may not be useful for everyon= e.

We need to talk more=85

 

If you are talking about a holistic, complete federat= ed approach to a content repository, I some what agree.  If you are ta= lking about an organizational repository, I totally disagree. But you knew = I would. ;)

 

Here is how I see the problem.  There is an immediate nee= d for SCAP and other related content to be served up inside an organization= .  Today we have situation where the standards allow us to provide sit= es the capability to have a single SCAP implemented policy they call offici= al for their environment. Yes this is a rather simplistic since there are t= hings such as targeting specific platforms, specific operational use needs,= but for now lets agree SCAP is a massive improvement over the proprietary = situations of the past. While we have created this standard content so that= sites can implement their local site security once and then assure they ar= e measuring all appropriately targeted devices the same way, we have failed= to support the operational needs of the sites.  We have a situation w= here no two vendors distribute content the same way.  This causes mass= ive problems for the administration staff when they need to incorporate a n= ew SCAP enabled product into their architecture.  They need to discove= r how the new product supports distributing SCAP content to it's various co= mponents.  If they have one product then they do this one and they are= done.  If they have multiple products they will have to figure out ho= w to minimize the impact by incorporating the update process for the new pr= oduct into the existing SCAP security content processes. Now when the inevi= table happens and the site staff needs to make a change to their security p= olicy, they have to make the modifications to the benchmark or checks or bo= th and then distribute those updates across their network.  For each S= CAP enabled product they have in place, they have doubled, tripled or more = the work needed to make those updates available. 

 

There is another co= ntent repository problem and that is the Federated Content Distribution. &n= bsp;If you think global DNS you have a general frame of reference.  Th= e guidance authors need to be able to publish content in an authoritative m= anner so their content is updated in a timely fashion.  This is a much= harder problem to solve if there is no local organizational infrastructure= to support it. ;)

 

So here is what I am thinking=85  We should consi= der addressing these as two separate but integrated efforts.  I believ= e the Organizational Content Repository is the more critical piece that is = actually easier to address.  The Federated Content Distribution should= be a subsequent effort integrating / augmenting the Organizational reposit= ory specification. 

 

Mike, to your point that we need someone to build= one first=85 That has happened already.  I have one as do other vendo= rs but what we don=92t have is the access specification.  Ours are foc= used on our specific product needs.  Additionally there is a company t= hat has developed a commercial SCAP content repository that will be announc= ed later this month. I won't steal their thunder but I was recently given a= sneak peek at it and I must admit I was very impressed.  Again, to yo= ur point, it has been done. What is needed to address the initial operation= al problem is to develop a specification that provides a consistent means f= or all SCAP products to retrieve the appropriate content as configured and = managed but the site.  

 

TO THAT END=85.

 

I am requesting participatio= n from those in the community that see the need and want to put in the work= to make this specification happen.  I have talked to a couple of you = but I do not want to assume your participation.  If you are interested= please contact me so we can get this started. 

<= p class=3D"MsoNormal"> <= /p>

Thanks!

 

= Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An Intel= Company
5000 Headquart= ers Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 =
Mobile: +1.817.637.8026
Web: <= /span>www.mcafee.com

 

From: <Kinney&g= t;, Michael A <m.kinne@radium.ncsc.mil>
To: David Waltermire <david.waltermire= @nist.gov>, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm= ] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Dave,=

I have no problem with we= binars, I do want to keep developer days actionable and use it to make deci= sions, and vote and accomplish things good or bad.  I do not want this= to be an informational briefing conference.

Thanks for= the links.

 

I still think th= at any specification for a repository is wishful thinking until someone bui= lds one and learns the lessons it will just be another whitepaper spec. &nb= sp;I believe the DoD needs to incorporate a metadata repository as part of = it and other customizations that may not be useful for everyone.

We need to talk more=85<= /o:p>

 

-Mike 

 

From: Waltermire, David A. [mailto:david.waltermire@nist.gov]
Sent: Tu= esday, May 08, 2012 10:44 AM
To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org
Sub= ject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA

 <= /o:p>

Mike,

 

What about having webinars in-place of the= 30 minute briefs?

=

 

Regarding= content management, we are building the prototype content repository for u= se in a production environment.  As an open source project, it will be= free for use by anyone interested.  My thinking is that this project = can bridge the gap until commercial solutions are available to augment it.&= nbsp; This is a similar path that was followed with DNS (bind) and HTTP (ap= ache).  When it is ready for use, I am hoping to use it to host USGCB = content.  You would be welcome to use it for your needs.

 

It is good that OCIL is moving forward.&n= bsp; This is an important piece of supporting risk management and aspects o= f continuous monitoring.  I would also like to see some discussion on = OCIL at Developer Days.  With the proposals we will likely have a sens= e of what needs to be discussed and what we can achieve consensus on outsid= e the meeting.

 

Remediation i= s a topic near and dear to my heart.  I too would like to see it move = forward.

 

We just published= the draft ASR specification for public comment.  This specification s= upports enterprise aggregate reporting which greatly reduces the data volum= es needed verses detailed host-based reports. This specification has been d= esigned as a more robust replacement for LASR.  It can be used in cont= inuous monitoring applications to support aggregate data reporting needs (e= .g. FISMA reporting,  CyberScope).<= o:p>

 

Here are the links:

 

http://csrc.nist.gov/publications/PubsDrafts.html

http://csrc.nist.gov/publications/PubsNISTIRs.ht= ml#NIST-IR-7848

 

The prim= ary reason we have suggested waiting on XCCDF is not the internationalizati= on issue. Many vendors have commented that they are still working on implem= enting the XCCDF 1.2.1 specification. We will be in a better place in a few= months once more development around XCCDF has occurred.  As we consid= er changes to the SCAP stack to address OCIL and other issues, we will iden= tify areas that need improvement in XCCDF.  These are good and necessa= ry discussions to have now, but we have a good deal of work to do before we= are ready to open up XCCDF.  My suggestion is to work on these relate= d areas and then work up change proposals for XCCDF as needed.  By tha= t time we should be ready to work on a new revision of XCCDF.

 

I am also looking forward to the discussi= ons at the conference.  It has been too long.

&nbs= p;

Sincerely,

Dave

 <= /p>

From: Kinney, Michael A= [mailto:m.kin= ne@radium.ncsc.mil]
Sent: Tuesday, May 08, 2012 7:09 AM
<= b>To: SCAP-DEV
Cc: Waltermire, David A.
Subject: RE= : [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 =

Kent,

 =

It=92s good to read your thoughts, and a realistic act= ionable approach is indeed needed.  Since all the activity hasn=92t be= en on the lists a brief 1=8E2 hour recap may be in order to bring everyone = up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/= CybOX CEE and others.<= /p>

 

We cou= ld write a content repository specification, but without someone willing to= stand one up it will be as valuable as the CCSS specification is today. &n= bsp;I=92ve been trying for two years to get my management to get a coordina= ted effort together for the DoD to stand up a repository, it is a tough pro= blem and will require funding with a tail, I=92m not sure a specification w= ill solve that problem.

 

We (= DoD) have been putting a lot of effort into OCIL over the last year trying = to make it useful in an enterprise environment and will be posting our idea= s to the list before developer days it should have already started, we need= to get consensus and a vote on how the community wishes to proceed.=

 

Remediation is stalled but I=92m m= aking every effort to get it kick started from our perspective. I hope to a= ssist in getting the draft ERI finished this year.  We are writing som= e new STIG content and intend to used the draft CRE specification to insert= CRE into the content so we (DoD) can do some automatic configuration fixes= , part of a self healing network concept. It is just a start but the best w= e can do at this point.

 

Ente= rprise reporting is an interesting subject, since XML adds size to and cont= ent to roll up reporting, in any enterprise of size the problem gets greate= r, I look forward to your thoughts on that subject.

&nb= sp;

I am concerned that the internationalization effort= s are detracting from efforts to meet use cases, we have some things we wou= ld like changed in XCCDF to support our OCIl use case and I have been told = that I need to wait. I didn=92t think that a move to internationalization s= hould impede efforts to move forward with use cases.

&n= bsp;

I look forward to talking with you at the conferen= ce.

 

v/r=

 

Mike Kinney

Project Director<= /p>

Computer Network Defense Research and Technolog= y (CND R&T) Office=

9800 Savage Road Ste 6767
Ft Meade, MD 2075= 5-6767
Phone: 410-= 854-4422
NSTS: 968-8886
Fax 410-854-4681

makinn2@nsa.gov=

 

 

 

From:scap-dev@nist.gov = [mailto:sca= p-dev@nist.gov] On Behalf Of Waltermire, David A.
Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipients of listSubject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Da= ys: Summer 2012 at MITRE in Bedford, MA<= o:p>

 = ;

Kent,<= span style=3D"color:black">

 

I like what you are saying here.&nb= sp; We are also in support of this type of approach.  We would like to= see some community discussion around what are the key areas/priorities tha= t the community would like to see discussed at Dev Days.  Your topics = below look like a good start. The SACM list might be a better venue than th= e OVAL list for this discussion.  For each area we should focus the di= scussion around developing objectives for each session.  The sessions = can be time boxed based on what would be a reasonable amount of time to acc= omplish each objective.  For example if continuous monitoring is a pri= ority and collectively it takes 3 days to work through all the objectives, = I see no problem with that.  We can also keep a few sessions =93on dec= k=94 if all the objectives are reached and we complete all the scheduled se= ssions early.

 =

Thoughts?

 =

Sincerely,

 

David Waltermire

<= p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto">SCAP Architect

Na= tional Institute of Standards and Technology

(301) 975-= 3390

david.waltermire@nist.gov

 

From:scap-dev@nist.gov [mailto:scap-d= ev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com
Sent: Mond= ay, May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [OVA= L-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE = in Bedford, MA

 

All,

 

I would like to disc= uss the format for the SCAP Developer Days that seems to be listed below.

 <= o:p>

I see = this appears to follow a path we have discussed in the past as the way not = to hold a Dev Days event.  We have been trying to get away from 'Death= by Powerpoint' and back to the type of event we held years ago when we wer= e highly productive.  In the past we had a topic to be discussed and a= time box to work within.  That allowed us to have very active brainst= orming sessions in a high bandwidth environment.

 

At past Summer events we have g= ot into a pattern of lots of powerpoint, lots of status of the efforts and = very little discussion about things that need active discussions.  We = need to keep moving forward and making progress as an effort. We can get st= atus from various places such as the lists, a presentation being sent out i= n advance, a webinar if it is felt there will be questions and answers from= those that are new to the efforts.  We have a limited amount of time = and all who are attending are investing a great deal of time and money to b= e there.  We should not  be spending a great deal of time reeduca= ting everyone when we could be focused on advancing needed efforts.

 

The type of = approach to a Dev Days event was discussed at the last Summer Dev Days. &nb= sp;I have seen the following work quite well in other efforts.

  1. Presentations are sent out to the attendees and the lists a we= ek in advance.
  2. Status for any effort is limited to 30 minutes
  3. Focused brainstorming time should be esta= blished for certain areas that need real work by the community
  4. Efforts to be discussed sh= ould be based on needs of the security automation space to move existing ef= forts to completion.

For example:

 

Continuous monitoring is a major direction the efforts ar= e becoming involved with. There are going to be things we need to do as a s= ecurity automation community to be able to accomplish what is listed in the= CAESARS FE.  There are interfaces that need to be worked and establis= hed.  That is one area that is not listed below.  CM will have a = major impact on all of us in the next couple years and it is being ignored.=  We can't keep trying to solve what has already been solved.  We= need to address the needed interface development now. This is an effort th= at could take nearly a whole day by itself.

 

Operationally we have a real need to= be able to deliver SCAP content internally within an organization. Today t= he SCAP vendors cannot share a single local site security policy (XCCDF = 3; OVAL + CPE +=85) without the site staff having to go to each of = the individual products and figuring out how to inject that new or updated = policy into that products delivery mechanisms.  That is limiting sites= from wanting to buy multiple focused SCAP products since they are such a p= ain to manage from a content perspective.  It is easier to buy from on= e vendor that has a single means for distributing content than it is to dea= l with the management issues that having multiple SCAP products presents. &= nbsp;We need to have at least an entire 1/2 a day on the development of a C= ontent Repository specification.

 

OCIL is a positive and a negative at the same= time. It has real value that is being underutilized and under implemented = because of the limitations of how it addresses uses in an enterprise enviro= nment.  People don't need security automation to do things on/for a si= ngle host.  They need security automation to focus on the enterprise i= ssues that reduce their costs and improve their efficiencies.  OCIL is= failing in the enterprise and we all understand that.  We need to add= ress developing a definitive solution for incorporating OCIL into the enter= prise and that means into the existing specifications. Scheduling and track= ing are key to it's success.  We need to make that happen.  This = too needs a focused brainstorming time box to discuss options.

 <= /span>

I am really disap= pointed that Remediation is not on the list below=85  Yes, last Summer= Dev Days, the time spent on Remediation was wasted time but that does not = mean we should ignore it and not try to make some real progress.  As f= ar as I am concerned we need to reboot the remediation effort.  We can= not keep being the set of specifications / tools that act as the little boy= crying "Wolf" in the night.  We need to be able to find and= fix issues if we are going to really make a difference in organizational s= ecurity postures.  But today we think it is too hard so we don't try ?=  I think we need a couple hours to discuss the reboot of the effort e= ven if that means minimizing work already done.

=

 

A focused discussion on enterpri= se reporting is also critically needed.  For the vendors here, we have= all gone through the Cyberscope goat rope, delivering limited capabilities= to specific data call requirements of the Federal Agencies.  The init= ial effort was a mess, did little more than prove it was possible and cause= the vendor community a great deal of thrashing to put a kludgey 'solution'= in place.  Reality is all our customers need roll up reporting and an= infrastructure that supports it.  A data call should not be special t= o anyone other than the agencies responding. The tools should be able to se= lect the types of data needed and deliver that on a scheduled basis automat= ically.    Enterprise Reporting pertains to commercial as well as= Federal customers.  We need to focus some time on what that would loo= k like using the ARF and ASR as the foundational pieces.  But there ar= e missing pieces=85.  We need this discussed.

 

I would hope we can make this= summer's SCAP Dev Days useful in advancing the security automation efforts= by addressing some of the more critical issues our customers are facing no= w or will be facing in the very short term.  Status presentations are = not interesting to those active in the efforts.  Let's try to do those= before we get to Bedford so we can real make some progress while we are al= l in the same room.  This is always a big event for the 'consensus of = the willing' that assemble and driven to see security automation make a dif= ference.  Let's see if we can have an event that, when we all walk out= the last day, we all feel that every minute was well spent and moves us fo= rward.

 

Thanks.

 

Kent Landfield
Director Content Strategy, Architecture and Standards<= br>
McAfee | An= Intel Company
5000 Hea= dquarters Dr.
Plano, Texas 75024=

Direct: +1.972.963.7096=  
Mobile: +1.817.637.80= 26
Web:&= nbsp;www.mcafee.com

<= p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto"> 

From: <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply-To: &q= uot;OVAL Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-L= IST@LISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@LISTS.MIT= RE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
Subjec= t: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer= 2012 at MITRE in Bedford, MA

 

Frank;

 

We hope= to have the registration site up next week.  The event will be during= the week of July 9 =96 starting Monday at 10:00 AM and ending on Friday at= 12:00.

 <= /o:p>

Meanwhile, we are wo= rking on the agenda and are currently considering this list of topics:

 =

CCE

CPE/SWID

C= EE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/= MAEC

Federated Content Repository Spec=

Endpoint Reporting for Continuous Mon= itoring and Compliance (ERCC)=

MILE

TAXII<= o:p>

IF-M for SCAP

IF-MAP

SCAP Releases=

SC= AP and IETF

NETCONF and SCAP

 

<= p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto">Steve

 

 <= o:p>

Steve....

= Has there been any additional information regarding this event?

Than= ks,
Frank Acker

=

From: Bocz= enowski, Steve [sbo= czeno@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To= : OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Subject: [OVAL-DEVELO= PER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedfo= rd, MA

<= div>

Save the Date: we= ek of July 9, 2012

 

This year=92s MITRE-hosted Security Automation De= veloper Days event will be held during the week of July 9, 2012 at MITRE=92= s facility in Bedford, MA.

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

Details to follow.

<= p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto;margin-left:.5in"> 

Regards,

 =    Steve

 

______________________________________________

Stephen P. Boczeno= wski

    &nbs= p; The MITRE Corporation

      Office: (781) 271-= 7682

  &n= bsp;   Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE= .ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If yo= u have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE= .ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MIT= RE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If = you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MIT= RE.ORG.

To u= nsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVE= LOPER-LIST in the BODY of the message. If you have difficulties, write to <= a href=3D"mailto:OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG" target=3D"_bl= ank">OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

 


_______________________= ________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/li= stinfo/sacm

--_000_CBD6C31D32F27kentlandfieldmcafeecom_-- From Kent_Landfield@mcafee.com Mon May 14 12:24: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 09D1B21F88AC for ; Mon, 14 May 2012 12:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.378 X-Spam-Level: X-Spam-Status: No, score=-5.378 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVYGdm0yHa4b for ; Mon, 14 May 2012 12:24:26 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 5C51221F88AB for ; Mon, 14 May 2012 12:24:26 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 5fdc_1ebc_41207779_2ef2_4483_8a4e_caf2ec8908c3; Mon, 14 May 2012 14:24:17 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 14 May 2012 14:22:57 -0500 From: To: , Date: Mon, 14 May 2012 14:23:37 -0500 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0yBve8CAhpagtWQiqKXSDjuJgFzg== 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.1.120420 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD6C4B432F3Ckentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: turners@ieca.com Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 19:24:31 -0000 --_000_CBD6C4B432F3Ckentlandfieldmcafeecom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi Sean, Can you help here? I too have heard that but I want to make sure we are no= t being confused by hearsay=85 Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > To: "bchandra@secpod.com" >, SCAP-DEV >, "sacm@ietf.org" > Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development One problem with SOAP web services is that they are often considered very h= eavy weight. From what I have seen, the IETF tends to prefer lighter weigh= t protocols (e.g. REST, standardized messages over HTTP, etc). Anyone else= have any insights on this? Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Chandrashekhar B Sent: Saturday, May 12, 2012 2:43 AM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development Having a standard access interface is really important for content reposito= ry. I had proposed a simple WSDL in a presentation I shared with Kent, last= year's ITSAC. We are looking forward to take active participation in it. Thanks, Chandra. www.secpod.com -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 11, 2012 11:33 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development It would be great to have as many of these considerations as possible in mi= nd from the start as the actual work begins. As another example, I'd like = to see active participation from vendors that have commercial content repos= itories so those concerns also don't have to be later addressed with major = changes. But we also see a lot of these type of topics come up on the lists, get dis= cussed for a bit, then languish. If reducing the problem set is what it ta= kes to spur some action, let's get started. It kinda sounds like this is headed towards having a dedicated working grou= p to take it on, which is what I'd prefer to see, so I'm avoiding making sp= ecific comments until then. And my apologies to Dave: I'd like to see how much you've already addresse= d, but I just haven't had a chance to look through your draft yet. --gun ThreatGuard, Inc. On 5/11/2012 1:13 PM, Waltermire, David A. wrote: Kent, I have already started work on a draft specification in this area. My hope is that this work could be used as an initial draft within SACM at the appropriate time. Count me in. I mostly agree with what you are describing below. The only area I disagree with is in regards to federation. If we do not implement the specification for an organizational repository in the right way, we may need to make major changes to support federation. This is not good for anyone. In my mind these two concepts cannot be decoupled. We need to insure that any work towards supporting an organizational repository provides a foundation for supporting a federated repository netw= ork. Imagine if DNS was designed with a single organization mindset first without thinking about federation. Top Level Domains (TLDs) and subdomains would not likely exist as concepts. An individual DNS server would likely not support caching, time-to-live and delegating capabilities that are necessary for federation to happen. All of these things would need to be retrofitted. To prevent this, we need to address the building blocks of federation in the basic design. Sincerely, Dave *From:*Kent_Landfield@McAfee.com [mailto= :Kent_Landfield@McAfee.com] *Sent:* Friday, May 11, 2012 12:36 PM *To:* m.kinne@radium.ncsc.mil; Waltermire, = David A.; SCAP-DEV; sacm@ietf.org *Subject:* Request for participants - Content Repository Specification Development Mike I love it when you tee something up like that.. ;-) Thank you. ;) Mike wrote: I still think that any specification for a repository is wishful thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful for everyone. We need to talk more. If you are talking about a holistic, complete federated approach to a content repository, I some what agree. If you are talking about an organizational repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and other related content to be served up inside an organization. Today we have situation where the standards allow us to provide sites the capability to have a single SCAP implemented policy they call official for their environment. Yes this is a rather simplistic since there are things such as targeting specific platforms, specific operational use needs, but for now lets agree SCAP is a massive improvement over the proprietary situations of the past. While we have created this standard content so that sites can implement their local site security once and then assure they are measuring all appropriately targeted devices the same way, we have failed to support the operational needs of th= e sites. We have a situation where no two vendors distribute content the same way. This causes massive problems for the administration staff when they need to incorporate a new SCAP enabled product into their architecture= . They need to discover how the new product supports distributing SCAP content to it's various components. If they have one product then they do this one and they are done. If they have multiple products they will have to figure out how to minimize the impact by incorporating the update process for the new product into the existing SCAP security content processes. Now when the inevitable happens and the site staff needs to make a change to their security policy, they have to make the modifications to the benchmark or checks or both and then distribute those updates across their network. For each SCAP enabled product they have in place, they have doubled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Content Distribution. If you think global DNS you have a general frame of reference. The guidance authors need to be able to publish content in an authoritative manner so their content is updated in a timely fashion. This is a much harder problem to solve if there is no local organizational infrastructure to support it. ;) So here is what I am thinking. We should consider addressing these as two separate but integrated efforts. I believe the Organizational Content Repository is the more critical piece that is actually easier to address. The Federated Content Distribution should be a subsequent effort integrating / augmenting the Organizational repository specification. Mike, to your point that we need someone to build one first. That has happened already. I have one as do other vendors but what we don't have is the access specification. Ours are focused on our specific product needs. Additionally there is a company that has developed a commercial SCAP content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I was very impressed. Again, to your point, it = has been done. What is needed to address the initial operational problem is to develop a specification that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site. TO THAT END.. I am requesting participation from those in the community that see the need and want to put in the work to make this specification happen. I have talked to a couple of you but I do not want to assume your participation. If you are interested please contact me so we can get this started. Thanks! *Kent Landfield* Director Content Strategy, Architecture and Standards *McAfee | An Intel Company* 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *, Michael A > *To: *David Waltermire >, SCAP-DEV >, "sacm@ietf.org " > *Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionable and use it to make decisions, and vote and accomplish things good or bad. I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful for everyone. We need to talk more. -Mike *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] *Sent:* Tuesday, May 08, 2012 10:44 AM *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content repository for use in a production environment. As an open source project, it will be free for use by anyone interested. My thinking is that this project can bridge the gap until commercial solutions are available to augment it. This is a similar path that was followed with DNS (bind) and HTTP (apache). When it is ready for use, I am hoping to use it to host USGCB content. You would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supporting risk management and aspects of continuous monitoring. I would also like to see some discussion on OCIL at Developer Days. With the proposals we will likely have a sense of what needs to be discussed and what we can achieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see it move forward. We just published the draft ASR specification for public comment. This specification supports enterprise aggregate reporting which greatly reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR. It can be used in continuous monitoring applications to support aggregate data reporting needs (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred. As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF. These are good and necessary discussions to have now, but we have a good deal of work to do before we are ready to open up XCCDF. My suggestion is to work on these related areas and then work up change proposals for XCCDF as needed. By that time we should be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has been too long. Sincerely, Dave *From:*Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] *Sent:* Tuesday, May 08, 2012 7:09 AM *To:* SCAP-DEV *Cc:* Waltermire, David A. *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Kent, It's good to read your thoughts, and a realistic actionable approach is indeed needed. Since all the activity hasn't been on the lists a brief 1=8E2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification is today. I've been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is a tough problem and will require funding with a tail, I'm not sure a specification will solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year trying to make it useful in an enterprise environment and will be posting our ideas to the list before developer days it should have already started, we need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I'm making every effort to get it kick started from our perspective. I hope to assist in getting the draft ERI finished this year. We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can do some automatic configuration fixes, part of a self healing network concept. It is just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to wait. I didn't think that a move to internationalization should impede efforts to move forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov *From:*scap-dev@nist.gov [mailto:scap-dev@nist.gov] *On Behalf Of *Waltermire, David A. *Sent:* Monday, May 07, 2012 7:09 PM *To:* Multiple recipients of list *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of approach. We would like to see some community discussion around what are the key areas/priorities that the community would like to see discussed at Dev Days. Your topics below look like a good start. The SACM list might be a better venue than the OVAL list for this discussion. For each area we should focus the discussion around developing objectives for each session. The sessions can be time boxed based on what would be a reasonable amount of time to accomplish each objective. For example if continuous monitoring is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that. We can also keep a few sessions "on deck" if all the objectives are reached and we complete all the scheduled sessions early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov *From:*scap-dev@nist.gov [mailto:scap-dev@nist.gov] *On Behalf Of *Kent_Landfield@mcafee.com *Sent:* Monday, May 07, 2012 4:25 PM *To:* SCAP-DEV *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems to be listed below. I see this appears to follow a path we have discussed in the past as the way not to hold a Dev Days event. We have been trying to get away from 'Death by Powerpoint' and back to the type of event we held years ago when we were highly productive. In the past we had a topic to be discussed and a time box to work within. That allowed us to have very active brainstorming sessions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lots of status of the efforts and very little discussion about things that need active discussions. We need to keep moving forward and making progress as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there will be questions and answers from those that are new to the efforts. We have a limited amount of time and all who are attending are investing a great deal of time and money to be there. We should not be spending a great deal of time reeducating everyone when we could be focused on advancing needed efforts. The type of approach to a Dev Days event was discussed at the last Summer Dev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in advance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas that need real work by the community 4. Efforts to be discussed should be based on needs of the security automation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involved with. There are going to be things we need to do as a security automation community to be able to accomplish what is listed in the CAESARS FE. There are interfaces that need to be worked and established. That is one area that is not listed below. CM will have a major impact on all of us in the next couple years and it is being ignored. We can't keep trying to solve what has already been solved. We need to address the needed interface development now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +.) without the site staff having to go to each of the individual products and figuring out how to inject that new or updated policy into that products delivery mechanisms. That is limiting sites from wanting to buy multiple focused SCAP products since they are such a pain to manage from a content perspective. It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having multiple SCAP products presents. We need to have at least an entire 1/2 a day on the development of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that is being underutilized and under implemented because of the limitations of how it addresses uses in an enterprise environment. People don't need security automation to do things on/for a single host. They need security automation to focus on the enterprise issues that reduce their costs and improve their efficiencies. OCIL is failing in the enterprise and we all understand that. We need to address developing a definitive solution for incorporating OCIL into the enterprise and that means into the existing specifications. Scheduling and tracking are key to it's success. We need to make that happen. This too needs a focused brainstorming time box to discuss options. I am really disappointed that Remediation is not on the list below. Yes, last Summer Dev Days, the time spent on Remediation was wasted time but that does not mean we should ignore it and not try to make some real progress. As far as I am concerned we need to reboot the remediation effort. We cannot keep being the set of specifications / tools that act as the little boy crying "Wolf" in the night. We need to be able to find and fix issues if we are going to really make a difference in organizational security postures. But today we think it is too hard so we don't try ? I think we need a couple hours to discuss the reboot of the effort even if that means minimizing work already done. A focused discussion on enterprise reporting is also critically needed. For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of the Federal Agencies. The initial effort was a mess, did little more than prove it was possible and cause the vendor community a great deal of thrashing to put a kludgey 'solution' in place. Reality is all our customers need roll up reporting and an infrastructure that supports it. A data call should not be special to anyone other than the agencies responding. The tools should be able to select the types of data needed and deliver that on a scheduled basis automatically. Enterprise Reporting pertains to commercial as well as Federal customers. We need to focus some time on what that would look like using the ARF and ASR as the foundational pieces. But there are missing pieces.. We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing the security automation efforts by addressing some of the more critical issues our customers are facing now or will be facing in the very short term. Status presentations are not interesting to those active in the efforts. Let's try to do those before we get to Bedford so we can real make some progress while we are all in the same room. This is always a big event for the 'consensus of the willing' that assemble and driven to see security automation make a difference. Let's see if we can have an event that, when we all walk out the last day, we all feel that every minute was well spent and moves us forward. Thanks. *Kent Landfield* Director Content Strategy, Architecture and Standards *McAfee | An Intel Company* 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *, Steve > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG " > *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be during the week of July 9 - starting Monday at 10:00 AM and ending on Friday at 12:00. Meanwhile, we are working on the agenda and are currently considering this list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU] *Sent:* Tuesday, May 01, 2012 9:32 AM *To:* oval-developer-list OVAL Developer List/Closed Public Discussion *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ------------------------------------------------------------------------ *From:*Boczenowski, Steve [sboczeno@MITRE.ORG ] *Sent:* Tuesday, March 20, 2012 16:38 *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year's MITRE-hosted Security Automation Developer Days event will be held during the week of July 9, 2012 at MITRE's facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ /Stephen P. Boczenowski/ The MITRECorporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG . To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG . To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG . _______________________________________________ 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 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CBD6C4B432F3Ckentlandfieldmcafeecom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Hi Sean,

Can you help here?  I too have heard that but I= want to make sure we are not being confused by hearsay=85

Thanks.

Kent Landfield
Director Content Strategy, A= rchitecture and Standards


5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026<= /span>
= Web: = ;= www.mcafee.com

From: <Waltermire>, David = Waltermire <david.waltermir= e@nist.gov>
To: "bchandra@secpod.com" <bchandra@secpod.com>, SCAP-DEV &l= t;SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
S= ubject: Re: [sacm] Request for participants - Content Repository Sp= ecification Development

One problem with SOAP web services = is that they are often considered very heavy weight.  From what I= have seen, the IETF tends to prefer lighter weight protocols (e.g. REST, s= tandardized messages over HTTP, etc).  Anyone else have any insig= hts on this?

Sincerely,
Dave
<= br>

-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Chandrashekhar B
Sent: Saturday, May 12, 2012 2:43 AM
To: SCAP-DEV; sacm@ietf.org
Subject: Re: [sacm] Request for participants - Content Repository Specifi= cation Development

Having a standard access interf= ace is really important for content repository. I had proposed a simple WSD= L in a presentation I shared with Kent, last year's ITSAC. We are looking f= orward to take active participation in it.

Thanks,=
Chandra.
www.secpod.com

-----= Original Message-----
From: sacm-bounces@ietf.org [mai= lto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach
Sent= : Friday, May 11, 2012 11:33 PM
Cc: SCAP-DEV; sacm@ietf.org
Subject: Re: [sacm] Request for p= articipants - Content Repository Specification Development


It would be great to have as many of these consider= ations as possible in mind from the start as the actual work begins. &= nbsp;As another example, I'd like to see active participation from vendors = that have commercial content repositories so those concerns also don't have= to be later addressed with major changes.

But we = also see a lot of these type of topics come up on the lists, get discussed = for a bit, then languish.  If reducing the problem set is what it= takes to spur some action, let's get started.

It = kinda sounds like this is headed towards having a dedicated working group t= o take it on, which is what I'd prefer to see, so I'm avoiding making speci= fic comments until then.

And my apologies to Dave:=   I'd like to see how much you've already addressed, but I just h= aven't had a chance to look through your draft yet.



--gun

ThreatGuard,= Inc.


On 5/11/2012 1:13 PM, Walterm= ire, David A. wrote:
Kent,

I have already started work on a d= raft specification in this area.  My
hope is that this= work could be used as an initial draft within SACM
at the appro= priate time.  Count me in.

I mostly agr= ee with what you are describing below.  The only area I
disagree with is in regards to federation.  If we do not implem= ent the
specification for an organizational repository in the ri= ght way, we
may need to make major changes to support federation= .  This is not
good for anyone.  In my mind = these two concepts cannot be decoupled.
We need to insure that a= ny work towards supporting an organizational
repository provides= a foundation for supporting a federated repository network.
Ima= gine if DNS was designed with a single organization mindset first
without thinking about federation.  Top Level Domains (TLDs) an= d
subdomains would not likely exist as concepts.  An i= ndividual DNS
server would likely not support caching, time-to-l= ive and delegating
capabilities that are necessary for federatio= n to happen.  All of
these things would need to be ret= rofitted.  To prevent this, we need
to address the bui= lding blocks of federation in the basic design.

S= incerely,

Dave

*From:*Kent_Landfield@McAfee.com = [mailto:Kent_Landfield@McAfee.= com]
*Sent:* Friday, May 11, 2012 12:36 PM
*To:* = m.kinne@radium.ncsc.mil; Wal= termire, David A.; SCAP-DEV;
*Subject:* Request for participants - Content Repository Sp= ecification
Development

Mike I love it= when you tee something up like that.. ;-) Thank you. ;)

Mike wrote:

I still think that any specif= ication for a repository is wishful
thinking until someone build= s one and learns the lessons it will just
be another whitepaper = spec. I believe the DoD needs to incorporate a
metadata reposito= ry as part of it and other customizations that may
not be useful= for everyone.

We need to talk more.
If you are talking about a holistic, complete federated appro= ach to a
content repository, I some what agree. If you are talki= ng about an
organizational repository, I totally disagree. But y= ou knew I would.
;)

Here is how I see = the problem. There is an immediate need for SCAP and
other relat= ed content to be served up inside an organization. Today we
have= situation where the standards allow us to provide sites the
cap= ability to have a single SCAP implemented policy they call official
for their environment. Yes this is a rather simplistic since there are<= /div>
things such as targeting specific platforms, specific operationa= l use
needs, but for now lets agree SCAP is a massive improvemen= t over the
proprietary situations of the past. While we have cre= ated this
standard content so that sites can implement their loc= al site security
once and then assure they are measuring all app= ropriately targeted
devices the same way, we have failed to supp= ort the operational needs of the sites.
We have a situation wher= e no two vendors distribute content the same
way. This causes ma= ssive problems for the administration staff when
they need to in= corporate a new SCAP enabled product into their architecture.
Th= ey need to discover how the new product supports distributing SCAP
content to it's various components. If they have one product then they
do this one and they are done. If they have multiple products the= y
will have to figure out how to minimize the impact by incorpor= ating
the update process for the new product into the existing S= CAP security
content processes. Now when the inevitable happens = and the site staff
needs to make a change to their security poli= cy, they have to make the
modifications to the benchmark or chec= ks or both and then distribute
those updates across their networ= k. For each SCAP enabled product they
have in place, they have d= oubled, tripled or more the work needed to
make those updates av= ailable.

There is another content repository prob= lem and that is the Federated
Content Distribution. If you think= global DNS you have a general frame
of reference. The guidance = authors need to be able to publish content
in an authoritative m= anner so their content is updated in a timely fashion.
This is a= much harder problem to solve if there is no local
organizationa= l infrastructure to support it. ;)

So here is wha= t I am thinking. We should consider addressing these as
two sepa= rate but integrated efforts. I believe the Organizational
Conten= t Repository is the more critical piece that is actually easier
= to address. The Federated Content Distribution should be a subsequent
=
effort integrating / augmenting the Organizational repository
specification.

Mike, to your point that we ne= ed someone to build one first. That has
happened already. I have= one as do other vendors but what we don't
have is the access sp= ecification. Ours are focused on our specific
product needs. Add= itionally there is a company that has developed a
commercial SCA= P content repository that will be announced later this
month. I = won't steal their thunder but I was recently given a sneak
peek = at it and I must admit I was very impressed. Again, to your point, it has b= een done.
What is needed to address the initial operational prob= lem is to
develop a specification that provides a consistent mea= ns for all SCAP
products to retrieve the appropriate content as = configured and managed
but the
site.

T= O THAT END..

I am requesting participation from t= hose in the community that see the
need and want to put in the w= ork to make this specification happen. I
have talked to a couple= of you but I do not want to assume your
participation. If you a= re interested please contact me so we can get
this started.

Thanks!

*Kent Landfield*
Director Content Strategy, Architecture and Standards
*McAfee | An Intel Company*
5000 Headquarters Dr.<= /div>
Plano, Texas 75024

Direct: +1.972.= 963.7096
Mobile: +1.817.637.8026
*Web: *www.mcafe= e.com <http://www.mcafee.com/>=

*From: *<Kinney>, Michael A <m.kinne@radium.ncsc.mil
*To: *David Waltermire <david.waltermire@nist.gov
*Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automati= on
Developer Days: Summer 2012 at MITRE in Bedford, MA

     Dave,

&nb= sp;    I have no problem with webinars, I do want to keep de= veloper days
     actionable and use it to ma= ke decisions, and vote and accomplish
     th= ings good or bad. I do not want this to be an informational
 = ;    briefing conference.

 &nb= sp;   Thanks for the links.

  =    I still think that any specification for a repository is wishf= ul
     thinking until someone builds one and= learns the lessons it will
     just be anot= her whitepaper spec. I believe the DoD needs to
   = ;  incorporate a metadata repository as part of it and other
     customizations that may not be useful for everyon= e.

     We need to talk more.<= /div>

     -Mike

     *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov]
     *Sent:* Tuesday, May 08, 2012 10:44 AM
     *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org
     *Subject:* = RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
 &nb= sp;   Days: Summer 2012 at MITRE in Bedford, MA

     Mike,

  = ;   What about having webinars in-place of the 30 minute briefs?<= /div>

     Regarding content managem= ent, we are building the prototype content
   &nbs= p; repository for use in a production environment. As an open source
<= div>     project, it will be free for use by anyone int= erested. My thinking
     is that this projec= t can bridge the gap until commercial solutions
   = ;  are available to augment it. This is a similar path that was
<= div>     followed with DNS (bind) and HTTP (apache). Wh= en it is ready for
     use, I am hoping to u= se it to host USGCB content. You would be
    = ; welcome to use it for your needs.

  &n= bsp;  It is good that OCIL is moving forward. This is an important pie= ce
     of supporting risk management and asp= ects of continuous monitoring.
     I would a= lso like to see some discussion on OCIL at Developer Days.
 =     With the proposals we will likely have a sense of what n= eeds to be
     discussed and what we can ach= ieve consensus on outside the meeting.

  = ;   Remediation is a topic near and dear to my heart. I too would= like
     to see it move forward.
=
     We just published the draft ASR spe= cification for public comment.
     This spec= ification supports enterprise aggregate reporting which
 &nb= sp;   greatly reduces the data volumes needed verses detailed hos= t-based
     reports. This specification has = been designed as a more robust
     replaceme= nt for LASR. It can be used in continuous monitoring
  =    applications to support aggregate data reporting needs (e.g. F= ISMA
     reporting, CyberScope).
<= br>
     Here are the links:

     http://csrc.nist.gov/publications/PubsDrafts.html<= /div>


 =     The primary reason we have suggested waiting on XCCDF is= not the
     internationalization issue. Man= y vendors have commented that they
     are s= till working on implementing the XCCDF 1.2.1 specification. We
&n= bsp;    will be in a better place in a few months once more = development
     around XCCDF has occurred. A= s we consider changes to the SCAP stack
     = to address OCIL and other issues, we will identify areas that need
     improvement in XCCDF. These are good and necessa= ry discussions to
     have now, but we have = a good deal of work to do before we are ready
   &= nbsp; to open up XCCDF. My suggestion is to work on these related areas
     and then work up change proposals for XCCDF= as needed. By that time
     we should be re= ady to work on a new revision of XCCDF.

 &nbs= p;   I am also looking forward to the discussions at the conferen= ce. It
     has been too long.

=
     Sincerely,

&nb= sp;    Dave

    = ; *From:*Kinney, Michael A [mail= to:m.kinne@radium.ncsc.mil]
     *Sent:* = Tuesday, May 08, 2012 7:09 AM
     *To:* SCAP= -DEV
     *Cc:* Waltermire, David A.
     *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Au= tomation Developer
     Days: Summer 2012 at = MITRE in Bedford, MA

     Kent= ,

     It's good to read your = thoughts, and a realistic actionable approach
   &= nbsp; is indeed needed. Since all the activity hasn't been on the lists a
     brief 1=8E2 hour recap may be in order to= bring everyone up to speed
     since there = has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX
 &n= bsp;   CEE and others.

   = ;  We could write a content repository specification, but without
     someone willing to stand one up it will be a= s valuable as the CCSS
     specification is = today. I've been trying for two years to get my
   = ;  management to get a coordinated effort together for the DoD to stan= d
     up a repository, it is a tough problem= and will require funding with
     a tail, I= 'm not sure a specification will solve that problem.

     We (DoD) have been putting a lot of effort into= OCIL over the last
     year trying to make = it useful in an enterprise environment and will
   = ;  be posting our ideas to the list before developer days it should
     have already started, we need to get conse= nsus and a vote on how the
     community wis= hes to proceed.

     Remediati= on is stalled but I'm making every effort to get it kick
 &n= bsp;   started from our perspective. I hope to assist in getting = the draft
     ERI finished this year. We are= writing some new STIG content and
     inten= d to used the draft CRE specification to insert CRE into the
&nbs= p;    content so we (DoD) can do some automatic configuratio= n fixes, part
     of a self healing network = concept. It is just a start but the best
    = we can do at this point.

    = Enterprise reporting is an interesting subject, since XML adds size
<= div>     to and content to roll up reporting, in any en= terprise of size the
     problem gets greate= r, I look forward to your thoughts on that subject.

     I am concerned that the internationalization eff= orts are detracting
     from efforts to meet= use cases, we have some things we would like
   &= nbsp; changed in XCCDF to support our OCIl use case and I have been told
     that I need to wait. I didn't think that a= move to
     internationalization should imp= ede efforts to move forward with use
     cas= es.

     I look forward to tal= king with you at the conference.

   = ;  v/r

     Mike Kinney

     Project Director

     Computer Network Defense Research = and Technology (CND R&T) Office

  &n= bsp;  9800 Savage Road Ste 6767
     Ft = Meade, MD 20755-6767
     Phone: 410-854-4422=
     NSTS: 968-8886
  &n= bsp;  Fax 410-854-4681

<= div>


   =   of approach. We would like to see some community discussion around
     what are the key areas/priorities that th= e community would like to
     see discussed = at Dev Days. Your topics below look like a good start.
 &nbs= p;   The SACM list might be a better venue than the OVAL list for= this
     discussion. For each area we shoul= d focus the discussion around
     developing= objectives for each session. The sessions can be time
 &nbs= p;   boxed based on what would be a reasonable amount of time to<= /div>
     accomplish each objective. For example i= f continuous monitoring is a
     priority an= d collectively it takes 3 days to work through all the
 &nbs= p;   objectives, I see no problem with that. We can also keep a f= ew
     sessions "on deck" if all t= he objectives are reached and we complete
    = ; all the scheduled sessions early.

  &n= bsp;  Thoughts?

     Sinc= erely,

     Behalf Of *Kent_Landfield@mcafee.com
<mailto:Kent_Landfield@mca= fee.com>
     *Sent:* Monday, May 07, 2012 4:25 PM
=      *To:* SCAP-DEV
     = *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
     Days: Summer 2012 at MITRE in Bedford, MA
<= div>
     All,

&= nbsp;    I would like to discuss the format for the SCAP Dev= eloper Days that
     seems to be listed belo= w.

     I see this appears to = follow a path we have discussed in the past as
   =   the way not to hold a Dev Days event. We have been trying to get
     away from 'Death by Powerpoint' and back to= the type of event we
     held years ago whe= n we were highly productive. In the past we had a
  &nb= sp;  topic to be discussed and a time box to work within. That allowed= us
     to have very active brainstorming se= ssions in a high bandwidth
     environment.<= /div>

     At past Summer events we = have got into a pattern of lots of
     power= point, lots of status of the efforts and very little discussion
&= nbsp;    about things that need active discussions. We need = to keep moving
     forward and making progre= ss as an effort. We can get status from
     = various places such as the lists, a presentation being sent out in
     advance, a webinar if it is felt there will be q= uestions and answers
     from those that are= new to the efforts. We have a limited amount of
  &nbs= p;  time and all who are attending are investing a great deal of time<= /div>
     and money to be there. We should not be = spending a great deal of
     time reeducatin= g everyone when we could be focused on advancing
  &nbs= p;  needed efforts.

     = The type of approach to a Dev Days event was discussed at the last
     Summer Dev Days. I have seen the following work = quite well in other
     efforts.
<= br>
      1. Presentations are sent= out to the attendees and the lists a week
   &nbs= p;     in advance.
    &n= bsp; 2. Status for any effort is limited to 30 minutes
 = ;     3. Focused brainstorming time should be esta= blished for certain
       &nb= sp; areas that need real work by the community
   =    4. Efforts to be discussed should be based on needs of th= e security
         autom= ation space to move existing efforts to completion.

     For example:

 &nbs= p;   Continuous monitoring is a major direction the efforts are b= ecoming
     involved with. There are going t= o be things we need to do as a
     security = automation community to be able to accomplish what is
  = ;   listed in the CAESARS FE. There are interfaces that need to b= e
     worked and established. That is one ar= ea that is not listed below.
     CM will hav= e a major impact on all of us in the next couple years
 &nbs= p;   and it is being ignored. We can't keep trying to solve what = has
     already been solved. We need to addr= ess the needed interface
     development now= . This is an effort that could take nearly a whole
  &n= bsp;  day by itself.

    = Operationally we have a real need to be able to deliver SCAP content
=
     internally within an organization. Today the = SCAP vendors cannot
     share a single local= site security policy (XCCDF + OVAL + CPE +.)
 &= nbsp;   without the site staff having to go to each of the indivi= dual
     products and figuring out how to in= ject that new or updated policy
     into tha= t products delivery mechanisms. That is limiting sites from
 = ;    wanting to buy multiple focused SCAP products since the= y are such a
     pain to manage from a conte= nt perspective. It is easier to buy from
    = one vendor that has a single means for distributing content than it
<= div>     is to deal with the management issues that hav= ing multiple SCAP
     products presents. We = need to have at least an entire 1/2 a day on
   &n= bsp; the development of a Content Repository specification.

<= /div>
     OCIL is a positive and a negative at the= same time. It has real
     value that is be= ing underutilized and under implemented because of
  &n= bsp;  the limitations of how it addresses uses in an enterprise
<= div>     environment. People don't need security automa= tion to do things
     on/for a single host. = They need security automation to focus on the
   &= nbsp; enterprise issues that reduce their costs and improve their
     efficiencies. OCIL is failing in the enterprise a= nd we all
     understand that. We need to ad= dress developing a definitive solution
     f= or incorporating OCIL into the enterprise and that means into the
     existing specifications. Scheduling and tracking = are key to it's
     success. We need to make= that happen. This too needs a focused
     b= rainstorming time box to discuss options.

 &n= bsp;   I am really disappointed that Remediation is not on the li= st below.
     Yes, last Summer Dev Days, the= time spent on Remediation was wasted
     ti= me but that does not mean we should ignore it and not try to make
     some real progress. As far as I am concerned we n= eed to reboot the
     remediation effort. We= cannot keep being the set of specifications /
   =   tools that act as the little boy crying "Wolf" in the nigh= t. We need
     to be able to find and fix is= sues if we are going to really make a
     di= fference in organizational security postures. But today we think
=      it is too hard so we don't try ? I think we need a= couple hours to
     discuss the reboot of t= he effort even if that means minimizing work
   &n= bsp; already done.

     A focu= sed discussion on enterprise reporting is also critically
 &= nbsp;   needed. For the vendors here, we have all gone through th= e
     Cyberscope goat rope, delivering limit= ed capabilities to specific
     data call re= quirements of the Federal Agencies. The initial effort
 &nbs= p;   was a mess, did little more than prove it was possible and c= ause the
     vendor community a great deal o= f thrashing to put a kludgey
     'solution' = in place. Reality is all our customers need roll up
  &= nbsp;  reporting and an infrastructure that supports it. A data call s= hould
     not be special to anyone other tha= n the agencies responding. The
     tools sho= uld be able to select the types of data needed and deliver
 =     that on a scheduled basis automatically. Enterprise Repo= rting
     pertains to commercial as well as = Federal customers. We need to
     focus some= time on what that would look like using the ARF and ASR
 &n= bsp;   as the foundational pieces. But there are missing pieces..= We need
     this discussed.

<= /div>
     I would hope we can make this summer's S= CAP Dev Days useful in
     advancing the sec= urity automation efforts by addressing some of the
  &n= bsp;  more critical issues our customers are facing now or will be fac= ing
     in the very short term. Status prese= ntations are not interesting to
     those ac= tive in the efforts. Let's try to do those before we get to
 = ;    Bedford so we can real make some progress while we are = all in the
     same room. This is always a b= ig event for the 'consensus of the
     willi= ng' that assemble and driven to see security automation make a
&n= bsp;    difference. Let's see if we can have an event that, = when we all walk
     out the last day, we al= l feel that every minute was well spent and
   &nb= sp; moves us forward.

     Tha= nks.

     *Kent Landfield*
     Director Content Strategy, Architecture and= Standards

     *McAfee | An I= ntel Company*
     5000 Headquarters Dr.
     Plano, Texas 75024

=      Direct: +1.972.963.7096
  =    Mobile: +1.817.637.8026
    = *Web: *www.mcafee.com <http://www.mc= afee.com/>

     *From: = *<Boczenowski>, Steve <sbocz= eno@MITRE.ORG
&nb= sp;    *Reply-To: *"OVAL Developer List (Closed Public = Discussion)"
     *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
&= nbsp;    *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Autom= ation Developer
     Days: Summer 2012 at MIT= RE in Bedford, MA

     &n= bsp;   Frank;

    &n= bsp;    We hope to have the registration site up next week. = The event
         will b= e during the week of July 9 - starting Monday at 10:00 AM
 &= nbsp;       and ending on Friday at 12:00.

         Mea= nwhile, we are working on the agenda and are currently
 &nbs= p;       considering this list of topics:

         CCE<= /div>

         C= PE/SWID

       =   CEE

      &nb= sp;  XCCDF

     &nbs= p;   OVAL

     =     ASR

    &nb= sp;    Enterprise OCIL

  =        CybOX/MAEC

&n= bsp;        Federated Content Repository= Spec

       &n= bsp; Endpoint Reporting for Continuous Monitoring and Compliance
= (ERCC)

       =   MILE

      &n= bsp;  TAXII

     &nb= sp;   IF-M for SCAP

   &n= bsp;     IF-MAP

  &n= bsp;      SCAP Releases

&= nbsp;        SCAP and IETF
         NETCONF and SC= AP

        = ; Steve

       =   *From:*Frank Lindsay Acker [mailt= o:afrank@NOVA.EDU]
       =   *Sent:* Tuesday, May 01, 2012 9:32 AM
   &n= bsp;     *To:* oval-developer-list OVAL Developer List/= Closed Public
         Di= scussion
         *Subjec= t:* Re: [OVAL-DEVELOPER-LIST] Security Automation
  &nb= sp;      Developer Days: Summer 2012 at MITRE in B= edford, MA

      &nb= sp;  Steve....

     =     Has there been any additional information regarding this= event?

       =   Thanks,
         F= rank Acker


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

  = ;       *From:*Boczenowski, Steve [sboczeno@MITRE.ORG
  &n= bsp;      <mailto:sboczeno@MITRE.ORG>]
    =      *Sent:* Tuesday, March 20, 2012 16:38
&n= bsp;        *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
        = *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer
&= nbsp;        Days: Summer 2012 at MITRE = in Bedford, MA

      = ;   Save the Date: week of July 9, 2012

=          This year's MITRE-hosted S= ecurity Automation Developer Days
     &= nbsp;   event will be held during the week of July 9, 2012 at MIT= RE's
         facility in= Bedford, MA.

      =    Details to follow.

   =       Regards,

 &nbs= p;       Steve

 = ;        _______________________________= _______________

     &nbs= p;   /Stephen P. Boczenowski/

 &nbs= p;       The MITRECorporation

<= /div>
         Office: (781) 27= 1-7682

       &= nbsp; Cell: (978) 302-3849


      &= nbsp;  To unsubscribe, send an email message to
  =        SIGNOFF OVAL-DEVELOPER-LIST in the BOD= Y of the message. If you
      &nbs= p;  have difficulties, write to

     &n= bsp;   To unsubscribe, send an email message to
 &= nbsp;       SIGNOFF OVAL-DEVELOPER-LIST in th= e BODY of the message. If you
      = ;   have difficulties, write to

    &nb= sp;    To unsubscribe, send an email message to
&n= bsp;        SIGNOFF OVAL-DEVELOPER-LIST = in the BODY of the message. If you
     =     have difficulties, write to
         <mailto:OVAL-DEVELOPER-LIST-reque= st@LISTS.MITRE.ORG>.



_______________________________________________
sacm ma= iling list
sacm@ietf.org
________________= _______________________________
sacm mailing list

__________________________________________= _____
sacm mailing list
________= _______________________________________
sacm mailing list
sacm@ietf.org

= --_000_CBD6C4B432F3Ckentlandfieldmcafeecom_-- From kathleen.moriarty@emc.com Mon May 14 12:40: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 3B5A321F88AD for ; Mon, 14 May 2012 12:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.937 X-Spam-Level: X-Spam-Status: No, score=-9.937 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu-1pl+x10OM for ; Mon, 14 May 2012 12:39:59 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8686321F88AB for ; Mon, 14 May 2012 12:39:58 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4EJdtVA024405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2012 15:39:56 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 14 May 2012 15:39:37 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4EJdaAg027461; Mon, 14 May 2012 15:39:37 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Mon, 14 May 2012 15:39:36 -0400 From: To: , , Date: Mon, 14 May 2012 15:39:35 -0400 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0yBve8CAhpagtWQiqKXSDjuJgFzgAAVd7g 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_AE31510960917D478171C79369B660FA0E969C0B72MX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: turners@ieca.com Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 19:40:14 -0000 --_000_AE31510960917D478171C79369B660FA0E969C0B72MX06Acorpemcc_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sean - please do chime in. My .02: When MILE was INCH, the WG had thought SOAP and BEEP were good so= lutions to fit the protocol (so the WG can drive what they think is needed)= . But the IETF saw that the direction at the time was HTTPS, which would s= eem to agree with the statement below. There really were not many BEEP imp= lementations, so it didn't seem practical even if the protocol design was a= better fit. REST wasn't popular then, so we also took the approach to sep= arate out the protocol from the binding to allow for changes later (add new= bindings). With this approach, you can build in the security at the proto= col so that you don't rely fully on the binding for authentication and encr= yption. Discussions in some WGs have been debating XML or JSON and there are 2 camp= s here, but the theory of having a data model approach and selecting one fo= r the WG seems to be the go-forward decision. Best regards, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, May 14, 2012 3:24 PM To: SCAP-DEV@nist.gov; sacm@ietf.org Cc: turners@ieca.com Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development Hi Sean, Can you help here? I too have heard that but I want to make sure we are no= t being confused by hearsay... Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > To: "bchandra@secpod.com" >, SCAP-DEV >, "sacm@ietf.org" > Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development One problem with SOAP web services is that they are often considered very h= eavy weight. From what I have seen, the IETF tends to prefer lighter weigh= t protocols (e.g. REST, standardized messages over HTTP, etc). Anyone else= have any insights on this? Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Chandrashekhar B Sent: Saturday, May 12, 2012 2:43 AM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development Having a standard access interface is really important for content reposito= ry. I had proposed a simple WSDL in a presentation I shared with Kent, last= year's ITSAC. We are looking forward to take active participation in it. Thanks, Chandra. www.secpod.com -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 11, 2012 11:33 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development It would be great to have as many of these considerations as possible in mi= nd from the start as the actual work begins. As another example, I'd like = to see active participation from vendors that have commercial content repos= itories so those concerns also don't have to be later addressed with major = changes. But we also see a lot of these type of topics come up on the lists, get dis= cussed for a bit, then languish. If reducing the problem set is what it ta= kes to spur some action, let's get started. It kinda sounds like this is headed towards having a dedicated working grou= p to take it on, which is what I'd prefer to see, so I'm avoiding making sp= ecific comments until then. And my apologies to Dave: I'd like to see how much you've already addresse= d, but I just haven't had a chance to look through your draft yet. --gun ThreatGuard, Inc. On 5/11/2012 1:13 PM, Waltermire, David A. wrote: Kent, I have already started work on a draft specification in this area. My hope is that this work could be used as an initial draft within SACM at the appropriate time. Count me in. I mostly agree with what you are describing below. The only area I disagree with is in regards to federation. If we do not implement the specification for an organizational repository in the right way, we may need to make major changes to support federation. This is not good for anyone. In my mind these two concepts cannot be decoupled. We need to insure that any work towards supporting an organizational repository provides a foundation for supporting a federated repository netw= ork. Imagine if DNS was designed with a single organization mindset first without thinking about federation. Top Level Domains (TLDs) and subdomains would not likely exist as concepts. An individual DNS server would likely not support caching, time-to-live and delegating capabilities that are necessary for federation to happen. All of these things would need to be retrofitted. To prevent this, we need to address the building blocks of federation in the basic design. Sincerely, Dave *From:*Kent_Landfield@McAfee.com [mailto= :Kent_Landfield@McAfee.com] *Sent:* Friday, May 11, 2012 12:36 PM *To:* m.kinne@radium.ncsc.mil; Waltermire, = David A.; SCAP-DEV; sacm@ietf.org *Subject:* Request for participants - Content Repository Specification Development Mike I love it when you tee something up like that.. ;-) Thank you. ;) Mike wrote: I still think that any specification for a repository is wishful thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful for everyone. We need to talk more. If you are talking about a holistic, complete federated approach to a content repository, I some what agree. If you are talking about an organizational repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and other related content to be served up inside an organization. Today we have situation where the standards allow us to provide sites the capability to have a single SCAP implemented policy they call official for their environment. Yes this is a rather simplistic since there are things such as targeting specific platforms, specific operational use needs, but for now lets agree SCAP is a massive improvement over the proprietary situations of the past. While we have created this standard content so that sites can implement their local site security once and then assure they are measuring all appropriately targeted devices the same way, we have failed to support the operational needs of th= e sites. We have a situation where no two vendors distribute content the same way. This causes massive problems for the administration staff when they need to incorporate a new SCAP enabled product into their architecture= . They need to discover how the new product supports distributing SCAP content to it's various components. If they have one product then they do this one and they are done. If they have multiple products they will have to figure out how to minimize the impact by incorporating the update process for the new product into the existing SCAP security content processes. Now when the inevitable happens and the site staff needs to make a change to their security policy, they have to make the modifications to the benchmark or checks or both and then distribute those updates across their network. For each SCAP enabled product they have in place, they have doubled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Content Distribution. If you think global DNS you have a general frame of reference. The guidance authors need to be able to publish content in an authoritative manner so their content is updated in a timely fashion. This is a much harder problem to solve if there is no local organizational infrastructure to support it. ;) So here is what I am thinking. We should consider addressing these as two separate but integrated efforts. I believe the Organizational Content Repository is the more critical piece that is actually easier to address. The Federated Content Distribution should be a subsequent effort integrating / augmenting the Organizational repository specification. Mike, to your point that we need someone to build one first. That has happened already. I have one as do other vendors but what we don't have is the access specification. Ours are focused on our specific product needs. Additionally there is a company that has developed a commercial SCAP content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I was very impressed. Again, to your point, it = has been done. What is needed to address the initial operational problem is to develop a specification that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site. TO THAT END.. I am requesting participation from those in the community that see the need and want to put in the work to make this specification happen. I have talked to a couple of you but I do not want to assume your participation. If you are interested please contact me so we can get this started. Thanks! *Kent Landfield* Director Content Strategy, Architecture and Standards *McAfee | An Intel Company* 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *, Michael A > *To: *David Waltermire >, S= CAP-DEV >, "sacm@ietf.org " > *Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionable and use it to make decisions, and vote and accomplish things good or bad. I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful for everyone. We need to talk more. -Mike *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] *Sent:* Tuesday, May 08, 2012 10:44 AM *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content repository for use in a production environment. As an open source project, it will be free for use by anyone interested. My thinking is that this project can bridge the gap until commercial solutions are available to augment it. This is a similar path that was followed with DNS (bind) and HTTP (apache). When it is ready for use, I am hoping to use it to host USGCB content. You would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supporting risk management and aspects of continuous monitoring. I would also like to see some discussion on OCIL at Developer Days. With the proposals we will likely have a sense of what needs to be discussed and what we can achieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see it move forward. We just published the draft ASR specification for public comment. This specification supports enterprise aggregate reporting which greatly reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR. It can be used in continuous monitoring applications to support aggregate data reporting needs (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred. As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF. These are good and necessary discussions to have now, but we have a good deal of work to do before we are ready to open up XCCDF. My suggestion is to work on these related areas and then work up change proposals for XCCDF as needed. By that time we should be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has been too long. Sincerely, Dave *From:*Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] *Sent:* Tuesday, May 08, 2012 7:09 AM *To:* SCAP-DEV *Cc:* Waltermire, David A. *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Kent, It's good to read your thoughts, and a realistic actionable approach is indeed needed. Since all the activity hasn't been on the lists a brief 1=AE2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification is today. I've been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is a tough problem and will require funding with a tail, I'm not sure a specification will solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year trying to make it useful in an enterprise environment and will be posting our ideas to the list before developer days it should have already started, we need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I'm making every effort to get it kick started from our perspective. I hope to assist in getting the draft ERI finished this year. We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can do some automatic configuration fixes, part of a self healing network concept. It is just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to wait. I didn't think that a move to internationalization should impede efforts to move forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov *From:*scap-dev@nist.gov [mailto:scap-dev@nist.gov] *On Behalf Of *Waltermire, David A. *Sent:* Monday, May 07, 2012 7:09 PM *To:* Multiple recipients of list *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of approach. We would like to see some community discussion around what are the key areas/priorities that the community would like to see discussed at Dev Days. Your topics below look like a good start. The SACM list might be a better venue than the OVAL list for this discussion. For each area we should focus the discussion around developing objectives for each session. The sessions can be time boxed based on what would be a reasonable amount of time to accomplish each objective. For example if continuous monitoring is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that. We can also keep a few sessions "on deck" if all the objectives are reached and we complete all the scheduled sessions early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov *From:*scap-dev@nist.gov [mailto:scap-dev@nist.gov] *On Behalf Of *Kent_Landfield@mcafee.com *Sent:* Monday, May 07, 2012 4:25 PM *To:* SCAP-DEV *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems to be listed below. I see this appears to follow a path we have discussed in the past as the way not to hold a Dev Days event. We have been trying to get away from 'Death by Powerpoint' and back to the type of event we held years ago when we were highly productive. In the past we had a topic to be discussed and a time box to work within. That allowed us to have very active brainstorming sessions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lots of status of the efforts and very little discussion about things that need active discussions. We need to keep moving forward and making progress as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there will be questions and answers from those that are new to the efforts. We have a limited amount of time and all who are attending are investing a great deal of time and money to be there. We should not be spending a great deal of time reeducating everyone when we could be focused on advancing needed efforts. The type of approach to a Dev Days event was discussed at the last Summer Dev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in advance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas that need real work by the community 4. Efforts to be discussed should be based on needs of the security automation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involved with. There are going to be things we need to do as a security automation community to be able to accomplish what is listed in the CAESARS FE. There are interfaces that need to be worked and established. That is one area that is not listed below. CM will have a major impact on all of us in the next couple years and it is being ignored. We can't keep trying to solve what has already been solved. We need to address the needed interface development now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +.) without the site staff having to go to each of the individual products and figuring out how to inject that new or updated policy into that products delivery mechanisms. That is limiting sites from wanting to buy multiple focused SCAP products since they are such a pain to manage from a content perspective. It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having multiple SCAP products presents. We need to have at least an entire 1/2 a day on the development of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that is being underutilized and under implemented because of the limitations of how it addresses uses in an enterprise environment. People don't need security automation to do things on/for a single host. They need security automation to focus on the enterprise issues that reduce their costs and improve their efficiencies. OCIL is failing in the enterprise and we all understand that. We need to address developing a definitive solution for incorporating OCIL into the enterprise and that means into the existing specifications. Scheduling and tracking are key to it's success. We need to make that happen. This too needs a focused brainstorming time box to discuss options. I am really disappointed that Remediation is not on the list below. Yes, last Summer Dev Days, the time spent on Remediation was wasted time but that does not mean we should ignore it and not try to make some real progress. As far as I am concerned we need to reboot the remediation effort. We cannot keep being the set of specifications / tools that act as the little boy crying "Wolf" in the night. We need to be able to find and fix issues if we are going to really make a difference in organizational security postures. But today we think it is too hard so we don't try ? I think we need a couple hours to discuss the reboot of the effort even if that means minimizing work already done. A focused discussion on enterprise reporting is also critically needed. For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of the Federal Agencies. The initial effort was a mess, did little more than prove it was possible and cause the vendor community a great deal of thrashing to put a kludgey 'solution' in place. Reality is all our customers need roll up reporting and an infrastructure that supports it. A data call should not be special to anyone other than the agencies responding. The tools should be able to select the types of data needed and deliver that on a scheduled basis automatically. Enterprise Reporting pertains to commercial as well as Federal customers. We need to focus some time on what that would look like using the ARF and ASR as the foundational pieces. But there are missing pieces.. We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing the security automation efforts by addressing some of the more critical issues our customers are facing now or will be facing in the very short term. Status presentations are not interesting to those active in the efforts. Let's try to do those before we get to Bedford so we can real make some progress while we are all in the same room. This is always a big event for the 'consensus of the willing' that assemble and driven to see security automation make a difference. Let's see if we can have an event that, when we all walk out the last day, we all feel that every minute was well spent and moves us forward. Thanks. *Kent Landfield* Director Content Strategy, Architecture and Standards *McAfee | An Intel Company* 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *, Steve > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG " > *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be during the week of July 9 - starting Monday at 10:00 AM and ending on Friday at 12:00. Meanwhile, we are working on the agenda and are currently considering this list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU] *Sent:* Tuesday, May 01, 2012 9:32 AM *To:* oval-developer-list OVAL Developer List/Closed Public Discussion *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ------------------------------------------------------------------------ *From:*Boczenowski, Steve [sboczeno@MITRE.ORG ] *Sent:* Tuesday, March 20, 2012 16:38 *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year's MITRE-hosted Security Automation Developer Days event will be held during the week of July 9, 2012 at MITRE's facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ /Stephen P. Boczenowski/ The MITRECorporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG . To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG . To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG . _______________________________________________ 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 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_AE31510960917D478171C79369B660FA0E969C0B72MX06Acorpemcc_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Sean – please do chime in.

 

My .02:=A0=A0 When MILE was INCH, the WG had thought SOAP and BEEP were go= od solutions to fit the protocol (so the WG can drive what they think is ne= eded).=A0 But the IETF saw that the direction at the time was HTTPS, which = would seem to agree with the statement below.=A0 There really were not many= BEEP implementations, so it didn’t seem practical even if the protoc= ol design was a better fit.=A0 REST wasn’t popular then, so we also t= ook the approach to separate out the protocol from the binding to allow for= changes later (add new bindings).=A0 With this approach, you can build in = the security at the protocol so that you don’t rely fully on the bind= ing for authentication and encryption.

 

Disc= ussions in some WGs have been debating XML or JSON and there are 2 camps he= re, but the theory of having a data model approach and selecting one for th= e WG seems to be the go-forward decision.

 

Bes= t regards,

Kathleen

 

From: sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: = Monday, May 14, 2012 3:24 PM
To: SCAP-DEV@nist.gov; sacm@ietf.org=
Cc: turners@ieca.com
Subject: Re: [sacm] Request for p= articipants - Content Repository Specification Development

 

<= p class=3DMsoNormal>Hi Sean,<= /p>

 <= /o:p>

Can you help here?  I too have heard that but I want to make sure we = are not being confused by hearsay…

 

=

Thanks.

<= o:p> 

Kent Landfield
Direc= tor Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.<= br>Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

<= /div>

 = ;

From: = <Waltermire>, David Waltermire <david.waltermire@nist.gov>
To: "<= a href=3D"mailto:bchandra@secpod.com">bchandra@secpod.com" <bchandra@secpod.com>, SCAP-DEV &= lt;SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Reques= t for participants - Content Repository Specification Development

 

One problem with SOAP web services= is that they are often considered very heavy weight.  From what = I have seen, the IETF tends to prefer lighter weight protocols (e.g. REST, = standardized messages over HTTP, etc).  Anyone else have any insi= ghts on this?

 

Sincerely,

Dave

 

<= o:p> 

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

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Chandrashekhar B

Sent: Saturday, May 12, 2012 2:43 AM

<= p class=3DMsoNormal>To: SCAP-DEV; sacm@ietf.org

Subject: Re: [sacm] Request for= participants - Content Repository Specification Development

&nb= sp;

Having a standard access interface is really important for content rep= ository. I had proposed a simple WSDL in a presentation I shared with Kent,= last year's ITSAC. We are looking forward to take active participation in = it.

 

Thanks,

Chandra.

www.secpod.com

 

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

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach

Sent: Friday, May 11, 2012 11:33 PM

Cc: SCAP-DEV; sacm@ietf.org

Subject: Re: [sacm] Request for p= articipants - Content Repository Specification Development

 = ;

 

It would be great to have as many of these considerations = as possible in mind from the start as the actual work begins.  As= another example, I'd like to see active participation from vendors that ha= ve commercial content repositories so those concerns also don't have to be = later addressed with major changes.

 

But we also see a lo= t of these type of topics come up on the lists, get discussed for a bit, th= en languish.  If reducing the problem set is what it takes to spu= r some action, let's get started.

 

=

It kinda sounds like = this is headed towards having a dedicated working group to take it on, whic= h is what I'd prefer to see, so I'm avoiding making specific comments until= then.

 

And my apologies to Dave:  I'd like to = see how much you've already addressed, but I just haven't had a chance to l= ook through your draft yet.

 

 

=

 

--= gun

 

ThreatGuard, Inc.

 

=

 

On= 5/11/2012 1:13 PM, Waltermire, David A. wrote:

=

K= ent,

 

I have already started work on a draft specificatio= n in this area.  My

hope is that this work could be used as= an initial draft within SACM

at the appropriate time.  Cou= nt me in.

 

I mostly agree with what you are describing b= elow.  The only area I

disagree with is in regards to fed= eration.  If we do not implement the

<= div>

specification for an o= rganizational repository in the right way, we

may need to make major = changes to support federation.  This is not

=

good for anyone= .  In my mind these two concepts cannot be decoupled.<= /span>

We ne= ed to insure that any work towards supporting an organizational<= /span>

repos= itory provides a foundation for supporting a federated repository network.<= o:p>

Imagine if DNS was designed with a single organization mindset first<= o:p>

without thinking about federation.  Top Level Domains (TLDs= ) and

subdomains would not likely exist as concepts.  An in= dividual DNS

server would likely not support caching, time-to-live an= d delegating

capabilities that are necessary for federation to happen= .  All of

these things would need to be retrofitted. &= nbsp;To prevent this, we need

to address the building blocks of feder= ation in the basic design.

 

Sincerely,<= /p>

 <= /o:p>

Dave

 

<= p class=3DMsoNormal>*Sent:* Friday, May 11, 201= 2 12:36 PM

*To:* m.kinne@r= adium.ncsc.mil; Waltermire, David A.; SCAP-DEV;

<= 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">

*S= ubject:* Request for participants - Content Repository Specification

= Development

 

Mike I love it when you tee something up lik= e that.. ;-) Thank you. ;)

 

Mike wrote:=

 =

I still think that any specification for a repository is wishful

th= inking until someone builds one and learns the lessons it will just

b= e another whitepaper spec. I believe the DoD needs to incorporate a

m= etadata repository as part of it and other customizations that may

no= t be useful for everyone.

 

We need to talk more.

 

If you are talking about a holistic, complete federated approach= to a

content repository, I some what agree. If you are talking about= an

organizational repository, I totally disagree. But you knew I wou= ld.

;)

 

Here is how I see the problem. There is an = immediate need for SCAP and

other related content to be served up ins= ide an organization. Today we

have situation where the standards allo= w us to provide sites the

capability to have a single SCAP implemente= d policy they call official

for their environment. Yes this is a rath= er simplistic since there are

things such as targeting specific platf= orms, specific operational use

needs, but for now lets agree SCAP is = a massive improvement over the

proprietary situations of the past. Wh= ile we have created this

standard content so that sites can implement= their local site security

once and then assure they are measuring al= l appropriately targeted

devices the same way, we have failed to supp= ort the operational needs of the sites.

We have a situation where no = two vendors distribute content the same

way. This causes massive prob= lems for the administration staff when

they need to incorporate a new= SCAP enabled product into their architecture.

<= div>

They need to discover = how the new product supports distributing SCAP

<= div>

content to it's variou= s components. If they have one product then they

do this one and they= are done. If they have multiple products they

<= div>

will have to figure ou= t how to minimize the impact by incorporating

the update process for = the new product into the existing SCAP security

=

content processes. No= w when the inevitable happens and the site staff

needs to make a chan= ge to their security policy, they have to make the

modifications to t= he benchmark or checks or both and then distribute

those updates acro= ss their network. For each SCAP enabled product they

<= /div>

have in place, t= hey have doubled, tripled or more the work needed to

<= /div>

make those updat= es available.

 

There is another content repository proble= m and that is the Federated

Content Distribution. If you think global= DNS you have a general frame

of reference. The guidance authors need= to be able to publish content

in an authoritative manner so their co= ntent is updated in a timely fashion.

This is a much harder problem t= o solve if there is no local

organizational infrastructure to support= it. ;)

 

<= span style=3D'color:black'>So here is what I am thinking. We should conside= r addressing these as

= two separate but integrated efforts. I believe = the Organizational

Content Repository is the more critical piece that= is actually easier

to address. The Federated Content Distribution sh= ould be a subsequent

<= span style=3D'color:black'>effort integrating / augmenting the Organization= al repository

specification.

 

=

Mike, to your point t= hat we need someone to build one first. That has

happened already. I = have one as do other vendors but what we don't

<= div>

have is the access spe= cification. Ours are focused on our specific

product needs. Additiona= lly there is a company that has developed a

commercial SCAP content r= epository that will be announced later this

month. I won't steal thei= r thunder but I was recently given a sneak

=

peek at it and I must admi= t I was very impressed. Again, to your point, it has been done.<= /span>

What = is needed to address the initial operational problem is to

develop a = specification that provides a consistent means for all SCAP

products = to retrieve the appropriate content as configured and managed

but the=

site.

 

TO THAT EN= D..

 

I am requesting participation from those in the comm= unity that see the

need and want to put in the work to make this spec= ification happen. I

have talked to a couple of you but I do not want = to assume your

participation. If you are interested please contact me= so we can get

this started.

 

=

Thanks!

&n= bsp;

*Kent Landfield*

Director Content Strategy, Architecture and St= andards

 

<= span style=3D'color:black'>*McAfee | An Intel Company*

5000 Headquart= ers Dr.

Plano, Texas 75024

 

=

Direct: +1.972.963.70= 96

Mobile: +1.817.637.8026

*Web: *www.mcafee.com <http://www.mcafee.com/>

 = ;

*From: *<Kinney>, Michael A <m.kinne@radium.ncsc.mil

*To: *Da= vid Waltermire <david.walte= rmire@nist.gov

<mailto:SCAP-DEV@nist.gov>>, "sacm@ietf.org <mailto:sacm@ietf.org>"

*Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] S= ecurity Automation

Developer Days: Summer 2012 at MITRE in Bedford, M= A

 

     Dave,

 =

&nbs= p;    I have no problem with webinars, I do want to keep dev= eloper days

     actionable and use it to make de= cisions, and vote and accomplish

     things go= od or bad. I do not want this to be an informational

<= /div>

  &nbs= p;  briefing conference.

 

=

     T= hanks for the links.

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

     I still t= hink that any specification for a repository is wishful

  &= nbsp;  thinking until someone builds one and learns the lessons it wil= l

     just be another whitepaper spec. I believe= the DoD needs to

     incorporate a metadata rep= ository as part of it and other

     customizatio= ns that may not be useful for everyone.

 

<= /div>

  &nbs= p;  We need to talk more.

 

     = -Mike

 

     *From:*Waltermire, David = A. [mailto:david.waltermire@ni= st.gov]

     *Sent:* Tuesday, May 08, 2012 10= :44 AM

     *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org

     *Subject:* RE: [OVAL-DEVELOPER-LIST] Sec= urity Automation Developer

     Days: Summer 2012= at MITRE in Bedford, MA

 

     Mike,<= o:p>

 

     What about having webinars in-p= lace of the 30 minute briefs?

 

=

     R= egarding content management, we are building the prototype content

&n= bsp;    repository for use in a production environment. As a= n open source

     project, it will be free for u= se by anyone interested. My thinking

     is that= this project can bridge the gap until commercial solutions

 &nb= sp;   are available to augment it. This is a similar path that wa= s

     followed with DNS (bind) and HTTP (apache)= . When it is ready for

     use, I am hoping to u= se it to host USGCB content. You would be

<= p class=3DMsoNormal>     we= lcome to use it for your needs.

 

    = It is good that OCIL is moving forward. This is an important piece

&= nbsp;    of supporting risk management and aspects of contin= uous monitoring.

     I would also like to see so= me discussion on OCIL at Developer Days.

     Wit= h the proposals we will likely have a sense of what needs to be<= /span>

 = ;    discussed and what we can achieve consensus on outside = the meeting.

 

     Remediation is a t= opic near and dear to my heart. I too would like

   &n= bsp; to see it move forward.

 

<= p class=3DMsoNormal>     We= just published the draft ASR specification for public comment.<= /span>

 = ;    This specification supports enterprise aggregate report= ing which

     greatly reduces the data volumes = needed verses detailed host-based

     reports. = This specification has been designed as a more robust

=

  &nb= sp;  replacement for LASR. It can be used in continuous monitoring

     applications to support aggregate data reportin= g needs (e.g. FISMA

     reporting, CyberScope).<= o:p>

 

     Here are the links:<= /span>

=  

 

 

   &= nbsp; The primary reason we have suggested waiting on XCCDF is not the=

     internationalization issue. Many vendors have co= mmented that they

     are still working on imple= menting the XCCDF 1.2.1 specification. We

<= p class=3DMsoNormal>     wi= ll be in a better place in a few months once more development

 &= nbsp;   around XCCDF has occurred. As we consider changes to the = SCAP stack

     to address OCIL and other issues,= we will identify areas that need

     improveme= nt in XCCDF. These are good and necessary discussions to<= /p>

  =    have now, but we have a good deal of work to do before we are = ready

     to open up XCCDF. My suggestion is to = work on these related areas

     and then work up= change proposals for XCCDF as needed. By that time

   = ;  we should be ready to work on a new revision of XCCDF.

&= nbsp;

     I am also looking forward to the discussion= s at the conference. It

     has been too long.

 

     Sincerely,

=

 

&n= bsp;    Dave

 

     *Fr= om:*Kinney, Michael A [mailto:m.= kinne@radium.ncsc.mil]

     *Sent:* Tuesday, = May 08, 2012 7:09 AM

<= span style=3D'color:black'>     *To:* SCAP-DEV

&n= bsp;    *Cc:* Waltermire, David A.

   &= nbsp; *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer

     Days: Summer 2012 at MITRE in Bedford, MA=

 

     Kent,

=

 

 &n= bsp;   It's good to read your thoughts, and a realistic actionabl= e approach

     is indeed needed. Since all the a= ctivity hasn't been on the lists a

     brief 1= =AE2 hour recap may be in order to bring everyone up to speed

 &= nbsp;   since there has been a lot of activity on CPE/SWID, OCIl,= MAEC/CybOX

     CEE and others.

 = ;

     We could write a content repository specificati= on, but without

     someone willing to stand one= up it will be as valuable as the CCSS

     speci= fication is today. I've been trying for two years to get my

 &nb= sp;   management to get a coordinated effort together for the DoD= to stand

     up a repository, it is a tough pr= oblem and will require funding with

     a tail, = I'm not sure a specification will solve that problem.

=

 

&n= bsp;    We (DoD) have been putting a lot of effort into OCIL= over the last

     year trying to make it useful= in an enterprise environment and will

     be po= sting our ideas to the list before developer days it should

 &nb= sp;   have already started, we need to get consensus and a vote o= n how the

     community wishes to proceed.=

 

     Remediation is stalled but I'm ma= king every effort to get it kick

     started f= rom our perspective. I hope to assist in getting the draft

 &nbs= p;   ERI finished this year. We are writing some new STIG content= and

     intend to used the draft CRE specificat= ion to insert CRE into the

     content so we (Do= D) can do some automatic configuration fixes, part

   =   of a self healing network concept. It is just a start but the best

     we can do at this point.

 

&= nbsp;    Enterprise reporting is an interesting subject, sin= ce XML adds size

     to and content to roll up r= eporting, in any enterprise of size the

     prob= lem gets greater, I look forward to your thoughts on that subject.

 

     I am concerned that the internationaliz= ation efforts are detracting

     from efforts to= meet use cases, we have some things we would like

   =   changed in XCCDF to support our OCIl use case and I have been told

     that I need to wait. I didn't think that a mo= ve to

     internationalization should impede eff= orts to move forward with use

     cases.

<= o:p> 

     I look forward to talking with you at = the conference.

 

     v/r<= /span>

=  

     Mike Kinney

 =

  = ;   Project Director

 

     = Computer Network Defense Research and Technology (CND R&T) Office<= /o:p>

 

     9800 Savage Road Ste 6767=

&nbs= p;    Ft Meade, MD 20755-6767

    = Phone: 410-854-4422

<= span style=3D'color:black'>     NSTS: 968-8886

&n= bsp;    Fax 410-854-4681

 

<= /div>

 

     Behalf Of *Waltermire, David A.

=      *Sent:* Monday, May 07, 2012 7:09 PM

 &= nbsp;   *To:* Multiple recipients of list

   = ;  *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer<= o:p>

     Days: Summer 2012 at MITRE in Bedford, MA

 

     Kent,

=

 

 &n= bsp;   I like what you are saying here. We are also in support of= this type

     of approach. We would like to see= some community discussion around

     what are = the key areas/priorities that the community would like to=

  = ;   see discussed at Dev Days. Your topics below look like a good= start.

     The SACM list might be a better venu= e than the OVAL list for this

     discussion. Fo= r each area we should focus the discussion around

   &= nbsp; developing objectives for each session. The sessions can be time=

     boxed based on what would be a reasonable amount= of time to

     accomplish each objective. For e= xample if continuous monitoring is a

     priorit= y and collectively it takes 3 days to work through all the

 &nbs= p;   objectives, I see no problem with that. We can also keep a f= ew

     sessions "on deck" if all the o= bjectives are reached and we complete

     all th= e scheduled sessions early.

 

     Tho= ughts?

 

     Sincerely,

&n= bsp;

     David Waltermire

=

 

 &n= bsp;   SCAP Architect

 

    = National Institute of Standards and Technology

=

 

 &n= bsp;   (301) 975-3390

 

    = david.waltermire@nist.gov= <mailto:david.waltermire@n= ist.gov>

 

     *From:*scap-dev@nist.gov <mailto:scap-dev@nist.gov>

<= /div>

     Behalf Of *Kent_Landfield@mcafee.com

    = *Sent:* Monday, May 07, 2012 4:25 PM

     *To:* = SCAP-DEV

     *Subject:* Re: [OVAL-DEVELOPER-LI= ST] Security Automation Developer

     Days: Sum= mer 2012 at MITRE in Bedford, MA

 

=

   &nb= sp; All,

 

     I would like to disc= uss the format for the SCAP Developer Days that

=

   &nb= sp; seems to be listed below.

 

=

     I= see this appears to follow a path we have discussed in the past as

&= nbsp;    the way not to hold a Dev Days event. We have been = trying to get

     away from 'Death by Powerpoint= ' and back to the type of event we

     held year= s ago when we were highly productive. In the past we had a

 &nbs= p;   topic to be discussed and a time box to work within. That al= lowed us

     to have very active brainstorming= sessions in a high bandwidth

     environment.

 

     At past Summer events we have go= t into a pattern of lots of

     powerpoint, lots= of status of the efforts and very little discussion

<= /div>

  &nbs= p;  about things that need active discussions. We need to keep moving<= o:p>

     forward and making progress as an effort. We= can get status from

<= span style=3D'color:black'>     various places such as = the lists, a presentation being sent out in

     = advance, a webinar if it is felt there will be questions and answers

=      from those that are new to the efforts. We have a = limited amount of

     time and all who are atten= ding are investing a great deal of time

     and = money to be there. We should not be spending a great deal of

 &n= bsp;   time reeducating everyone when we could be focused on adva= ncing

     needed efforts.

<= /div>

 

&nb= sp;    The type of approach to a Dev Days event was discusse= d at the last

     Summer Dev Days. I have seen t= he following work quite well in other

     effort= s.

 

      1. Presentations = are sent out to the attendees and the lists a week

   =       in advance.

=

    &n= bsp; 2. Status for any effort is limited to 30 minutes

 &nb= sp;    3. Focused brainstorming time should be establis= hed for certain

         area= s that need real work by the community

     =  4. Efforts to be discussed should be based on needs of the security

         automation space to m= ove existing efforts to completion.

 

   &n= bsp; For example:

 

     Continuous mo= nitoring is a major direction the efforts are becoming

  &n= bsp;  involved with. There are going to be things we need to do as a

     security automation community to be able to a= ccomplish what is

     listed in the CAESARS FE. = There are interfaces that need to be

     worked = and established. That is one area that is not listed below.

 &nb= sp;   CM will have a major impact on all of us in the next couple= years

     and it is being ignored. We can't kee= p trying to solve what has

     already been solv= ed. We need to address the needed interface

     = development now. This is an effort that could take nearly a whole

&nb= sp;    day by itself.

 

   &= nbsp; Operationally we have a real need to be able to deliver SCAP content<= o:p>

     internally within an organization. Today the= SCAP vendors cannot

<= span style=3D'color:black'>     share a single local si= te security policy (XCCDF + OVAL + CPE +.)

=

     w= ithout the site staff having to go to each of the individual

 &n= bsp;   products and figuring out how to inject that new or update= d policy

     into that products delivery mecha= nisms. That is limiting sites from

     wanting t= o buy multiple focused SCAP products since they are such a

 &nbs= p;   pain to manage from a content perspective. It is easier to b= uy from

     one vendor that has a single means f= or distributing content than it

     is to deal w= ith the management issues that having multiple SCAP

   = ;  products presents. We need to have at least an entire 1/2 a day on<= o:p>

     the development of a Content Repository spec= ification.

 

     OCIL is a positive a= nd a negative at the same time. It has real

     = value that is being underutilized and under implemented because of

&n= bsp;    the limitations of how it addresses uses in an enter= prise

     environment. People don't need securit= y automation to do things

     on/for a single ho= st. They need security automation to focus on the

   &= nbsp; enterprise issues that reduce their costs and improve their

&nb= sp;    efficiencies. OCIL is failing in the enterprise and w= e all

     understand that. We need to address de= veloping a definitive solution

     for incorpora= ting OCIL into the enterprise and that means into the

=

  &nb= sp;  existing specifications. Scheduling and tracking are key to it's<= o:p>

     success. We need to make that happen. This t= oo needs a focused

     brainstorming time box to= discuss options.

 

     I am really d= isappointed that Remediation is not on the list below.

  &n= bsp;  Yes, last Summer Dev Days, the time spent on Remediation was was= ted

     time but that does not mean we should ig= nore it and not try to make

     some real progre= ss. As far as I am concerned we need to reboot the

   =   remediation effort. We cannot keep being the set of specifications /=

     tools that act as the little boy crying &qu= ot;Wolf" in the night. We need

     to be ab= le to find and fix issues if we are going to really make a

 &nbs= p;   difference in organizational security postures. But today we= think

     it is too hard so we don't try ? I th= ink we need a couple hours to

     discuss the re= boot of the effort even if that means minimizing work

=

  &nb= sp;  already done.

 

     A focus= ed discussion on enterprise reporting is also critically<= /p>

  =    needed. For the vendors here, we have all gone through the

     Cyberscope goat rope, delivering limited capabi= lities to specific

     data call requirements of= the Federal Agencies. The initial effort

<= p class=3DMsoNormal>     wa= s a mess, did little more than prove it was possible and cause the

&n= bsp;    vendor community a great deal of thrashing to put a = kludgey

     'solution' in place. Reality is all = our customers need roll up

     reporting and an = infrastructure that supports it. A data call should

   = ;  not be special to anyone other than the agencies responding. The

     tools should be able to select the types of da= ta needed and deliver

=      that on a scheduled ba= sis automatically. Enterprise Reporting

     pert= ains to commercial as well as Federal customers. We need to

 &nb= sp;   focus some time on what that would look like using the ARF = and ASR

     as the foundational pieces. But ther= e are missing pieces.. We need

     this discusse= d.

 

     I would hope we can make thi= s summer's SCAP Dev Days useful in

     advancing= the security automation efforts by addressing some of the

 &nbs= p;   more critical issues our customers are facing now or will be= facing

     in the very short term. Status prese= ntations are not interesting to

     those active= in the efforts. Let's try to do those before we get to

  &= nbsp;  Bedford so we can real make some progress while we are all in t= he

     same room. This is always a big event for= the 'consensus of the

     willing' that assembl= e and driven to see security automation make a

<= div>

   &nbs= p; difference. Let's see if we can have an event that, when we all walk

     out the last day, we all feel that every minute= was well spent and

     moves us forward.

=  

     Thanks.

 

 &nbs= p;   *Kent Landfield*

     Director Con= tent Strategy, Architecture and Standards

<= p class=3DMsoNormal> 

  &n= bsp;  *McAfee | An Intel Company*

     5000 = Headquarters Dr.

     Plano, Texas 75024

 

     Direct: +1.972.963.7096

 &nb= sp;   Mobile: +1.817.637.8026

     *Web= : *www.mcafee.com <http://www.mcafee.= com/>

 

     *From: *<Boczen= owski>, Steve <sboczeno@MITRE.O= RG

    = ; *Reply-To: *"OVAL Developer List (Closed Public Discussion)"

     <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG

<= /div>

  &nbs= p;  <mail= to:OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>>

     <<= a href=3D"mailto:OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG%3e">mailto:OVAL-DEVELO= PER-LIST@LISTS.MITRE.ORG>"

     <<= a href=3D"mailto:OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG">OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG

     *Subject: *Re: [OVAL-DEVELO= PER-LIST] Security Automation Developer

     Days= : Summer 2012 at MITRE in Bedford, MA

 

   =       Frank;

 

   =       We hope to have the registration site up nex= t week. The event

         wi= ll be during the week of July 9 - starting Monday at 10:00 AM

 &= nbsp;       and ending on Friday at 12:00.

 

         Meanwhile= , we are working on the agenda and are currently

   &n= bsp;     considering this list of topics:

&n= bsp;

         CCE

 = ;

         CPE/SWID

&nb= sp;

         CEE=

 =

         XCCDF<= /p>

 <= /o:p>

         OVAL

 

&= nbsp;        ASR

 =

&nbs= p;        Enterprise OCIL

&nb= sp;

         CybOX/MAEC=

 

         Federated Content= Repository Spec

 

      &nb= sp;  Endpoint Reporting for Continuous Monitoring and Compliance<= /o:p>

(ERCC)

 

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

 

         T= AXII

 

         IF= -M for SCAP

 

       &n= bsp; IF-MAP

 

       &n= bsp; SCAP Releases

 

      &= nbsp;  SCAP and IETF

 

     =     NETCONF and SCAP

 

   &n= bsp;     Steve

 

=

   &nb= sp;     *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU]

    &= nbsp;    *Sent:* Tuesday, May 01, 2012 9:32 AM

 &= nbsp;       *To:* oval-developer-list OVAL De= veloper List/Closed Public

       =   Discussion

         *S= ubject:* Re: [OVAL-DEVELOPER-LIST] Security Automation

  &n= bsp;      Developer Days: Summer 2012 at MITRE in = Bedford, MA

 

       &n= bsp; Steve....

 

       = ;  Has there been any additional information regarding this event?

 

         Thanks,

         Frank Acker

 

 

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

 

&n= bsp;        *From:*Boczenowski, Steve [<= a href=3D"mailto:sboczeno@MITRE.ORG">sboczeno@MITRE.ORG

 &nb= sp;       <mailto:sboczeno@MITRE.ORG>]

    =      *Sent:* Tuesday, March 20, 2012 16:38

 =         *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG

         *Subject:= * [OVAL-DEVELOPER-LIST] Security Automation Developer

=

  &nb= sp;      Days: Summer 2012 at MITRE in Bedford, MA=

 

         Save t= he Date: week of July 9, 2012

 

=

    &n= bsp;    This year's MITRE-hosted Security Automation Develop= er Days

         event will b= e held during the week of July 9, 2012 at MITRE's

   &= nbsp;     facility in Bedford, MA.

 

&= nbsp;        Details to follow.

 

         Regards,

=  

         Steve

<= o:p> 

         ______________= ________________________________

 

=

   &nb= sp;     /Stephen P. Boczenowski/

<= /div>

 

&nb= sp;        The MITRECorporation

 

         Office: (781) 2= 71-7682

 

<= span style=3D'color:black'>        = Cell: (978) 302-3849

=  

     &nbs= p;   sboczeno@mitre.org= <mailto:sboczeno@mitre.org>= ;

 

         To un= subscribe, send an email message to

      &= nbsp;  SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you<= o:p>

         have difficulties, w= rite to

 

=          To unsubscribe, send an em= ail message to

 

=

   &nb= sp;     To unsubscribe, send an email message to

&nbs= p;        SIGNOFF OVAL-DEVELOPER-LIST in= the BODY of the message. If you

     &nbs= p;   have difficulties, write to

 

 

<= p class=3DMsoNormal> 

______________= _________________________________

sacm mailing list

_______________________________________________

sac= m mailing list

 

=

__________________________= _____________________

= sacm mailing list

sacm@ietf.org

________= _______________________________________

sacm mailing list<= /span>

https://www.ietf.org/mailman/listinfo/sacm<= /a>

= = --_000_AE31510960917D478171C79369B660FA0E969C0B72MX06Acorpemcc_-- From gunnar.engelbach@threatguard.com Mon May 14 13:13: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 69E5821F8880 for ; Mon, 14 May 2012 13:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bfyhQ9QOQKc for ; Mon, 14 May 2012 13:13:10 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id AC0A021F887D for ; Mon, 14 May 2012 13:13:10 -0700 (PDT) Received: (qmail 29404 invoked from network); 14 May 2012 14:16:21 -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); 14 May 2012 14:16:21 -0700 Message-ID: <4FB16756.9020703@ThreatGuard.com> Date: Mon, 14 May 2012 16:13:10 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Multiple recipients of list , "sacm@ietf.org >> \"sacm@ietf.org\"" References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <4FAD544D.2090601@ThreatGuard.com> <04a001cd300a$8c816970$a5843c50$@secpod.com> <4FB15ED8.1000702@redhat.com> In-Reply-To: <4FB15ED8.1000702@redhat.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 20:13:11 -0000 On the other hand, everything else in the SCAP world is XML-based. If repositories also want to interact with non-SCAP content, a good argument could be made for JSON. It would be good to have the options narrowed down to a most likely set so that we've all time to do our research ahead of time. --gun On 5/14/2012 3:51 PM, Kurt Seifried wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/14/2012 01:28 PM, Waltermire, David A. wrote: >> >> One problem with SOAP web services is that they are often >> considered very heavy weight. From what I have seen, the IETF >> tends to prefer lighter weight protocols (e.g. REST, standardized >> messages over HTTP, etc). Anyone else have any insights on this? >> >> Sincerely, Dave > > > I was watching a presentation on cloud public API's (can't find the > link) and the current trend is that REST+JSON is winning (like over > 50%), SOAP/XML are far less popular. I suspect a lot of this is due to > simplicity/practical/resource issues. > > > - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPsV7YAAoJEBYNRVNeJnmT4dYP/1e1FOuKHyFpn3G8mvPZwfSu > z2C2dx32MGQU0ZsOW+9dVuZbvCMQKct2QSTEFCJc31Vrt8cv3w2C4tMXUfuEeDn+ > wbzEa4M3Pu0HHxx+XboaNHCSFKDdXACKcAvSjC1bG+SGcQLpr542BpH+08p987o3 > DgOZAOoA65cUJXep7O+OcvrYwVL/BY/m4aY9ClvwFogKhbn2c7K1nDnMudaPxohS > 7M9WR7sWwMYMVtjfQVGmqDkf+eq8h3aVN+cxjdDGkZVhffBslP3x5LUAtakmGDOw > X34WJYGkKSERVL6PxCAUZUvtLqDN6Zq1AU62RP9RIztKjbPSFckrBXVPXPGyVOLQ > RTFh9YF+zQgX/3C9yhXF7uUMN0SdsN3NVETHwww3CqiwD0Qg4QKFmGritiMU5VVJ > uqX6WXROhqzAgr3nPJe/WbC//ckGKsVO4JOctbQmFzdxK8+HgMqrRUc6KdGJkyWo > JJBdW3D828MgOA0G4emvbWHh1bYlGuacO0I4/t27xQFEZ/UdJMRsEh+7hTAZd16j > OYfMunX9PlpvZFsHmvcMTybIOz3PApz0ob8fzF/vOD7r4VrNHGEqPZF6GyllvLw3 > qxYDGfzeDtaoT5p6V0bptUzAcR3y0DRHQBJTl/Ai2ejTN8K1pYDUBONTGhnkLp10 > jvOC5WFffjgysH0hKE5g > =YuOG > -----END PGP SIGNATURE----- > > --------------------------------------------------------------- > > To unsubscribe from this mailing list, please send an e-mail to > listproc@nist.gov with the words "unsubscribe scap-dev" in the body. You > will need to send this from the email account that you used to initially > subscribe to scap-dev. > From david.waltermire@nist.gov Mon May 14 13:37: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 94EF321F884E for ; Mon, 14 May 2012 13:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITPxdmMsq8Um for ; Mon, 14 May 2012 13:37:00 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8B43D21F88BF for ; Mon, 14 May 2012 13:37:00 -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.355.2; Mon, 14 May 2012 16:36:44 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 14 May 2012 16:35:48 -0400 From: "Waltermire, David A." To: "Gunnar.Engelbach@threatguard.com" , SCAP-DEV , "sacm@ietf.org" Date: Mon, 14 May 2012 16:36:57 -0400 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0yEBbANl19+1NsQcWB/Kzy71X1FgAANJ3Q Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <4FAD544D.2090601@ThreatGuard.com> <04a001cd300a$8c816970$a5843c50$@secpod.com> <4FB15ED8.1000702@redhat.com> <4FB16756.9020703@ThreatGuard.com> In-Reply-To: <4FB16756.9020703@ThreatGuard.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] Request for participants - Content Repository Specification Development 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, 14 May 2012 20:37:01 -0000 Something like this technique could be used to support JSON in XML. http://jsontoxml.utilities-online.info/ Both are hierarchical in nature. Information can be easily marshaled either way. Sincerely, Dave -----Original Message----- From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Gunnar Engelbach Sent: Monday, May 14, 2012 4:27 PM To: SCAP-DEV Subject: Re: [sacm] Request for participants - Content Repository Specification Development On the other hand, everything else in the SCAP world is XML-based. If repositories also want to interact with non-SCAP content, a good argument could be made for JSON. It would be good to have the options narrowed down to a most likely set so that we've all time to do our research ahead of time. --gun On 5/14/2012 3:51 PM, Kurt Seifried wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/14/2012 01:28 PM, Waltermire, David A. wrote: >> >> One problem with SOAP web services is that they are often >> considered very heavy weight. From what I have seen, the IETF >> tends to prefer lighter weight protocols (e.g. REST, standardized >> messages over HTTP, etc). Anyone else have any insights on this? >> >> Sincerely, Dave > > > I was watching a presentation on cloud public API's (can't find the > link) and the current trend is that REST+JSON is winning (like over > 50%), SOAP/XML are far less popular. I suspect a lot of this is due to > simplicity/practical/resource issues. > > > - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPsV7YAAoJEBYNRVNeJnmT4dYP/1e1FOuKHyFpn3G8mvPZwfSu > z2C2dx32MGQU0ZsOW+9dVuZbvCMQKct2QSTEFCJc31Vrt8cv3w2C4tMXUfuEeDn+ > wbzEa4M3Pu0HHxx+XboaNHCSFKDdXACKcAvSjC1bG+SGcQLpr542BpH+08p987o3 > DgOZAOoA65cUJXep7O+OcvrYwVL/BY/m4aY9ClvwFogKhbn2c7K1nDnMudaPxohS > 7M9WR7sWwMYMVtjfQVGmqDkf+eq8h3aVN+cxjdDGkZVhffBslP3x5LUAtakmGDOw > X34WJYGkKSERVL6PxCAUZUvtLqDN6Zq1AU62RP9RIztKjbPSFckrBXVPXPGyVOLQ > RTFh9YF+zQgX/3C9yhXF7uUMN0SdsN3NVETHwww3CqiwD0Qg4QKFmGritiMU5VVJ > uqX6WXROhqzAgr3nPJe/WbC//ckGKsVO4JOctbQmFzdxK8+HgMqrRUc6KdGJkyWo > JJBdW3D828MgOA0G4emvbWHh1bYlGuacO0I4/t27xQFEZ/UdJMRsEh+7hTAZd16j > OYfMunX9PlpvZFsHmvcMTybIOz3PApz0ob8fzF/vOD7r4VrNHGEqPZF6GyllvLw3 > qxYDGfzeDtaoT5p6V0bptUzAcR3y0DRHQBJTl/Ai2ejTN8K1pYDUBONTGhnkLp10 > jvOC5WFffjgysH0hKE5g > =YuOG > -----END PGP SIGNATURE----- > > --------------------------------------------------------------- > > To unsubscribe from this mailing list, please send an e-mail to > listproc@nist.gov with the words "unsubscribe scap-dev" in the body. You > will need to send this from the email account that you used to initially > subscribe to scap-dev. > --------------------------------------------------------------- To unsubscribe from this mailing list, please send an e-mail to listproc@nist.gov with the words "unsubscribe scap-dev" in the body. You will need to send this from the email account that you used to initially subscribe to scap-dev. From david.oliva@verizon.net Tue May 15 06:37: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 0ACA621F89DF for ; Tue, 15 May 2012 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.761 X-Spam-Level: X-Spam-Status: No, score=0.761 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, MIME_HTML_ONLY=1.457, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsWMagbiIqnb for ; Tue, 15 May 2012 06:37:10 -0700 (PDT) Received: from vms173021pub.verizon.net (vms173021pub.verizon.net [206.46.173.21]) by ietfa.amsl.com (Postfix) with ESMTP id BDEB221F89D0 for ; Tue, 15 May 2012 06:37:08 -0700 (PDT) Received: from vznit170080pub.verizon.net ([unknown] [192.168.1.3]) by vms173021.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M4200IWZGHEIGQ1@vms173021.mailsrvcs.net> for sacm@ietf.org; Tue, 15 May 2012 08:36:51 -0500 (CDT) Received: from 96.255.129.191 ([96.255.129.191]) by vznit170080 (Verizon Webmail) with HTTP; Tue, 15 May 2012 08:36:50 -0500 (CDT) Date: Tue, 15 May 2012 08:36:50 -0500 (CDT) From: david.oliva@verizon.net To: m.kinne@radium.ncsc.mil, david.oliva@verizon.net, Kent_Landfield@McAfee.com, david.waltermire@nist.gov, SCAP-DEV@nist.gov, sacm@ietf.org Message-id: <17823436.373235.1337089010524.JavaMail.root@vznit170080> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [96.255.129.191] Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 15 May 2012 13:37:12 -0000
Mike and all:
 
In = the long run multiple repositories in different languages catering to diffe= rent groups will likely appear.
 
I recommend that= the NVD Checklist Repository continue to used and work as a reference poin= t and anchor to content that needs to be translated to other languages.
In the meantime, it is great to see vendor-unique content in th= e national checklist website.
 
David Oliva
<= DIV> 
 
 
On 05/14/12, Kinney, Michael A<= ;m.kinne@radium.ncsc.mil> wrote:
 

Kent, I re-read your comments, and = understand your points. Glad someone is setting up another SCAP repository,= I would like to be included, so will this be discussed at developer days, = or SACM, or will is someone going to setup another working group?

It will be interesting to get everyone to c= reate and share content, are you offering up sharing of McAfee content?

 

-Mike

 

From: david.oliva@verizon.net [m= ailto:david.oliva@verizon.net]
Sent: Saturday, May 12, 2012 = 3:46 PM
To: Kent_Landfield@McAfee.com; Kinney, Michael = A; david.waltermire@nist.gov; SCAP-DEV@nist.gov; sacm@ietf.orgSubject: Re: [sacm] Request for participants - Content Repository = Specification Development

 =

To all:

 

I= am interested in locating content for SCAP 1.2.

In particular, content for the specifications added af= ter 1.0.

Are you all talking= about SCAP 1.2 Content?

&nb= sp;

David Oliva

 

 

On 05/11/12,= Kent_Landfield@McAfee.com wrote:

 

<= SPAN style=3D"COLOR: black">Mike I love it when you tee something up like t= hat=E2=80=A6. ;-)  Thank you. ;)

 

Mike wrote: 

I still think that any specification for a repository is w= ishful thinking until someone builds one and learns the lessons it will jus= t be another whitepaper spec.  I believe the DoD needs to incorporate = a metadata repository as part of it and other customizations that may not b= e useful for everyone.

We need to talk more=E2=80=A6

 

If you are talking about a holistic, complete federated approach to a = content repository, I some what agree.  If you are talking about an or= ganizational repository, I totally disagree. But you knew I would. ;)

 

Here is how I see the proble= m.  There is an immediate need for SCAP and other related content to b= e served up inside an organization.  Today we have situation where the= standards allow us to provide sites the capability to have a single SCAP i= mplemented policy they call official for their environment. Yes this is a r= ather simplistic since there are things such as targeting specific platform= s, specific operational use needs, but for now lets agree SCAP is a massive= improvement over the proprietary situations of the past. While we have cre= ated this standard content so that sites can implement their local site sec= urity once and then assure they are measuring all appropriately targeted de= vices the same way, we have failed to support the operational needs of the = sites.  We have a situation where no two vendors distribute content th= e same way.  This causes massive problems for the administration staff= when they need to incorporate a new SCAP enabled product into their archit= ecture.  They need to discover how the new product supports distributi= ng SCAP content to it's various components.  If they have one product = then they do this one and they are done.  If they have multiple produc= ts they will have to figure out how to minimize the impact by incorporating= the update process for the new product into the existing SCAP security con= tent processes. Now when the inevitable happens and the site staff needs to= make a change to their security policy, they have to make the modification= s to the benchmark or checks or both and then distribute those updates acro= ss their network.  For each SCAP enabled product they have in place, t= hey have doubled, tripled or more the work needed to make those updates ava= ilable. 

&= nbsp;

There is = another content repository problem and that is the Federated Content Distri= bution.  If you think global DNS you have a general frame of reference= .  The guidance authors need to be able to publish content in an autho= ritative manner so their content is updated in a timely fashion.  This= is a much harder problem to solve if there is no local organizational infr= astructure to support it. ;)

 

So here is what I am thinking=E2=80=A6  We should consider addre= ssing these as two separate but integrated efforts.  I believe the Org= anizational Content Repository is the more critical piece that is actually = easier to address.  The Federated Content Distribution should be a sub= sequent effort integrating / augmenting the Organizational repository speci= fication. 

 

Mike, t= o your point that we need someone to build one first=E2=80=A6 That has happ= ened already.  I have one as do other vendors but what we don=E2=80=99= t have is the access specification.  Ours are focused on our specific = product needs.  Additionally there is a company that has developed a c= ommercial SCAP content repository that will be announced later this month. = I won't steal their thunder but I was recently given a sneak peek at it and= I must admit I was very impressed.  Again, to your point, it has been= done. What is needed to address the initial operational problem is to deve= lop a specification that provides a consistent means for all SCAP products = to retrieve the appropriate content as configured and managed but the site.=  

 <= /SPAN>

TO THAT END=E2= =80=A6.

 <= /SPAN>

I am requesting= participation from those in the community that see the need and want to pu= t in the work to make this specification happen.  I have talked to a c= ouple of you but I do not want to assume your participation.  If you a= re interested please contact me so we can get this started. 

 

Thanks!

 

Kent Landfield
Director Content Strategy, Architecture and Stan= dards

Web:&n= bsp;www.mcafee.com

<= SPAN style=3D"COLOR: black"> 

From: = <Kinney>, Michael A <m.kinne@radium.ncsc.mil&g= t;
To: David Waltermire <david.waltermire@nist.gov&g= t;, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>=
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation De= veloper Days: Summer 2012 at MITRE in Bedford, MA

 

Dave,

I have no pro= blem with webinars, I do want to keep developer days actionable and use it = to make decisions, and vote and accomplish things good or bad.  I do n= ot want this to be an informational briefing conference.

Thank= s for the links.

 

I still think that any spec= ification for a repository is wishful thinking until someone builds one and= learns the lessons it will just be another whitepaper spec.  I believ= e the DoD needs to incorporate a metadata repository as part of it and othe= r customizations that may not be useful for everyone.

We need t= o talk more=E2=80=A6

 =

-Mike 

From:= Waltermire, David A. [mailto:david.waltermire@nist.gov] <= BR>Sent: Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michae= l A; SCAP-DEV; sacm@ietf.org
Subject: RE: [OVAL-DEVELOPER-LIST] Se= curity Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-place = of the 30 minute briefs?

 

Regarding content m= anagement, we are building the prototype content repository for use in a pr= oduction environment.  As an open source project, it will be free for = use by anyone interested.  My thinking is that this project can bridge= the gap until commercial solutions are available to augment it.  This= is a similar path that was followed with DNS (bind) and HTTP (apache).&nbs= p; When it is ready for use, I am hoping to use it to host USGCB content.&n= bsp; You would be welcome to use it for your needs.

 

It is good that OCIL is moving forward.  This is an important = piece of supporting risk management and aspects of continuous monitoring.&n= bsp; I would also like to see some discussion on OCIL at Developer Days.&nb= sp; With the proposals we will likely have a sense of what needs to be disc= ussed and what we can achieve consensus on outside the meeting.

 

Remediation is a topic near and dear to my heart. = I too would like to see it move forward. 

We= just published the draft ASR specification for public comment.  This = specification supports enterprise aggregate reporting which greatly reduces= the data volumes needed verses detailed host-based reports. This specifica= tion has been designed as a more robust replacement for LASR.  It can = be used in continuous monitoring applications to support aggregate data rep= orting needs (e.g. FISMA reporting,  CyberScope).

 

Here are the links:

 

http://cs= rc.nist.gov/publications/PubsDrafts.html

h= ttp://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

 

The primary reason we have suggested waiting on XCCD= F is not the internationalization issue. Many vendors have commented that t= hey are still working on implementing the XCCDF 1.2.1 specification. We wil= l be in a better place in a few months once more development around XCCDF h= as occurred.  As we consider changes to the SCAP stack to address OCIL= and other issues, we will identify areas that need improvement in XCCDF.&n= bsp; These are good and necessary discussions to have now, but we have a go= od deal of work to do before we are ready to open up XCCDF.  My sugges= tion is to work on these related areas and then work up change proposals fo= r XCCDF as needed.  By that time we should be ready to work on a new r= evision of XCCDF.

<= SPAN style=3D"COLOR: #1f497d"> 

I am also looking forward = to the discussions at the conference.  It has been too long.

 

Sincerely,

Dave

&n= bsp;

From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]
Sent:= Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: Wal= termire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] Security Aut= omation Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

It=E2=80=99s good to read your thoughts, and a r= ealistic actionable approach is indeed needed.  Since all the activity= hasn=E2=80=99t been on the lists a brief 1=C5=BD2 hour recap may be in ord= er to bring everyone up to speed since there has been a lot of activity on = CPE/SWID, OCIl, MAEC/CybOX CEE and others.

 

W= e could write a content repository specification, but without someone willi= ng to stand one up it will be as valuable as the CCSS specification is toda= y.  I=E2=80=99ve been trying for two years to get my management to get= a coordinated effort together for the DoD to stand up a repository, it is = a tough problem and will require funding with a tail, I=E2=80=99m not sure = a specification will solve that problem.

 

We = (DoD) have been putting a lot of effort into OCIL over the last year trying= to make it useful in an enterprise environment and will be posting our ide= as to the list before developer days it should have already started, we nee= d to get consensus and a vote on how the community wishes to proceed.

 

Remediation is stalled but I=E2=80=99m making eve= ry effort to get it kick started from our perspective. I hope to assist in = getting the draft ERI finished this year.  We are writing some new STI= G content and intend to used the draft CRE specification to insert CRE into= the content so we (DoD) can do some automatic configuration fixes, part of= a self healing network concept. It is just a start but the best we can do = at this point.

 

Enterprise reporting is an in= teresting subject, since XML adds size to and content to roll up reporting,= in any enterprise of size the problem gets greater, I look forward to your= thoughts on that subject.

 

I am concerned th= at the internationalization efforts are detracting from efforts to meet use= cases, we have some things we would like changed in XCCDF to support our O= CIl use case and I have been told that I need to wait. I didn=E2=80=99t thi= nk that a move to internationalization should impede efforts to move forwar= d with use cases.

<= SPAN style=3D"COLOR: #1f497d"> 

I look forward to talking = with you at the conference.

<= P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto" class=3DM= soNormal> 

 

Mike Kinney

Project Director

Computer Network Defense Research and Techn= ology (CND R&T) Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
= NSTS: 968-8886
Fax 410-854-4681

makinn2@nsa.gov<= /SPAN>

 

 

 

From:scap-dev@= nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Walt= ermire, David A.
Sent: Monday, May 07, 2012 7:09 PM
To:= Multiple recipients of list
Subject: RE: [OVAL-DEVELOPER-LIST] S= ecurity Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

I like what you are saying here.&nbs= p; We are also in support of this type of approach.  We would like to = see some community discussion around what are the key areas/priorities that= the community would like to see discussed at Dev Days.  Your topics b= elow look like a good start. The SACM list might be a better venue than the= OVAL list for this discussion.  For each area we should focus the dis= cussion around developing objectives for each session.  The sessions c= an be time boxed based on what would be a reasonable amount of time to acco= mplish each objective.  For example if continuous monitoring is a prio= rity and collectively it takes 3 days to work through all the objectives, I= see no problem with that.  We can also keep a few sessions =E2=80=9Co= n deck=E2=80=9D if all the objectives are reached and we complete all the s= cheduled sessions early.

 

Thoughts?

 

Sincerely,

 

David Waltermire

SCAP Arch= itect

National Institute of Standards and Technology

(301) 975-3390

david.waltermire@nist.gov

 

From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mc= afee.com
Sent: Monday, May 07, 2012 4:25 PM
To: SCA= P-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Deve= loper Days: Summer 2012 at MITRE in Bedford, MA

 = ;

All,=

 <= /P>

I would like to discus= s the format for the SCAP Developer Days that seems to be listed below.

 

<= /DIV>

I see this appears to foll= ow a path we have discussed in the past as the way not to hold a Dev Days e= vent.  We have been trying to get away from 'Death by Powerpoint' and = back to the type of event we held years ago when we were highly productive.=  In the past we had a topic to be discussed and a time box to work wi= thin.  That allowed us to have very active brainstorming sessions in a= high bandwidth environment.

 

At past Summer events we have got into a pattern of lots of powerpoin= t, lots of status of the efforts and very little discussion about things th= at need active discussions.  We need to keep moving forward and making= progress as an effort. We can get status from various places such as the l= ists, a presentation being sent out in advance, a webinar if it is felt the= re will be questions and answers from those that are new to the efforts. &n= bsp;We have a limited amount of time and all who are attending are investin= g a great deal of time and money to be there.  We should not  be = spending a great deal of time reeducating everyone when we could be focused= on advancing needed efforts.

 

The type of approach to a Dev Days event was discussed at the last S= ummer Dev Days.  I have seen the following work quite well in other ef= forts.

  1. Presentations are sent out to the attendees and the lists a we= ek in advance.
  2. Statu= s for any effort is limited to 30 minutes
  3. Focused brainstorming time should be established for = certain areas that need real work by the community
  4. Efforts to be discussed should be based on n= eeds of the security automation space to move existing efforts to completio= n.

For example:=

 

Continuous monitoring is a ma= jor direction the efforts are becoming involved with. There are going to be= things we need to do as a security automation community to be able to acco= mplish what is listed in the CAESARS FE.  There are interfaces that ne= ed to be worked and established.  That is one area that is not listed = below.  CM will have a major impact on all of us in the next couple ye= ars and it is being ignored.  We can't keep trying to solve what has a= lready been solved.  We need to address the needed interface developme= nt now. This is an effort that could take nearly a whole day by itself.

 

<= /DIV>

Operationally we have a re= al need to be able to deliver SCAP content internally within an organizatio= n. Today the SCAP vendors cannot share a single local site security policy = (XCCDF + OVAL + CPE +=E2=80=A6) without the site staff having to go to each= of the individual products and figuring out how to inject that new or upda= ted policy into that products delivery mechanisms.  That is limiting s= ites from wanting to buy multiple focused SCAP products since they are such= a pain to manage from a content perspective.  It is easier to buy fro= m one vendor that has a single means for distributing content than it is to= deal with the management issues that having multiple SCAP products present= s.  We need to have at least an entire 1/2 a day on the development of= a Content Repository specification.

 

OCIL is a positive and a negative at the same time. It has re= al value that is being underutilized and under implemented because of the l= imitations of how it addresses uses in an enterprise environment.  Peo= ple don't need security automation to do things on/for a single host.  = ;They need security automation to focus on the enterprise issues that reduc= e their costs and improve their efficiencies.  OCIL is failing in the = enterprise and we all understand that.  We need to address developing = a definitive solution for incorporating OCIL into the enterprise and that m= eans into the existing specifications. Scheduling and tracking are key to i= t's success.  We need to make that happen.  This too needs a focu= sed brainstorming time box to discuss options.

 

I am really disappointed that Remediation is not on= the list below=E2=80=A6  Yes, last Summer Dev Days, the time spent on= Remediation was wasted time but that does not mean we should ignore it and= not try to make some real progress.  As far as I am concerned we need= to reboot the remediation effort.  We cannot keep being the set of sp= ecifications / tools that act as the little boy crying "Wolf" in the night.=  We need to be able to find and fix issues if we are going to really = make a difference in organizational security postures.  But today we t= hink it is too hard so we don't try ?  I think we need a couple hours = to discuss the reboot of the effort even if that means minimizing work alre= ady done.

 = ;

A focused dis= cussion on enterprise reporting is also critically needed.  For the ve= ndors here, we have all gone through the Cyberscope goat rope, delivering l= imited capabilities to specific data call requirements of the Federal Agenc= ies.  The initial effort was a mess, did little more than prove it was= possible and cause the vendor community a great deal of thrashing to put a= kludgey 'solution' in place.  Reality is all our customers need roll = up reporting and an infrastructure that supports it.  A data call shou= ld not be special to anyone other than the agencies responding. The tools s= hould be able to select the types of data needed and deliver that on a sche= duled basis automatically.    Enterprise Reporting pertains to co= mmercial as well as Federal customers.  We need to focus some time on = what that would look like using the ARF and ASR as the foundational pieces.=  But there are missing pieces=E2=80=A6.  We need this discussed.=

 <= /P>

I would hope we can ma= ke this summer's SCAP Dev Days useful in advancing the security automation = efforts by addressing some of the more critical issues our customers are fa= cing now or will be facing in the very short term.  Status presentatio= ns are not interesting to those active in the efforts.  Let's try to d= o those before we get to Bedford so we can real make some progress while we= are all in the same room.  This is always a big event for the 'consen= sus of the willing' that assemble and driven to see security automation mak= e a difference.  Let's see if we can have an event that, when we all w= alk out the last day, we all feel that every minute was well spent and move= s us forward.

&= nbsp;

Thanks.

 

Kent Landfield
Director Content Strategy, Architect= ure and Standards

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

Direct:= +1.972.963.7096 
Mobile: +1.= 817.637.8026
Web: www.mcafee.com

 

From: <Boczenowski>, Stev= e <sboczeno@MITRE.ORG>
Reply-To: "OVAL Developer List (C= losed Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MIT= RE.ORG>
To: "OVAL-DEVELOPER-LIST@LISTS.MIT= RE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>=
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer= Days: Summer 2012 at MITRE in Bedford, MA

<= SPAN style=3D"COLOR: black"> 

Frank;

 

We hope to have the registrat= ion site up next week.  The event will be during the week of July 9 = =E2=80=93 starting Monday at 10:00 AM and ending on Friday at 12:00.=

 

Meanwhile, we are working on the agenda and are cu= rrently considering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/M= AEC

Federated Content Repository Spec

Endpoint Reporting for Continuous Monitoring and= Compliance (ERCC)

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Release= s

SCAP and IETF

NETCONF and SCAP

 

Steve

&nbs= p;

From= : Frank Lindsay Acker [mailto:afrank@NOVA.EDU]
Sen= t: Tuesday, May 01, 2012 9:32 AM
To: oval-developer-list OVAL= Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVEL= OPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedf= ord, MA

 

Steve....

Has there been any addi= tional information regarding this event?

Thanks,
Frank Acker

From: Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Subject: [OVAL-DEVEL= OPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedf= ord, MA

Save the Date: week o= f July 9, 2012

 

This year=E2=80=99s MITRE-hosted Security Automation Developer Da= ys event will be held during the week of July 9, 2012 at MITRE=E2=80=99s fa= cility in Bedford, MA.

 

Details to follow.

 

Regards,

    Steve

 

____________________________= __________________

Stephen = P. Boczenowski

      T= he MITRE Corporation

   = ;   Office: (781) 271-7682

  &nbs= p;   Cell: (978) 302-3849

   = ;  sboczeno@mitre.org

 

To = unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG wit= h SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have diffi= culties, write to OVAL-DEVELOPER-LIST-request@LISTS= .MITRE.ORG.

= To unsubscribe, send an email message to = LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY o= f the message. If you have difficulties, write to O= VAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSE= RV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the = message. If you have difficulties, write to OVAL-DE= VELOPER-LIST-request@LISTS.MITRE.ORG.

 

<= HR align=3Dcenter SIZE=3D1 width=3D"100%">


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

=
From m.kinne@radium.ncsc.mil Mon May 14 04:09: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 81E4F21F86C5 for ; Mon, 14 May 2012 04:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.668 X-Spam-Level: X-Spam-Status: No, score=-9.668 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cygAirCJg4R for ; Mon, 14 May 2012 04:09:51 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34021F86C3 for ; Mon, 14 May 2012 04:09:50 -0700 (PDT) X-TM-IMSS-Message-ID: <700d5edf000ef2d5@nsa.gov> Received: from MSCS-GH1-UEA02.corp.nsa.gov ([10.215.225.42]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 700d5edf000ef2d5 ; Mon, 14 May 2012 07:11:27 -0400 Received: from MSIS-GH1-UEA10.corp.nsa.gov ([10.215.229.132]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 May 2012 07:09:45 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 May 2012 07:09:44 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0074_01CD31A0.893172A0" Message-ID: <15D0981C9BE53042A4C9D0F3D0B6826B290130@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: <22541297.132421.1336851964583.JavaMail.root@vznit170080> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0wd+CS9svKA/9zTuS3t0cuM7bijQBSSCkw References: <22541297.132421.1336851964583.JavaMail.root@vznit170080> From: "Kinney, Michael A" To: , , , , X-OriginalArrivalTime: 14 May 2012 11:09:45.0403 (UTC) FILETIME=[11B3E0B0:01CD31C2] X-Mailman-Approved-At: Tue, 15 May 2012 08:05:29 -0700 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 11:09:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0074_01CD31A0.893172A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0075_01CD31A0.893172A0" ------=_NextPart_001_0075_01CD31A0.893172A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kent, I re-read your comments, and understand your points. Glad someone = is setting up another SCAP repository, I would like to be included, so = will this be discussed at developer days, or SACM, or will is someone = going to setup another working group? It will be interesting to get everyone to create and share content, are = you offering up sharing of McAfee content?=20 =20 -Mike =20 From: david.oliva@verizon.net [mailto:david.oliva@verizon.net]=20 Sent: Saturday, May 12, 2012 3:46 PM To: Kent_Landfield@McAfee.com; Kinney, Michael A; = david.waltermire@nist.gov; SCAP-DEV@nist.gov; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository = Specification Development =20 To all: =20 I am interested in locating content for SCAP 1.2. In particular, content for the specifications added after 1.0. Are you all talking about SCAP 1.2 Content? =20 David Oliva =20 =20 On 05/11/12, Kent_Landfield@McAfee.com wrote: =20 Mike I love it when you tee something up like that=E2=80=A6. ;-) Thank = you. ;) =20 Mike wrote:=20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be = another whitepaper spec. I believe the DoD needs to incorporate a = metadata repository as part of it and other customizations that may not = be useful for everyone. We need to talk more=E2=80=A6 =20 If you are talking about a holistic, complete federated approach to a = content repository, I some what agree. If you are talking about an = organizational repository, I totally disagree. But you knew I would. ;) =20 Here is how I see the problem. There is an immediate need for SCAP and = other related content to be served up inside an organization. Today we = have situation where the standards allow us to provide sites the = capability to have a single SCAP implemented policy they call official = for their environment. Yes this is a rather simplistic since there are = things such as targeting specific platforms, specific operational use = needs, but for now lets agree SCAP is a massive improvement over the = proprietary situations of the past. While we have created this standard = content so that sites can implement their local site security once and = then assure they are measuring all appropriately targeted devices the = same way, we have failed to support the operational needs of the sites. = We have a situation where no two vendors distribute content the same = way. This causes massive problems for the administration staff when = they need to incorporate a new SCAP enabled product into their = architecture. They need to discover how the new product supports = distributing SCAP content to it's various components. If they have one = product then they do this one and they are done. If they have multiple = products they will have to figure out how to minimize the impact by = incorporating the update process for the new product into the existing = SCAP security content processes. Now when the inevitable happens and the = site staff needs to make a change to their security policy, they have to = make the modifications to the benchmark or checks or both and then = distribute those updates across their network. For each SCAP enabled = product they have in place, they have doubled, tripled or more the work = needed to make those updates available.=20 =20 There is another content repository problem and that is the Federated = Content Distribution. If you think global DNS you have a general frame = of reference. The guidance authors need to be able to publish content = in an authoritative manner so their content is updated in a timely = fashion. This is a much harder problem to solve if there is no local = organizational infrastructure to support it. ;) =20 So here is what I am thinking=E2=80=A6 We should consider addressing = these as two separate but integrated efforts. I believe the = Organizational Content Repository is the more critical piece that is = actually easier to address. The Federated Content Distribution should = be a subsequent effort integrating / augmenting the Organizational = repository specification.=20 =20 Mike, to your point that we need someone to build one first=E2=80=A6 = That has happened already. I have one as do other vendors but what we = don=E2=80=99t have is the access specification. Ours are focused on our = specific product needs. Additionally there is a company that has = developed a commercial SCAP content repository that will be announced = later this month. I won't steal their thunder but I was recently given a = sneak peek at it and I must admit I was very impressed. Again, to your = point, it has been done. What is needed to address the initial = operational problem is to develop a specification that provides a = consistent means for all SCAP products to retrieve the appropriate = content as configured and managed but the site. =20 =20 TO THAT END=E2=80=A6. =20 I am requesting participation from those in the community that see the = need and want to put in the work to make this specification happen. I = have talked to a couple of you but I do not want to assume your = participation. If you are interested please contact me so we can get = this started.=20 =20 Thanks! =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Michael A To: David Waltermire , SCAP-DEV = , "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer = Days: Summer 2012 at MITRE in Bedford, MA =20 Dave, I have no problem with webinars, I do want to keep developer days = actionable and use it to make decisions, and vote and accomplish things = good or bad. I do not want this to be an informational briefing = conference. Thanks for the links. =20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be = another whitepaper spec. I believe the DoD needs to incorporate a = metadata repository as part of it and other customizations that may not = be useful for everyone. We need to talk more=E2=80=A6 =20 -Mike =20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 Regarding content management, we are building the prototype content = repository for use in a production environment. As an open source = project, it will be free for use by anyone interested. My thinking is = that this project can bridge the gap until commercial solutions are = available to augment it. This is a similar path that was followed with = DNS (bind) and HTTP (apache). When it is ready for use, I am hoping to = use it to host USGCB content. You would be welcome to use it for your = needs. =20 It is good that OCIL is moving forward. This is an important piece of = supporting risk management and aspects of continuous monitoring. I = would also like to see some discussion on OCIL at Developer Days. With = the proposals we will likely have a sense of what needs to be discussed = and what we can achieve consensus on outside the meeting. =20 Remediation is a topic near and dear to my heart. I too would like to = see it move forward. =20 We just published the draft ASR specification for public comment. This = specification supports enterprise aggregate reporting which greatly = reduces the data volumes needed verses detailed host-based reports. This = specification has been designed as a more robust replacement for LASR. = It can be used in continuous monitoring applications to support = aggregate data reporting needs (e.g. FISMA reporting, CyberScope). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 The primary reason we have suggested waiting on XCCDF is not the = internationalization issue. Many vendors have commented that they are = still working on implementing the XCCDF 1.2.1 specification. We will be = in a better place in a few months once more development around XCCDF has = occurred. As we consider changes to the SCAP stack to address OCIL and = other issues, we will identify areas that need improvement in XCCDF. = These are good and necessary discussions to have now, but we have a good = deal of work to do before we are ready to open up XCCDF. My suggestion = is to work on these related areas and then work up change proposals for = XCCDF as needed. By that time we should be ready to work on a new = revision of XCCDF. =20 I am also looking forward to the discussions at the conference. It has = been too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]=20 Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 It=E2=80=99s good to read your thoughts, and a realistic actionable = approach is indeed needed. Since all the activity hasn=E2=80=99t been = on the lists a brief 1=C5=BD2 hour recap may be in order to bring = everyone up to speed since there has been a lot of activity on CPE/SWID, = OCIl, MAEC/CybOX CEE and others. =20 We could write a content repository specification, but without someone = willing to stand one up it will be as valuable as the CCSS specification = is today. I=E2=80=99ve been trying for two years to get my management = to get a coordinated effort together for the DoD to stand up a = repository, it is a tough problem and will require funding with a tail, = I=E2=80=99m not sure a specification will solve that problem. =20 We (DoD) have been putting a lot of effort into OCIL over the last year = trying to make it useful in an enterprise environment and will be = posting our ideas to the list before developer days it should have = already started, we need to get consensus and a vote on how the = community wishes to proceed. =20 Remediation is stalled but I=E2=80=99m making every effort to get it = kick started from our perspective. I hope to assist in getting the draft = ERI finished this year. We are writing some new STIG content and intend = to used the draft CRE specification to insert CRE into the content so we = (DoD) can do some automatic configuration fixes, part of a self healing = network concept. It is just a start but the best we can do at this = point. =20 Enterprise reporting is an interesting subject, since XML adds size to = and content to roll up reporting, in any enterprise of size the problem = gets greater, I look forward to your thoughts on that subject. =20 I am concerned that the internationalization efforts are detracting from = efforts to meet use cases, we have some things we would like changed in = XCCDF to support our OCIl use case and I have been told that I need to = wait. I didn=E2=80=99t think that a move to internationalization should = impede efforts to move forward with use cases. =20 I look forward to talking with you at the conference. =20 v/r =20 Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov =20 =20 =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 I like what you are saying here. We are also in support of this type of = approach. We would like to see some community discussion around what = are the key areas/priorities that the community would like to see = discussed at Dev Days. Your topics below look like a good start. The = SACM list might be a better venue than the OVAL list for this = discussion. For each area we should focus the discussion around = developing objectives for each session. The sessions can be time boxed = based on what would be a reasonable amount of time to accomplish each = objective. For example if continuous monitoring is a priority and = collectively it takes 3 days to work through all the objectives, I see = no problem with that. We can also keep a few sessions =E2=80=9Con = deck=E2=80=9D if all the objectives are reached and we complete all the = scheduled sessions early. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Kent_Landfield@mcafee.com Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA =20 All, =20 I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. =20 I see this appears to follow a path we have discussed in the past as the = way not to hold a Dev Days event. We have been trying to get away from = 'Death by Powerpoint' and back to the type of event we held years ago = when we were highly productive. In the past we had a topic to be = discussed and a time box to work within. That allowed us to have very = active brainstorming sessions in a high bandwidth environment. =20 At past Summer events we have got into a pattern of lots of powerpoint, = lots of status of the efforts and very little discussion about things = that need active discussions. We need to keep moving forward and making = progress as an effort. We can get status from various places such as the = lists, a presentation being sent out in advance, a webinar if it is felt = there will be questions and answers from those that are new to the = efforts. We have a limited amount of time and all who are attending are = investing a great deal of time and money to be there. We should not be = spending a great deal of time reeducating everyone when we could be = focused on advancing needed efforts. =20 The type of approach to a Dev Days event was discussed at the last = Summer Dev Days. I have seen the following work quite well in other = efforts. 1. Presentations are sent out to the attendees and the lists a week in = advance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas = that need real work by the community 4. Efforts to be discussed should be based on needs of the security = automation space to move existing efforts to completion. For example: =20 Continuous monitoring is a major direction the efforts are becoming = involved with. There are going to be things we need to do as a security = automation community to be able to accomplish what is listed in the = CAESARS FE. There are interfaces that need to be worked and = established. That is one area that is not listed below. CM will have a = major impact on all of us in the next couple years and it is being = ignored. We can't keep trying to solve what has already been solved. = We need to address the needed interface development now. This is an = effort that could take nearly a whole day by itself. =20 Operationally we have a real need to be able to deliver SCAP content = internally within an organization. Today the SCAP vendors cannot share a = single local site security policy (XCCDF + OVAL + CPE +=E2=80=A6) = without the site staff having to go to each of the individual products = and figuring out how to inject that new or updated policy into that = products delivery mechanisms. That is limiting sites from wanting to = buy multiple focused SCAP products since they are such a pain to manage = from a content perspective. It is easier to buy from one vendor that = has a single means for distributing content than it is to deal with the = management issues that having multiple SCAP products presents. We need = to have at least an entire 1/2 a day on the development of a Content = Repository specification. =20 OCIL is a positive and a negative at the same time. It has real value = that is being underutilized and under implemented because of the = limitations of how it addresses uses in an enterprise environment. = People don't need security automation to do things on/for a single host. = They need security automation to focus on the enterprise issues that = reduce their costs and improve their efficiencies. OCIL is failing in = the enterprise and we all understand that. We need to address = developing a definitive solution for incorporating OCIL into the = enterprise and that means into the existing specifications. Scheduling = and tracking are key to it's success. We need to make that happen. = This too needs a focused brainstorming time box to discuss options. =20 I am really disappointed that Remediation is not on the list = below=E2=80=A6 Yes, last Summer Dev Days, the time spent on Remediation = was wasted time but that does not mean we should ignore it and not try = to make some real progress. As far as I am concerned we need to reboot = the remediation effort. We cannot keep being the set of specifications = / tools that act as the little boy crying "Wolf" in the night. We need = to be able to find and fix issues if we are going to really make a = difference in organizational security postures. But today we think it = is too hard so we don't try ? I think we need a couple hours to discuss = the reboot of the effort even if that means minimizing work already = done. =20 A focused discussion on enterprise reporting is also critically needed. = For the vendors here, we have all gone through the Cyberscope goat rope, = delivering limited capabilities to specific data call requirements of = the Federal Agencies. The initial effort was a mess, did little more = than prove it was possible and cause the vendor community a great deal = of thrashing to put a kludgey 'solution' in place. Reality is all our = customers need roll up reporting and an infrastructure that supports it. = A data call should not be special to anyone other than the agencies = responding. The tools should be able to select the types of data needed = and deliver that on a scheduled basis automatically. Enterprise = Reporting pertains to commercial as well as Federal customers. We need = to focus some time on what that would look like using the ARF and ASR as = the foundational pieces. But there are missing pieces=E2=80=A6. We = need this discussed. =20 I would hope we can make this summer's SCAP Dev Days useful in advancing = the security automation efforts by addressing some of the more critical = issues our customers are facing now or will be facing in the very short = term. Status presentations are not interesting to those active in the = efforts. Let's try to do those before we get to Bedford so we can real = make some progress while we are all in the same room. This is always a = big event for the 'consensus of the willing' that assemble and driven to = see security automation make a difference. Let's see if we can have an = event that, when we all walk out the last day, we all feel that every = minute was well spent and moves us forward. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" = To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" = Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA =20 Frank; =20 We hope to have the registration site up next week. The event will be = during the week of July 9 =E2=80=93 starting Monday at 10:00 AM and = ending on Friday at 12:00. =20 Meanwhile, we are working on the agenda and are currently considering = this list of topics: =20 CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA =20 Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker _____ =20 From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 =20 This year=E2=80=99s MITRE-hosted Security Automation Developer Days = event will be held during the week of July 9, 2012 at MITRE=E2=80=99s = facility in Bedford, MA. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with = SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 =20 _____ =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_001_0075_01CD31A0.893172A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Kent, I re-read your comments, and understand your points. Glad = someone is setting up another SCAP repository, I would like to be = included, so will this be discussed at developer days, or SACM, or will = is someone going to setup another working group?

It will be interesting to get everyone to create and share content, = are you offering up sharing of McAfee content?

 

-Mike

 

From:= = david.oliva@verizon.net [mailto:david.oliva@verizon.net] =
Sent: Saturday, May 12, 2012 3:46 PM
To: = Kent_Landfield@McAfee.com; Kinney, Michael A; david.waltermire@nist.gov; = SCAP-DEV@nist.gov; sacm@ietf.org
Subject: Re: [sacm] Request = for participants - Content Repository Specification = Development

 

To= all:

&n= bsp;

I = am interested in locating content for SCAP = 1.2.

In= particular, content for the specifications added after = 1.0.

Ar= e you all talking about SCAP 1.2 = Content?

&n= bsp;

Da= vid Oliva

&n= bsp;

&n= bsp;

On= 05/11/12, Kent_Landfield@McAfee.com wrote:

&n= bsp;

Mike I love it when you = tee something up like that=E2=80=A6. ;-)  Thank you. = ;)

 

Mike wrote: 

I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be = another whitepaper spec.  I believe the DoD needs to incorporate a = metadata repository as part of it and other customizations that may not = be useful for everyone.

We need to talk more=E2=80=A6

 

If you are talking about a holistic, complete = federated approach to a content repository, I some what agree.  If = you are talking about an organizational repository, I totally disagree. = But you knew I would. ;)

 

Here is how I see the = problem.  There is an immediate need for SCAP and other related = content to be served up inside an organization.  Today we have = situation where the standards allow us to provide sites the capability = to have a single SCAP implemented policy they call official for their = environment. Yes this is a rather simplistic since there are things such = as targeting specific platforms, specific operational use needs, but for = now lets agree SCAP is a massive improvement over the proprietary = situations of the past. While we have created this standard content so = that sites can implement their local site security once and then assure = they are measuring all appropriately targeted devices the same way, we = have failed to support the operational needs of the sites.  We have = a situation where no two vendors distribute content the same way. =  This causes massive problems for the administration staff when = they need to incorporate a new SCAP enabled product into their = architecture.  They need to discover how the new product supports = distributing SCAP content to it's various components.  If they have = one product then they do this one and they are done.  If they have = multiple products they will have to figure out how to minimize the = impact by incorporating the update process for the new product into the = existing SCAP security content processes. Now when the inevitable = happens and the site staff needs to make a change to their security = policy, they have to make the modifications to the benchmark or checks = or both and then distribute those updates across their network. =  For each SCAP enabled product they have in place, they have = doubled, tripled or more the work needed to make those updates = available. 

 

There is another content = repository problem and that is the Federated Content Distribution. =  If you think global DNS you have a general frame of reference. =  The guidance authors need to be able to publish content in an = authoritative manner so their content is updated in a timely fashion. =  This is a much harder problem to solve if there is no local = organizational infrastructure to support it. ;)

 

So here is what I am = thinking=E2=80=A6  We should consider addressing these as two = separate but integrated efforts.  I believe the Organizational = Content Repository is the more critical piece that is actually easier to = address.  The Federated Content Distribution should be a subsequent = effort integrating / augmenting the Organizational repository = specification. 

 

Mike, to your point that = we need someone to build one first=E2=80=A6 That has happened already. =  I have one as do other vendors but what we don=E2=80=99t have is = the access specification.  Ours are focused on our specific product = needs.  Additionally there is a company that has developed a = commercial SCAP content repository that will be announced later this = month. I won't steal their thunder but I was recently given a sneak peek = at it and I must admit I was very impressed.  Again, to your point, = it has been done. What is needed to address the initial operational = problem is to develop a specification that provides a consistent means = for all SCAP products to retrieve the appropriate content as configured = and managed but the site.  

 

TO THAT = END=E2=80=A6.

 

I am requesting = participation from those in the community that see the need and want to = put in the work to make this specification happen.  I have talked = to a couple of you but I do not want to assume your participation. =  If you are interested please contact me so we can get this = started. 

 

Thanks!

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

=

 

From: <Kinney>, Michael A <m.kinne@radium.ncsc.mil>
To: David = Waltermire <david.waltermire@nist.gov>, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" = <sacm@ietf.org>
Subject: Re: [sacm] = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Dave,

I have no problem with webinars, I do want to = keep developer days actionable and use it to make decisions, and vote = and accomplish things good or bad.  I do not want this to be an = informational briefing conference.

Thanks for the links.

 

I still think that any specification for a = repository is wishful thinking until someone builds one and learns the = lessons it will just be another whitepaper spec.  I believe the DoD = needs to incorporate a metadata repository as part of it and other = customizations that may not be useful for everyone.

We need to talk more=E2=80=A6

 

-Mike 

 

= From:= Waltermire, David A. [mailto:david.waltermire@nist.gov]
Sent: = Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michael A; = SCAP-DEV; sacm@ietf.org
Subject: RE: = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-place of the 30 = minute briefs?

 

Regarding content management, we are building = the prototype content repository for use in a production = environment.  As an open source project, it will be free for use by = anyone interested.  My thinking is that this project can bridge the = gap until commercial solutions are available to augment it.  This = is a similar path that was followed with DNS (bind) and HTTP = (apache).  When it is ready for use, I am hoping to use it to host = USGCB content.  You would be welcome to use it for your = needs.

 

It is good that OCIL is moving forward.  = This is an important piece of supporting risk management and aspects of = continuous monitoring.  I would also like to see some discussion on = OCIL at Developer Days.  With the proposals we will likely have a = sense of what needs to be discussed and what we can achieve consensus on = outside the meeting.

 

Remediation is a topic near and dear to my = heart.  I too would like to see it move forward.

 

We just published the draft ASR specification = for public comment.  This specification supports enterprise = aggregate reporting which greatly reduces the data volumes needed verses = detailed host-based reports. This specification has been designed as a = more robust replacement for LASR.  It can be used in continuous = monitoring applications to support aggregate data reporting needs (e.g. = FISMA reporting,  CyberScope).

 

Here are the links:

 

http://csrc.nist.gov/publications/PubsDrafts.html

http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST= -IR-7848

 

The primary reason we have suggested waiting on = XCCDF is not the internationalization issue. Many vendors have commented = that they are still working on implementing the XCCDF 1.2.1 = specification. We will be in a better place in a few months once more = development around XCCDF has occurred.  As we consider changes to = the SCAP stack to address OCIL and other issues, we will identify areas = that need improvement in XCCDF.  These are good and necessary = discussions to have now, but we have a good deal of work to do before we = are ready to open up XCCDF.  My suggestion is to work on these = related areas and then work up change proposals for XCCDF as = needed.  By that time we should be ready to work on a new revision = of XCCDF.

 

I am also looking forward to the discussions at = the conference.  It has been too long.

 

Sincerely,

Dave

 

= From:= Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]
Sent: = Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: = Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Kent,

 

It=E2=80=99s good to read your thoughts, and a = realistic actionable approach is indeed needed.  Since all the = activity hasn=E2=80=99t been on the lists a brief 1=C5=BD2 hour recap = may be in order to bring everyone up to speed since there has been a lot = of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

 

We could write a content repository = specification, but without someone willing to stand one up it will be as = valuable as the CCSS specification is today.  I=E2=80=99ve been = trying for two years to get my management to get a coordinated effort = together for the DoD to stand up a repository, it is a tough problem and = will require funding with a tail, I=E2=80=99m not sure a specification = will solve that problem.

 

We (DoD) have been putting a lot of effort into = OCIL over the last year trying to make it useful in an enterprise = environment and will be posting our ideas to the list before developer = days it should have already started, we need to get consensus and a vote = on how the community wishes to proceed.

 

Remediation is stalled but I=E2=80=99m making = every effort to get it kick started from our perspective. I hope to = assist in getting the draft ERI finished this year.  We are writing = some new STIG content and intend to used the draft CRE specification to = insert CRE into the content so we (DoD) can do some automatic = configuration fixes, part of a self healing network concept. It is just = a start but the best we can do at this point.

 

Enterprise reporting is an interesting subject, = since XML adds size to and content to roll up reporting, in any = enterprise of size the problem gets greater, I look forward to your = thoughts on that subject.

 

I am concerned that the internationalization = efforts are detracting from efforts to meet use cases, we have some = things we would like changed in XCCDF to support our OCIl use case and I = have been told that I need to wait. I didn=E2=80=99t think that a move = to internationalization should impede efforts to move forward with use = cases.

 

I look forward to talking with you at the = conference.

 

v/r

 

Mike Kinney

Project Director

Computer Network Defense Research and Technology (CND R&T) = Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: = 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Waltermire, David A.
Sent: Monday, May 07, 2012 7:09 = PM
To: Multiple recipients of list
Subject: RE: = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Kent,

 

I like what you are saying here.  We are = also in support of this type of approach.  We would like to see = some community discussion around what are the key areas/priorities that = the community would like to see discussed at Dev Days.  Your topics = below look like a good start. The SACM list might be a better venue than = the OVAL list for this discussion.  For each area we should focus = the discussion around developing objectives for each session.  The = sessions can be time boxed based on what would be a reasonable amount of = time to accomplish each objective.  For example if continuous = monitoring is a priority and collectively it takes 3 days to work = through all the objectives, I see no problem with that.  We can = also keep a few sessions =E2=80=9Con deck=E2=80=9D if all the objectives = are reached and we complete all the scheduled sessions = early.

 

Thoughts?

 

Sincerely,

 

David Waltermire

SCAP Architect

National Institute of Standards and = Technology

(301) 975-3390

david.waltermire@nist.gov

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com
Sent: Monday, = May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

All,

 

I would like to discuss the format for the SCAP = Developer Days that seems to be listed = below.

 

I see this appears to follow a path we have = discussed in the past as the way not to hold a Dev Days event.  We = have been trying to get away from 'Death by Powerpoint' and back to the = type of event we held years ago when we were highly productive.  In = the past we had a topic to be discussed and a time box to work within. =  That allowed us to have very active brainstorming sessions in a = high bandwidth environment.

 

At past Summer events we have got into a pattern = of lots of powerpoint, lots of status of the efforts and very little = discussion about things that need active discussions.  We need to = keep moving forward and making progress as an effort. We can get status = from various places such as the lists, a presentation being sent out in = advance, a webinar if it is felt there will be questions and answers = from those that are new to the efforts.  We have a limited amount = of time and all who are attending are investing a great deal of time and = money to be there.  We should not  be spending a great deal of = time reeducating everyone when we could be focused on advancing needed = efforts.

 

The type of approach to a Dev Days event was = discussed at the last Summer Dev Days.  I have seen the following = work quite well in other efforts.

  1. Presentations are sent out to the attendees and = the lists a week in advance.
  2. Status for any effort is limited to 30 = minutes
  3. Focused brainstorming time should be established = for certain areas that need real work by the = community
  4. Efforts to be discussed should be based on needs = of the security automation space to move existing efforts to = completion.

For example:

 

Continuous monitoring is a major direction the = efforts are becoming involved with. There are going to be things we need = to do as a security automation community to be able to accomplish what = is listed in the CAESARS FE.  There are interfaces that need to be = worked and established.  That is one area that is not listed below. =  CM will have a major impact on all of us in the next couple years = and it is being ignored.  We can't keep trying to solve what has = already been solved.  We need to address the needed interface = development now. This is an effort that could take nearly a whole day by = itself.

 

Operationally we have a real need to be able to = deliver SCAP content internally within an organization. Today the SCAP = vendors cannot share a single local site security policy (XCCDF + OVAL + = CPE +=E2=80=A6) without the site staff having to go to each of the = individual products and figuring out how to inject that new or updated = policy into that products delivery mechanisms.  That is limiting = sites from wanting to buy multiple focused SCAP products since they are = such a pain to manage from a content perspective.  It is easier to = buy from one vendor that has a single means for distributing content = than it is to deal with the management issues that having multiple SCAP = products presents.  We need to have at least an entire 1/2 a day on = the development of a Content Repository = specification.

 

OCIL is a positive and a negative at the same = time. It has real value that is being underutilized and under = implemented because of the limitations of how it addresses uses in an = enterprise environment.  People don't need security automation to = do things on/for a single host.  They need security automation to = focus on the enterprise issues that reduce their costs and improve their = efficiencies.  OCIL is failing in the enterprise and we all = understand that.  We need to address developing a definitive = solution for incorporating OCIL into the enterprise and that means into = the existing specifications. Scheduling and tracking are key to it's = success.  We need to make that happen.  This too needs a = focused brainstorming time box to discuss = options.

 

I am really disappointed that Remediation is not = on the list below=E2=80=A6  Yes, last Summer Dev Days, the time = spent on Remediation was wasted time but that does not mean we should = ignore it and not try to make some real progress.  As far as I am = concerned we need to reboot the remediation effort.  We cannot keep = being the set of specifications / tools that act as the little boy = crying "Wolf" in the night.  We need to be able to find = and fix issues if we are going to really make a difference in = organizational security postures.  But today we think it is too = hard so we don't try ?  I think we need a couple hours to discuss = the reboot of the effort even if that means minimizing work already = done.

 

A focused discussion on enterprise reporting is = also critically needed.  For the vendors here, we have all gone = through the Cyberscope goat rope, delivering limited capabilities to = specific data call requirements of the Federal Agencies.  The = initial effort was a mess, did little more than prove it was possible = and cause the vendor community a great deal of thrashing to put a = kludgey 'solution' in place.  Reality is all our customers need = roll up reporting and an infrastructure that supports it.  A data = call should not be special to anyone other than the agencies responding. = The tools should be able to select the types of data needed and deliver = that on a scheduled basis automatically.    Enterprise = Reporting pertains to commercial as well as Federal customers.  We = need to focus some time on what that would look like using the ARF and = ASR as the foundational pieces.  But there are missing = pieces=E2=80=A6.  We need this = discussed.

 

I would hope we can make this summer's SCAP Dev = Days useful in advancing the security automation efforts by addressing = some of the more critical issues our customers are facing now or will be = facing in the very short term.  Status presentations are not = interesting to those active in the efforts.  Let's try to do those = before we get to Bedford so we can real make some progress while we are = all in the same room.  This is always a big event for the = 'consensus of the willing' that assemble and driven to see security = automation make a difference.  Let's see if we can have an event = that, when we all walk out the last day, we all feel that every minute = was well spent and moves us forward.

 

Thanks.

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

 

From: <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply-To: = "OVAL Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: = "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
Subje= ct: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA

 

Frank;

 

We hope to have the registration site up next = week.  The event will be during the week of July 9 =E2=80=93 = starting Monday at 10:00 AM and ending on Friday at 12:00.

 

Meanwhile, we are working on the agenda and are = currently considering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/MAEC

Federated Content Repository = Spec

Endpoint Reporting for Continuous = Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases

SCAP and IETF

NETCONF and SCAP

 

Steve

 

= From:= Frank Lindsay Acker [mailto:afrank@NOVA.EDU]
Sent: Tuesday, = May 01, 2012 9:32 AM
To: oval-developer-list OVAL Developer = List/Closed Public Discussion
Subject: Re: = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

= Steve....

Has there been any additional information regarding = this event?

Thanks,
Frank Acker

= From:= Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tuesday, March = 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Subject:<= /b> [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer = 2012 at MITRE in Bedford, MA

Save the Date: week of July 9, = 2012

 

This year=E2=80=99s MITRE-hosted = Security Automation Developer Days event will be held during the week of = July 9, 2012 at MITRE=E2=80=99s facility in Bedford, = MA.

 

Details to = follow.

 

Regards,

    = Steve

 

= ______________________________________________

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an email message = to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. =

To unsubscribe, send an email message = to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. =

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF = OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. =

 

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

------=_NextPart_001_0075_01CD31A0.893172A0-- ------=_NextPart_000_0074_01CD31A0.893172A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRbzCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIELzCCAxegAwIBAgIDK7YlMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjAwHhcNMDkwOTI4MDAwMDAwWhcN MTIwOTI3MjM1OTU5WjB6MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDT1NEMScwJQYDVQQDEx5LSU5ORVku TUlDSEFFTC5BTEFOLjExOTI1Mzk4NTAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJJ8Qtiv fKHUqYHJYW7ZNYAkrIeR0S2Ag9wUyl53wnghFTWZciTBUwsOtbXTqaX8njoxZVDo2ojvdb1//Jx0 R49T8Qrkd1mUjhFYoC5xK5s0U/NWLleAuy+lio+fofWTJLz4R5ekWjU0KfsYliMBtFQJkfaDGW3k b99if6jMDVJDAgMBAAGjggFdMIIBWTAfBgNVHSMEGDAWgBSyv24AbblASS9gCvR41XmEJakxujA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9ET0QlMjBFTUFJTCUy MENBLTIwMA4GA1UdDwEB/wQEAwIFIDAWBgNVHSAEDzANMAsGCWCGSAFlAgELCTAdBgNVHQ4EFgQU VTBSD3U2HbwcQdk+sn6AnUowodQwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8v Y3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yMDAgBggrBgEFBQcwAYYUaHR0 cDovL29jc3AuZGlzYS5taWwwIgYDVR0RBBswGYEXbS5raW5uZUByYWRpdW0ubmNzYy5taWwwGwYD VR0JBBQwEjAQBggrBgEFBQcJBDEEEwJVUzANBgkqhkiG9w0BAQUFAAOCAQEAZieGCENpai/zGUAd ozpxH0xPpvRB12r6i1xDKbXEqbOIgmIm0TieqZ6+AzJiux3sepabEqKHaeuCeasXQYPDhHowfslH QEZUhOk//yeQHpGaAILILm7qAWZxCo2ZzORqkLfiUGyYTZiCpChYYzFZ06QKLMgu/c+siPYPkRB4 jWsxWaXy+O0hTEzW0rJrSvHibwhhmIUpu4asTI0dUzdabDrUDHeTRFP5ODik9iHS+Qq8F5SN217H XZMPYWOuo9llENS5TKrRmKzDKTbf6qINm8+a0Z4+Q0tx4Vir+Evg7Fvp2qqIYzsNJigtA7gvRc/m Uch9TzTgLoeVoUxY8y8BQTCCBHowggNioAMCAQICAyu2HTANBgkqhkiG9w0BAQUFADBdMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIwMB4XDTA5MDkyODAwMDAwMFoXDTEyMDkyNzIz NTk1OVowejELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMD RG9EMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAsTA09TRDEnMCUGA1UEAxMeS0lOTkVZLk1JQ0hBRUwu QUxBTi4xMTkyNTM5ODUwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZ/Cz/otL0tbCthpKC hOBg5bCJxl1nHPkQ17f6Cbdq3pPYk2dPjSSdH6JlsMbIsPxHUkEtAqchGvU72lXqPY1J5edBpvJF X05ANTPEbU6BRu820jgwnkZUGilfB4S3MsRY7uQjbfSwJoHcHXeyTalgnmCnP6V0A9s5pnO7jNsl dwIDAQABo4IBqDCCAaQwHwYDVR0jBBgwFoAUsr9uAG25QEkvYAr0eNV5hCWpMbowPwYDVR0fBDgw NjA0oDKgMIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RE9EJTIwRU1BSUwlMjBDQS0yMDAO BgNVHQ8BAf8EBAMCBsAwFgYDVR0gBA8wDTALBglghkgBZQIBCwkwHQYDVR0OBBYEFB4xOCjbEzXK +N+f+UMnn/d933i8MG0GCCsGAQUFBwEBBGEwXzA7BggrBgEFBQcwAoYvaHR0cDovL2NybC5kaXNh Lm1pbC9nZXRzaWduP0RPRCUyMEVNQUlMJTIwQ0EtMjAwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3Nw LmRpc2EubWlsMEIGA1UdEQQ7MDmBF20ua2lubmVAcmFkaXVtLm5jc2MubWlsoB4GCisGAQQBgjcU AgOgEAwOMTE5MjUzOTg1MEBtaWwwGwYDVR0JBBQwEjAQBggrBgEFBQcJBDEEEwJVUzApBgNVHSUE IjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQEFBQADggEBAA3v Xw4DSRXCHOvkjDbUWBy+PaO2l+EFfSbgctV3jXOb3MC3ZePpoYvF4ojB1h1VeCgULS8zaslfVtAN 7dalhNZcsGQwsZy1RG5JAciimx5GuRbp1kbW6C/ruAhqNoldvNeOMotz9xwcIijf3wq9lmduaGD/ txCgc0MSvl9CXbMy55n7Vcxq/pA2kEUPQEsMf2/5KZYaF7chqQon+7pfd5wJq3+/+gXVOGKB7DyG i3kLS6ndSWLxp6vYujYLYmSkTzFkStvItD4F3Gz/+QxpzUNzUOoMmxrYfjZcG1llKXWIWSGyTR7a lHeCcxloeEM9A8RCCoDN4pYR1U5fVyobef8wggVGMIIELqADAgECAgErMA0GCSqGSIb3DQEBBQUA MFsxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTA4MDQyMzIxMDg1NloXDTE0 MDQyMzIwMDg1NlowXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoG A1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yMDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALcakIkcgAvbobol7C6j9i0BiFXmFtFPnclTnKYp+YhB 8d2dMiafBzMhtkdBAiA8pdJKy7vLgU9hQdD2yO5opsb3eHq0LFAd/osytloyeZEwUfAhSpipEtMu dJlP5vrVuCeI+MkhoMWzfbdWqnuXQ5wgNE6BiTqOPBYSjLuos4xg13m87+ErtHyRBCeOc05INALl +660zoOd2JXkFPgz3zasTvjpUjnXVuQywk1uSDdv9eVGNxJjMknCT4v+NJnI7Pjm366GoH89SCBj pEktQT7+nUJ8gUbmHZLjdNICCFSIYCtlMalzgPqX+Go21IMrZPDNYWHhwliUtsriMbLZGmECAwEA AaOCAhEwggINMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBw ljAdBgNVHQ4EFgQUsr9uAG25QEkvYAr0eNV5hCWpMbowDAYDVR0kBAUwA4ABADASBgNVHRMBAf8E CDAGAQH/AgEAMFcGA1UdIARQME4wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIB CwowCwYJYIZIAWUCAQsSMAsGCWCGSAFlAgELEzALBglghkgBZQIBCxQwPwYDVR0fBDgwNjA0oDKg MIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RG9EJTIwUm9vdCUyMENBJTIwMjCB/gYIKwYB BQUHAQEEgfEwge4wPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0SXNzdWVkVG8/ RG9EJTIwUm9vdCUyMENBJTIwMjAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgYgG CCsGAQUFBzAChnxsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUy MDIlMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVT P2NBQ2VydGlmaWNhdGU7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQBtBWU/wdnV8bIG1gjNjuWL oOZGAn2lpmSbLxMStAGYofWMOoFLBSOm7c3rsAUrRDFOBNdtQx3aKVGr+cGvlnThaB5IT05cvMqw JEOi7EArEQLbCCNclbw1djXQYrF28tk5/8C12KjbrqFp+qX+XfQ+BbUMhffMPtDCsERbCcPmg1zO Lkt1KKn47VgslkudJga9doaNNyQkVB3PzBdRCPCGknxHv7ft+zhdFG4u6lPTquGu+yaQ9Pr071lr dW8vKFmbHx6+153erlVdKxSfFpoLcIbzkULTI2ii8r82N68UuoBvYUcyvodMd3luqFnMxBcUOSO9 riGc/bm6+HPc4KcaMYICsTCCAq0CAQEwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBH b3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlM IENBLTIwAgMrth0wCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIwNTE0MTEwOTQyWjAjBgkqhkiG9w0BCQQxFgQUrIbPaQfaWcg6MMlvDU7y sgB1nU0wWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBd MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIwAgMrtiUwdQYLKoZIhvcNAQkQAgsx ZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0Rv RDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjACAyu2JTANBgkqhkiG9w0B AQEFAASBgB6z0uyTTc6nb8G3Eunb5w7JKRmj7qmBxDQY2JkiGRMWUFf7ElS+Ji1E0s5GWfr5pfdS H2hgpq/sBypO95V4F4f2VK7/fsQIYgXupR2kjn2h8grQjRJi+3uKu+YidwoJ+IVPBffigzJq4I7S V+QOoxMGEGusQEANl0fWWafKUGj6AAAAAAAA ------=_NextPart_000_0074_01CD31A0.893172A0-- From m.kinne@radium.ncsc.mil Mon May 14 12:21:23 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 3FB5E21F8899 for ; Mon, 14 May 2012 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.565 X-Spam-Level: X-Spam-Status: No, score=-9.565 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crY82n7E-PCC for ; Mon, 14 May 2012 12:21:19 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6D69721F8851 for ; Mon, 14 May 2012 12:21:18 -0700 (PDT) X-TM-IMSS-Message-ID: <4e176968000fc6aa@nsa.gov> Received: from MSCS-GH1-UEA03.corp.nsa.gov ([10.215.228.134]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 4e176968000fc6aa ; Mon, 14 May 2012 15:21:16 -0400 Received: from MSIS-GH1-UEA10.corp.nsa.gov ([10.215.229.132]) by MSCS-GH1-UEA03.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 May 2012 15:21:14 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3206.BA5284FC" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 May 2012 15:21:14 -0400 Message-ID: <15D0981C9BE53042A4C9D0F3D0B6826B29013D@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0wd+CS9svKA/9zTuS3t0cuM7bijQBSSCkwABC1WoAAAK+boA== References: <22541297.132421.1336851964583.JavaMail.root@vznit170080> <15D0981C9BE53042A4C9D0F3D0B6826B290130@MSIS-GH1-UEA10.corp.nsa.gov> From: "Kinney, Michael A" To: "Waltermire, David A." , , , "SCAP-DEV" , X-OriginalArrivalTime: 14 May 2012 19:21:14.0462 (UTC) FILETIME=[BA8D2FE0:01CD3206] X-Mailman-Approved-At: Tue, 15 May 2012 08:05:29 -0700 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 14 May 2012 19:21:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3206.BA5284FC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2ZSwNCg0KUGVyaGFwcyB5b3UgY2FuIGhhdmUgYSBtZWV0aW5nIGluIHRoZSBldmVuaW5nIG9y IGV4dGVuZCB0aGUgc3RheSB0byBGcmlkYXkgdG8gZ2V0IGlucHV0Lg0KDQogDQoNCiANCg0Kdi9y DQoNCiANCg0KTWlrZSBLaW5uZXkNCg0KQ0lTU1AsIENFSCwgQ05EQQ0KSTQxMSBTZWN1cml0eSBD b250ZW50IEF1dG9tYXRpb24gT2ZmaWNlDQoNClByb2plY3QgRGlyZWN0b3INCg0KQ29tcHV0ZXIg TmV0d29yayBEZWZlbnNlIFJlc2VhcmNoIGFuZCBUZWNobm9sb2d5IChDTkQgUiZUKSBPZmZpY2UN Cg0KOTgwMCBTYXZhZ2UgUm9hZCBTdGUgNjc2Nw0KRnQgTWVhZGUsIE1EIDIwNzU1LTY3NjcNClBo b25lOiA0MTAtODU0LTQ0MjINCk5TVFM6IDk2OC04ODg2DQpGYXggNDEwLTg1NC00NjgxDQoNCiA8 bWFpbHRvOk0ua2lubmVAcmFkaXVtLm5jc2MubWlsPiBtYWtpbm4yQG5zYS5nb3YNCg0KIA0KDQog DQoNCiANCg0KRnJvbTogV2FsdGVybWlyZSwgRGF2aWQgQS4gW21haWx0bzpkYXZpZC53YWx0ZXJt aXJlQG5pc3QuZ292XSANClNlbnQ6IE1vbmRheSwgTWF5IDE0LCAyMDEyIDM6MDQgUE0NClRvOiBL aW5uZXksIE1pY2hhZWwgQTsgZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ7IEtlbnRfTGFuZGZpZWxk QE1jQWZlZS5jb207IFNDQVAtREVWOyBzYWNtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NhY21d IFJlcXVlc3QgZm9yIHBhcnRpY2lwYW50cyAtIENvbnRlbnQgUmVwb3NpdG9yeSBTcGVjaWZpY2F0 aW9uIERldmVsb3BtZW50DQoNCiANCg0KTWlrZSwNCg0KIA0KDQpJIGFtIHdvcmtpbmcgdG8gZ2V0 IGEgc2Vzc2lvbiBvbiB0aGUgYWdlbmRhIGF0IERldiBEYXlzIHRvIGRpc2N1c3MgdmFyaW91cyBh c3BlY3RzIG9mIGNvbnRlbnQgcmVwb3NpdG9yeSBmdW5jdGlvbi4gIEkgc2VlIHRoaXMgYXMgYW4g YXJlYSB0aGF0IGhhcyBicm9hZCBhcHBlYWwgdGhhdCBtaWdodCBiZSBhIGdvb2QgY29uc2lkZXJh dGlvbiBmb3Igb25lIG9mIHRoZSBpbml0aWFsIHdvcmsgaXRlbXMgZm9yIFNBQ00uDQoNCiANCg0K U2luY2VyZWx5LA0KDQpEYXZlDQoNCiANCg0KRnJvbTogS2lubmV5LCBNaWNoYWVsIEEgW21haWx0 bzptLmtpbm5lQHJhZGl1bS5uY3NjLm1pbF0gDQpTZW50OiBNb25kYXksIE1heSAxNCwgMjAxMiA3 OjEwIEFNDQpUbzogZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ7IEtlbnRfTGFuZGZpZWxkQE1jQWZl ZS5jb207IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBTQ0FQLURFVjsgc2FjbUBpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtzYWNtXSBSZXF1ZXN0IGZvciBwYXJ0aWNpcGFudHMgLSBDb250ZW50IFJlcG9z aXRvcnkgU3BlY2lmaWNhdGlvbiBEZXZlbG9wbWVudA0KDQogDQoNCktlbnQsIEkgcmUtcmVhZCB5 b3VyIGNvbW1lbnRzLCBhbmQgdW5kZXJzdGFuZCB5b3VyIHBvaW50cy4gR2xhZCBzb21lb25lIGlz IHNldHRpbmcgdXAgYW5vdGhlciBTQ0FQIHJlcG9zaXRvcnksIEkgd291bGQgbGlrZSB0byBiZSBp bmNsdWRlZCwgc28gd2lsbCB0aGlzIGJlIGRpc2N1c3NlZCBhdCBkZXZlbG9wZXIgZGF5cywgb3Ig U0FDTSwgb3Igd2lsbCBpcyBzb21lb25lIGdvaW5nIHRvIHNldHVwIGFub3RoZXIgd29ya2luZyBn cm91cD8NCg0KSXQgd2lsbCBiZSBpbnRlcmVzdGluZyB0byBnZXQgZXZlcnlvbmUgdG8gY3JlYXRl IGFuZCBzaGFyZSBjb250ZW50LCBhcmUgeW91IG9mZmVyaW5nIHVwIHNoYXJpbmcgb2YgTWNBZmVl IGNvbnRlbnQ/IA0KDQogDQoNCi1NaWtlDQoNCiANCg0KRnJvbTogZGF2aWQub2xpdmFAdmVyaXpv bi5uZXQgW21haWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldF0gDQpTZW50OiBTYXR1cmRheSwg TWF5IDEyLCAyMDEyIDM6NDYgUE0NClRvOiBLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tOyBLaW5u ZXksIE1pY2hhZWwgQTsgZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjsgU0NBUC1ERVZAbmlzdC5n b3Y7IHNhY21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2FjbV0gUmVxdWVzdCBmb3IgcGFydGlj aXBhbnRzIC0gQ29udGVudCBSZXBvc2l0b3J5IFNwZWNpZmljYXRpb24gRGV2ZWxvcG1lbnQNCg0K IA0KDQpUbyBhbGw6DQoNCiANCg0KSSBhbSBpbnRlcmVzdGVkIGluIGxvY2F0aW5nIGNvbnRlbnQg Zm9yIFNDQVAgMS4yLg0KDQpJbiBwYXJ0aWN1bGFyLCBjb250ZW50IGZvciB0aGUgc3BlY2lmaWNh dGlvbnMgYWRkZWQgYWZ0ZXIgMS4wLg0KDQpBcmUgeW91IGFsbCB0YWxraW5nIGFib3V0IFNDQVAg MS4yIENvbnRlbnQ/DQoNCiANCg0KRGF2aWQgT2xpdmENCg0KIA0KDQogDQoNCk9uIDA1LzExLzEy LCBLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tIHdyb3RlOg0KDQogDQoNCk1pa2UgSSBsb3ZlIGl0 IHdoZW4geW91IHRlZSBzb21ldGhpbmcgdXAgbGlrZSB0aGF04oCmLiA7LSkgIFRoYW5rIHlvdS4g OykNCg0KIA0KDQpNaWtlIHdyb3RlOiANCg0KSSBzdGlsbCB0aGluayB0aGF0IGFueSBzcGVjaWZp Y2F0aW9uIGZvciBhIHJlcG9zaXRvcnkgaXMgd2lzaGZ1bCB0aGlua2luZyB1bnRpbCBzb21lb25l IGJ1aWxkcyBvbmUgYW5kIGxlYXJucyB0aGUgbGVzc29ucyBpdCB3aWxsIGp1c3QgYmUgYW5vdGhl ciB3aGl0ZXBhcGVyIHNwZWMuICBJIGJlbGlldmUgdGhlIERvRCBuZWVkcyB0byBpbmNvcnBvcmF0 ZSBhIG1ldGFkYXRhIHJlcG9zaXRvcnkgYXMgcGFydCBvZiBpdCBhbmQgb3RoZXIgY3VzdG9taXph dGlvbnMgdGhhdCBtYXkgbm90IGJlIHVzZWZ1bCBmb3IgZXZlcnlvbmUuDQoNCldlIG5lZWQgdG8g dGFsayBtb3Jl4oCmDQoNCiANCg0KSWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGEgaG9saXN0aWMs IGNvbXBsZXRlIGZlZGVyYXRlZCBhcHByb2FjaCB0byBhIGNvbnRlbnQgcmVwb3NpdG9yeSwgSSBz b21lIHdoYXQgYWdyZWUuICBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgYW4gb3JnYW5pemF0aW9u YWwgcmVwb3NpdG9yeSwgSSB0b3RhbGx5IGRpc2FncmVlLiBCdXQgeW91IGtuZXcgSSB3b3VsZC4g OykNCg0KIA0KDQpIZXJlIGlzIGhvdyBJIHNlZSB0aGUgcHJvYmxlbS4gIFRoZXJlIGlzIGFuIGlt bWVkaWF0ZSBuZWVkIGZvciBTQ0FQIGFuZCBvdGhlciByZWxhdGVkIGNvbnRlbnQgdG8gYmUgc2Vy dmVkIHVwIGluc2lkZSBhbiBvcmdhbml6YXRpb24uICBUb2RheSB3ZSBoYXZlIHNpdHVhdGlvbiB3 aGVyZSB0aGUgc3RhbmRhcmRzIGFsbG93IHVzIHRvIHByb3ZpZGUgc2l0ZXMgdGhlIGNhcGFiaWxp dHkgdG8gaGF2ZSBhIHNpbmdsZSBTQ0FQIGltcGxlbWVudGVkIHBvbGljeSB0aGV5IGNhbGwgb2Zm aWNpYWwgZm9yIHRoZWlyIGVudmlyb25tZW50LiBZZXMgdGhpcyBpcyBhIHJhdGhlciBzaW1wbGlz dGljIHNpbmNlIHRoZXJlIGFyZSB0aGluZ3Mgc3VjaCBhcyB0YXJnZXRpbmcgc3BlY2lmaWMgcGxh dGZvcm1zLCBzcGVjaWZpYyBvcGVyYXRpb25hbCB1c2UgbmVlZHMsIGJ1dCBmb3Igbm93IGxldHMg YWdyZWUgU0NBUCBpcyBhIG1hc3NpdmUgaW1wcm92ZW1lbnQgb3ZlciB0aGUgcHJvcHJpZXRhcnkg c2l0dWF0aW9ucyBvZiB0aGUgcGFzdC4gV2hpbGUgd2UgaGF2ZSBjcmVhdGVkIHRoaXMgc3RhbmRh cmQgY29udGVudCBzbyB0aGF0IHNpdGVzIGNhbiBpbXBsZW1lbnQgdGhlaXIgbG9jYWwgc2l0ZSBz ZWN1cml0eSBvbmNlIGFuZCB0aGVuIGFzc3VyZSB0aGV5IGFyZSBtZWFzdXJpbmcgYWxsIGFwcHJv cHJpYXRlbHkgdGFyZ2V0ZWQgZGV2aWNlcyB0aGUgc2FtZSB3YXksIHdlIGhhdmUgZmFpbGVkIHRv IHN1cHBvcnQgdGhlIG9wZXJhdGlvbmFsIG5lZWRzIG9mIHRoZSBzaXRlcy4gIFdlIGhhdmUgYSBz aXR1YXRpb24gd2hlcmUgbm8gdHdvIHZlbmRvcnMgZGlzdHJpYnV0ZSBjb250ZW50IHRoZSBzYW1l IHdheS4gIFRoaXMgY2F1c2VzIG1hc3NpdmUgcHJvYmxlbXMgZm9yIHRoZSBhZG1pbmlzdHJhdGlv biBzdGFmZiB3aGVuIHRoZXkgbmVlZCB0byBpbmNvcnBvcmF0ZSBhIG5ldyBTQ0FQIGVuYWJsZWQg cHJvZHVjdCBpbnRvIHRoZWlyIGFyY2hpdGVjdHVyZS4gIFRoZXkgbmVlZCB0byBkaXNjb3ZlciBo b3cgdGhlIG5ldyBwcm9kdWN0IHN1cHBvcnRzIGRpc3RyaWJ1dGluZyBTQ0FQIGNvbnRlbnQgdG8g aXQncyB2YXJpb3VzIGNvbXBvbmVudHMuICBJZiB0aGV5IGhhdmUgb25lIHByb2R1Y3QgdGhlbiB0 aGV5IGRvIHRoaXMgb25lIGFuZCB0aGV5IGFyZSBkb25lLiAgSWYgdGhleSBoYXZlIG11bHRpcGxl IHByb2R1Y3RzIHRoZXkgd2lsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgaG93IHRvIG1pbmltaXplIHRo ZSBpbXBhY3QgYnkgaW5jb3Jwb3JhdGluZyB0aGUgdXBkYXRlIHByb2Nlc3MgZm9yIHRoZSBuZXcg cHJvZHVjdCBpbnRvIHRoZSBleGlzdGluZyBTQ0FQIHNlY3VyaXR5IGNvbnRlbnQgcHJvY2Vzc2Vz LiBOb3cgd2hlbiB0aGUgaW5ldml0YWJsZSBoYXBwZW5zIGFuZCB0aGUgc2l0ZSBzdGFmZiBuZWVk cyB0byBtYWtlIGEgY2hhbmdlIHRvIHRoZWlyIHNlY3VyaXR5IHBvbGljeSwgdGhleSBoYXZlIHRv IG1ha2UgdGhlIG1vZGlmaWNhdGlvbnMgdG8gdGhlIGJlbmNobWFyayBvciBjaGVja3Mgb3IgYm90 aCBhbmQgdGhlbiBkaXN0cmlidXRlIHRob3NlIHVwZGF0ZXMgYWNyb3NzIHRoZWlyIG5ldHdvcmsu ICBGb3IgZWFjaCBTQ0FQIGVuYWJsZWQgcHJvZHVjdCB0aGV5IGhhdmUgaW4gcGxhY2UsIHRoZXkg aGF2ZSBkb3VibGVkLCB0cmlwbGVkIG9yIG1vcmUgdGhlIHdvcmsgbmVlZGVkIHRvIG1ha2UgdGhv c2UgdXBkYXRlcyBhdmFpbGFibGUuIA0KDQogDQoNClRoZXJlIGlzIGFub3RoZXIgY29udGVudCBy ZXBvc2l0b3J5IHByb2JsZW0gYW5kIHRoYXQgaXMgdGhlIEZlZGVyYXRlZCBDb250ZW50IERpc3Ry aWJ1dGlvbi4gIElmIHlvdSB0aGluayBnbG9iYWwgRE5TIHlvdSBoYXZlIGEgZ2VuZXJhbCBmcmFt ZSBvZiByZWZlcmVuY2UuICBUaGUgZ3VpZGFuY2UgYXV0aG9ycyBuZWVkIHRvIGJlIGFibGUgdG8g cHVibGlzaCBjb250ZW50IGluIGFuIGF1dGhvcml0YXRpdmUgbWFubmVyIHNvIHRoZWlyIGNvbnRl bnQgaXMgdXBkYXRlZCBpbiBhIHRpbWVseSBmYXNoaW9uLiAgVGhpcyBpcyBhIG11Y2ggaGFyZGVy IHByb2JsZW0gdG8gc29sdmUgaWYgdGhlcmUgaXMgbm8gbG9jYWwgb3JnYW5pemF0aW9uYWwgaW5m cmFzdHJ1Y3R1cmUgdG8gc3VwcG9ydCBpdC4gOykNCg0KIA0KDQpTbyBoZXJlIGlzIHdoYXQgSSBh bSB0aGlua2luZ+KApiAgV2Ugc2hvdWxkIGNvbnNpZGVyIGFkZHJlc3NpbmcgdGhlc2UgYXMgdHdv IHNlcGFyYXRlIGJ1dCBpbnRlZ3JhdGVkIGVmZm9ydHMuICBJIGJlbGlldmUgdGhlIE9yZ2FuaXph dGlvbmFsIENvbnRlbnQgUmVwb3NpdG9yeSBpcyB0aGUgbW9yZSBjcml0aWNhbCBwaWVjZSB0aGF0 IGlzIGFjdHVhbGx5IGVhc2llciB0byBhZGRyZXNzLiAgVGhlIEZlZGVyYXRlZCBDb250ZW50IERp c3RyaWJ1dGlvbiBzaG91bGQgYmUgYSBzdWJzZXF1ZW50IGVmZm9ydCBpbnRlZ3JhdGluZyAvIGF1 Z21lbnRpbmcgdGhlIE9yZ2FuaXphdGlvbmFsIHJlcG9zaXRvcnkgc3BlY2lmaWNhdGlvbi4gDQoN CiANCg0KTWlrZSwgdG8geW91ciBwb2ludCB0aGF0IHdlIG5lZWQgc29tZW9uZSB0byBidWlsZCBv bmUgZmlyc3TigKYgVGhhdCBoYXMgaGFwcGVuZWQgYWxyZWFkeS4gIEkgaGF2ZSBvbmUgYXMgZG8g b3RoZXIgdmVuZG9ycyBidXQgd2hhdCB3ZSBkb27igJl0IGhhdmUgaXMgdGhlIGFjY2VzcyBzcGVj aWZpY2F0aW9uLiAgT3VycyBhcmUgZm9jdXNlZCBvbiBvdXIgc3BlY2lmaWMgcHJvZHVjdCBuZWVk cy4gIEFkZGl0aW9uYWxseSB0aGVyZSBpcyBhIGNvbXBhbnkgdGhhdCBoYXMgZGV2ZWxvcGVkIGEg Y29tbWVyY2lhbCBTQ0FQIGNvbnRlbnQgcmVwb3NpdG9yeSB0aGF0IHdpbGwgYmUgYW5ub3VuY2Vk IGxhdGVyIHRoaXMgbW9udGguIEkgd29uJ3Qgc3RlYWwgdGhlaXIgdGh1bmRlciBidXQgSSB3YXMg cmVjZW50bHkgZ2l2ZW4gYSBzbmVhayBwZWVrIGF0IGl0IGFuZCBJIG11c3QgYWRtaXQgSSB3YXMg dmVyeSBpbXByZXNzZWQuICBBZ2FpbiwgdG8geW91ciBwb2ludCwgaXQgaGFzIGJlZW4gZG9uZS4g V2hhdCBpcyBuZWVkZWQgdG8gYWRkcmVzcyB0aGUgaW5pdGlhbCBvcGVyYXRpb25hbCBwcm9ibGVt IGlzIHRvIGRldmVsb3AgYSBzcGVjaWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBjb25zaXN0ZW50 IG1lYW5zIGZvciBhbGwgU0NBUCBwcm9kdWN0cyB0byByZXRyaWV2ZSB0aGUgYXBwcm9wcmlhdGUg Y29udGVudCBhcyBjb25maWd1cmVkIGFuZCBtYW5hZ2VkIGJ1dCB0aGUgc2l0ZS4gIA0KDQogDQoN ClRPIFRIQVQgRU5E4oCmLg0KDQogDQoNCkkgYW0gcmVxdWVzdGluZyBwYXJ0aWNpcGF0aW9uIGZy b20gdGhvc2UgaW4gdGhlIGNvbW11bml0eSB0aGF0IHNlZSB0aGUgbmVlZCBhbmQgd2FudCB0byBw dXQgaW4gdGhlIHdvcmsgdG8gbWFrZSB0aGlzIHNwZWNpZmljYXRpb24gaGFwcGVuLiAgSSBoYXZl IHRhbGtlZCB0byBhIGNvdXBsZSBvZiB5b3UgYnV0IEkgZG8gbm90IHdhbnQgdG8gYXNzdW1lIHlv dXIgcGFydGljaXBhdGlvbi4gIElmIHlvdSBhcmUgaW50ZXJlc3RlZCBwbGVhc2UgY29udGFjdCBt ZSBzbyB3ZSBjYW4gZ2V0IHRoaXMgc3RhcnRlZC4gDQoNCiANCg0KVGhhbmtzIQ0KDQogDQoNCktl bnQgTGFuZGZpZWxkDQpEaXJlY3RvciBDb250ZW50IFN0cmF0ZWd5LCBBcmNoaXRlY3R1cmUgYW5k IFN0YW5kYXJkcw0KDQpNY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55DQo1MDAwIEhlYWRxdWFydGVy cyBEci4NClBsYW5vLCBUZXhhcyA3NTAyNA0KDQpEaXJlY3Q6ICsxLjk3Mi45NjMuNzA5NiANCk1v YmlsZTogKzEuODE3LjYzNy44MDI2DQpXZWI6IHd3dy5tY2FmZWUuY29tIDxodHRwOi8vd3d3Lm1j YWZlZS5jb20vPiANCg0KIA0KDQpGcm9tOiA8S2lubmV5PiwgTWljaGFlbCBBIDxtLmtpbm5lQHJh ZGl1bS5uY3NjLm1pbD4NClRvOiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0ZXJtaXJlQG5p c3QuZ292PiwgU0NBUC1ERVYgPFNDQVAtREVWQG5pc3QuZ292PiwgInNhY21AaWV0Zi5vcmciIDxz YWNtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzYWNtXSBbT1ZBTC1ERVZFTE9QRVItTElTVF0g U2VjdXJpdHkgQXV0b21hdGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUg aW4gQmVkZm9yZCwgTUENCg0KIA0KDQpEYXZlLA0KDQpJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHdl YmluYXJzLCBJIGRvIHdhbnQgdG8ga2VlcCBkZXZlbG9wZXIgZGF5cyBhY3Rpb25hYmxlIGFuZCB1 c2UgaXQgdG8gbWFrZSBkZWNpc2lvbnMsIGFuZCB2b3RlIGFuZCBhY2NvbXBsaXNoIHRoaW5ncyBn b29kIG9yIGJhZC4gIEkgZG8gbm90IHdhbnQgdGhpcyB0byBiZSBhbiBpbmZvcm1hdGlvbmFsIGJy aWVmaW5nIGNvbmZlcmVuY2UuDQoNClRoYW5rcyBmb3IgdGhlIGxpbmtzLg0KDQogDQoNCkkgc3Rp bGwgdGhpbmsgdGhhdCBhbnkgc3BlY2lmaWNhdGlvbiBmb3IgYSByZXBvc2l0b3J5IGlzIHdpc2hm dWwgdGhpbmtpbmcgdW50aWwgc29tZW9uZSBidWlsZHMgb25lIGFuZCBsZWFybnMgdGhlIGxlc3Nv bnMgaXQgd2lsbCBqdXN0IGJlIGFub3RoZXIgd2hpdGVwYXBlciBzcGVjLiAgSSBiZWxpZXZlIHRo ZSBEb0QgbmVlZHMgdG8gaW5jb3Jwb3JhdGUgYSBtZXRhZGF0YSByZXBvc2l0b3J5IGFzIHBhcnQg b2YgaXQgYW5kIG90aGVyIGN1c3RvbWl6YXRpb25zIHRoYXQgbWF5IG5vdCBiZSB1c2VmdWwgZm9y IGV2ZXJ5b25lLg0KDQpXZSBuZWVkIHRvIHRhbGsgbW9yZeKApg0KDQogDQoNCi1NaWtlICANCg0K IA0KDQpGcm9tOiBXYWx0ZXJtaXJlLCBEYXZpZCBBLiBbbWFpbHRvOmRhdmlkLndhbHRlcm1pcmVA bmlzdC5nb3ZdIA0KU2VudDogVHVlc2RheSwgTWF5IDA4LCAyMDEyIDEwOjQ0IEFNDQpUbzogS2lu bmV5LCBNaWNoYWVsIEE7IFNDQVAtREVWOyBzYWNtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW09W QUwtREVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1 bW1lciAyMDEyIGF0IE1JVFJFIGluIEJlZGZvcmQsIE1BDQoNCiANCg0KTWlrZSwNCg0KIA0KDQpX aGF0IGFib3V0IGhhdmluZyB3ZWJpbmFycyBpbi1wbGFjZSBvZiB0aGUgMzAgbWludXRlIGJyaWVm cz8NCg0KIA0KDQpSZWdhcmRpbmcgY29udGVudCBtYW5hZ2VtZW50LCB3ZSBhcmUgYnVpbGRpbmcg dGhlIHByb3RvdHlwZSBjb250ZW50IHJlcG9zaXRvcnkgZm9yIHVzZSBpbiBhIHByb2R1Y3Rpb24g ZW52aXJvbm1lbnQuICBBcyBhbiBvcGVuIHNvdXJjZSBwcm9qZWN0LCBpdCB3aWxsIGJlIGZyZWUg Zm9yIHVzZSBieSBhbnlvbmUgaW50ZXJlc3RlZC4gIE15IHRoaW5raW5nIGlzIHRoYXQgdGhpcyBw cm9qZWN0IGNhbiBicmlkZ2UgdGhlIGdhcCB1bnRpbCBjb21tZXJjaWFsIHNvbHV0aW9ucyBhcmUg YXZhaWxhYmxlIHRvIGF1Z21lbnQgaXQuICBUaGlzIGlzIGEgc2ltaWxhciBwYXRoIHRoYXQgd2Fz IGZvbGxvd2VkIHdpdGggRE5TIChiaW5kKSBhbmQgSFRUUCAoYXBhY2hlKS4gIFdoZW4gaXQgaXMg cmVhZHkgZm9yIHVzZSwgSSBhbSBob3BpbmcgdG8gdXNlIGl0IHRvIGhvc3QgVVNHQ0IgY29udGVu dC4gIFlvdSB3b3VsZCBiZSB3ZWxjb21lIHRvIHVzZSBpdCBmb3IgeW91ciBuZWVkcy4NCg0KIA0K DQpJdCBpcyBnb29kIHRoYXQgT0NJTCBpcyBtb3ZpbmcgZm9yd2FyZC4gIFRoaXMgaXMgYW4gaW1w b3J0YW50IHBpZWNlIG9mIHN1cHBvcnRpbmcgcmlzayBtYW5hZ2VtZW50IGFuZCBhc3BlY3RzIG9m IGNvbnRpbnVvdXMgbW9uaXRvcmluZy4gIEkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSBzb21lIGRp c2N1c3Npb24gb24gT0NJTCBhdCBEZXZlbG9wZXIgRGF5cy4gIFdpdGggdGhlIHByb3Bvc2FscyB3 ZSB3aWxsIGxpa2VseSBoYXZlIGEgc2Vuc2Ugb2Ygd2hhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQg YW5kIHdoYXQgd2UgY2FuIGFjaGlldmUgY29uc2Vuc3VzIG9uIG91dHNpZGUgdGhlIG1lZXRpbmcu DQoNCiANCg0KUmVtZWRpYXRpb24gaXMgYSB0b3BpYyBuZWFyIGFuZCBkZWFyIHRvIG15IGhlYXJ0 LiAgSSB0b28gd291bGQgbGlrZSB0byBzZWUgaXQgbW92ZSBmb3J3YXJkLg0KDQogDQoNCldlIGp1 c3QgcHVibGlzaGVkIHRoZSBkcmFmdCBBU1Igc3BlY2lmaWNhdGlvbiBmb3IgcHVibGljIGNvbW1l bnQuICBUaGlzIHNwZWNpZmljYXRpb24gc3VwcG9ydHMgZW50ZXJwcmlzZSBhZ2dyZWdhdGUgcmVw b3J0aW5nIHdoaWNoIGdyZWF0bHkgcmVkdWNlcyB0aGUgZGF0YSB2b2x1bWVzIG5lZWRlZCB2ZXJz ZXMgZGV0YWlsZWQgaG9zdC1iYXNlZCByZXBvcnRzLiBUaGlzIHNwZWNpZmljYXRpb24gaGFzIGJl ZW4gZGVzaWduZWQgYXMgYSBtb3JlIHJvYnVzdCByZXBsYWNlbWVudCBmb3IgTEFTUi4gIEl0IGNh biBiZSB1c2VkIGluIGNvbnRpbnVvdXMgbW9uaXRvcmluZyBhcHBsaWNhdGlvbnMgdG8gc3VwcG9y dCBhZ2dyZWdhdGUgZGF0YSByZXBvcnRpbmcgbmVlZHMgKGUuZy4gRklTTUEgcmVwb3J0aW5nLCAg Q3liZXJTY29wZSkuDQoNCiANCg0KSGVyZSBhcmUgdGhlIGxpbmtzOg0KDQogDQoNCmh0dHA6Ly9j c3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9QdWJzRHJhZnRzLmh0bWwNCg0KaHR0cDovL2NzcmMu bmlzdC5nb3YvcHVibGljYXRpb25zL1B1YnNOSVNUSVJzLmh0bWwjTklTVC1JUi03ODQ4DQoNCiAN Cg0KVGhlIHByaW1hcnkgcmVhc29uIHdlIGhhdmUgc3VnZ2VzdGVkIHdhaXRpbmcgb24gWENDREYg aXMgbm90IHRoZSBpbnRlcm5hdGlvbmFsaXphdGlvbiBpc3N1ZS4gTWFueSB2ZW5kb3JzIGhhdmUg Y29tbWVudGVkIHRoYXQgdGhleSBhcmUgc3RpbGwgd29ya2luZyBvbiBpbXBsZW1lbnRpbmcgdGhl IFhDQ0RGIDEuMi4xIHNwZWNpZmljYXRpb24uIFdlIHdpbGwgYmUgaW4gYSBiZXR0ZXIgcGxhY2Ug aW4gYSBmZXcgbW9udGhzIG9uY2UgbW9yZSBkZXZlbG9wbWVudCBhcm91bmQgWENDREYgaGFzIG9j Y3VycmVkLiAgQXMgd2UgY29uc2lkZXIgY2hhbmdlcyB0byB0aGUgU0NBUCBzdGFjayB0byBhZGRy ZXNzIE9DSUwgYW5kIG90aGVyIGlzc3Vlcywgd2Ugd2lsbCBpZGVudGlmeSBhcmVhcyB0aGF0IG5l ZWQgaW1wcm92ZW1lbnQgaW4gWENDREYuICBUaGVzZSBhcmUgZ29vZCBhbmQgbmVjZXNzYXJ5IGRp c2N1c3Npb25zIHRvIGhhdmUgbm93LCBidXQgd2UgaGF2ZSBhIGdvb2QgZGVhbCBvZiB3b3JrIHRv IGRvIGJlZm9yZSB3ZSBhcmUgcmVhZHkgdG8gb3BlbiB1cCBYQ0NERi4gIE15IHN1Z2dlc3Rpb24g aXMgdG8gd29yayBvbiB0aGVzZSByZWxhdGVkIGFyZWFzIGFuZCB0aGVuIHdvcmsgdXAgY2hhbmdl IHByb3Bvc2FscyBmb3IgWENDREYgYXMgbmVlZGVkLiAgQnkgdGhhdCB0aW1lIHdlIHNob3VsZCBi ZSByZWFkeSB0byB3b3JrIG9uIGEgbmV3IHJldmlzaW9uIG9mIFhDQ0RGLg0KDQogDQoNCkkgYW0g YWxzbyBsb29raW5nIGZvcndhcmQgdG8gdGhlIGRpc2N1c3Npb25zIGF0IHRoZSBjb25mZXJlbmNl LiAgSXQgaGFzIGJlZW4gdG9vIGxvbmcuDQoNCiANCg0KU2luY2VyZWx5LA0KDQpEYXZlDQoNCiAN Cg0KRnJvbTogS2lubmV5LCBNaWNoYWVsIEEgW21haWx0bzptLmtpbm5lQHJhZGl1bS5uY3NjLm1p bF0gDQpTZW50OiBUdWVzZGF5LCBNYXkgMDgsIDIwMTIgNzowOSBBTQ0KVG86IFNDQVAtREVWDQpD YzogV2FsdGVybWlyZSwgRGF2aWQgQS4NClN1YmplY3Q6IFJFOiBbT1ZBTC1ERVZFTE9QRVItTElT VF0gU2VjdXJpdHkgQXV0b21hdGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlU UkUgaW4gQmVkZm9yZCwgTUENCg0KIA0KDQpLZW50LA0KDQogDQoNCkl04oCZcyBnb29kIHRvIHJl YWQgeW91ciB0aG91Z2h0cywgYW5kIGEgcmVhbGlzdGljIGFjdGlvbmFibGUgYXBwcm9hY2ggaXMg aW5kZWVkIG5lZWRlZC4gIFNpbmNlIGFsbCB0aGUgYWN0aXZpdHkgaGFzbuKAmXQgYmVlbiBvbiB0 aGUgbGlzdHMgYSBicmllZiAxxb0yIGhvdXIgcmVjYXAgbWF5IGJlIGluIG9yZGVyIHRvIGJyaW5n IGV2ZXJ5b25lIHVwIHRvIHNwZWVkIHNpbmNlIHRoZXJlIGhhcyBiZWVuIGEgbG90IG9mIGFjdGl2 aXR5IG9uIENQRS9TV0lELCBPQ0lsLCBNQUVDL0N5Yk9YIENFRSBhbmQgb3RoZXJzLg0KDQogDQoN CldlIGNvdWxkIHdyaXRlIGEgY29udGVudCByZXBvc2l0b3J5IHNwZWNpZmljYXRpb24sIGJ1dCB3 aXRob3V0IHNvbWVvbmUgd2lsbGluZyB0byBzdGFuZCBvbmUgdXAgaXQgd2lsbCBiZSBhcyB2YWx1 YWJsZSBhcyB0aGUgQ0NTUyBzcGVjaWZpY2F0aW9uIGlzIHRvZGF5LiAgSeKAmXZlIGJlZW4gdHJ5 aW5nIGZvciB0d28geWVhcnMgdG8gZ2V0IG15IG1hbmFnZW1lbnQgdG8gZ2V0IGEgY29vcmRpbmF0 ZWQgZWZmb3J0IHRvZ2V0aGVyIGZvciB0aGUgRG9EIHRvIHN0YW5kIHVwIGEgcmVwb3NpdG9yeSwg aXQgaXMgYSB0b3VnaCBwcm9ibGVtIGFuZCB3aWxsIHJlcXVpcmUgZnVuZGluZyB3aXRoIGEgdGFp bCwgSeKAmW0gbm90IHN1cmUgYSBzcGVjaWZpY2F0aW9uIHdpbGwgc29sdmUgdGhhdCBwcm9ibGVt Lg0KDQogDQoNCldlIChEb0QpIGhhdmUgYmVlbiBwdXR0aW5nIGEgbG90IG9mIGVmZm9ydCBpbnRv IE9DSUwgb3ZlciB0aGUgbGFzdCB5ZWFyIHRyeWluZyB0byBtYWtlIGl0IHVzZWZ1bCBpbiBhbiBl bnRlcnByaXNlIGVudmlyb25tZW50IGFuZCB3aWxsIGJlIHBvc3Rpbmcgb3VyIGlkZWFzIHRvIHRo ZSBsaXN0IGJlZm9yZSBkZXZlbG9wZXIgZGF5cyBpdCBzaG91bGQgaGF2ZSBhbHJlYWR5IHN0YXJ0 ZWQsIHdlIG5lZWQgdG8gZ2V0IGNvbnNlbnN1cyBhbmQgYSB2b3RlIG9uIGhvdyB0aGUgY29tbXVu aXR5IHdpc2hlcyB0byBwcm9jZWVkLg0KDQogDQoNClJlbWVkaWF0aW9uIGlzIHN0YWxsZWQgYnV0 IEnigJltIG1ha2luZyBldmVyeSBlZmZvcnQgdG8gZ2V0IGl0IGtpY2sgc3RhcnRlZCBmcm9tIG91 ciBwZXJzcGVjdGl2ZS4gSSBob3BlIHRvIGFzc2lzdCBpbiBnZXR0aW5nIHRoZSBkcmFmdCBFUkkg ZmluaXNoZWQgdGhpcyB5ZWFyLiAgV2UgYXJlIHdyaXRpbmcgc29tZSBuZXcgU1RJRyBjb250ZW50 IGFuZCBpbnRlbmQgdG8gdXNlZCB0aGUgZHJhZnQgQ1JFIHNwZWNpZmljYXRpb24gdG8gaW5zZXJ0 IENSRSBpbnRvIHRoZSBjb250ZW50IHNvIHdlIChEb0QpIGNhbiBkbyBzb21lIGF1dG9tYXRpYyBj b25maWd1cmF0aW9uIGZpeGVzLCBwYXJ0IG9mIGEgc2VsZiBoZWFsaW5nIG5ldHdvcmsgY29uY2Vw dC4gSXQgaXMganVzdCBhIHN0YXJ0IGJ1dCB0aGUgYmVzdCB3ZSBjYW4gZG8gYXQgdGhpcyBwb2lu dC4NCg0KIA0KDQpFbnRlcnByaXNlIHJlcG9ydGluZyBpcyBhbiBpbnRlcmVzdGluZyBzdWJqZWN0 LCBzaW5jZSBYTUwgYWRkcyBzaXplIHRvIGFuZCBjb250ZW50IHRvIHJvbGwgdXAgcmVwb3J0aW5n LCBpbiBhbnkgZW50ZXJwcmlzZSBvZiBzaXplIHRoZSBwcm9ibGVtIGdldHMgZ3JlYXRlciwgSSBs b29rIGZvcndhcmQgdG8geW91ciB0aG91Z2h0cyBvbiB0aGF0IHN1YmplY3QuDQoNCiANCg0KSSBh bSBjb25jZXJuZWQgdGhhdCB0aGUgaW50ZXJuYXRpb25hbGl6YXRpb24gZWZmb3J0cyBhcmUgZGV0 cmFjdGluZyBmcm9tIGVmZm9ydHMgdG8gbWVldCB1c2UgY2FzZXMsIHdlIGhhdmUgc29tZSB0aGlu Z3Mgd2Ugd291bGQgbGlrZSBjaGFuZ2VkIGluIFhDQ0RGIHRvIHN1cHBvcnQgb3VyIE9DSWwgdXNl IGNhc2UgYW5kIEkgaGF2ZSBiZWVuIHRvbGQgdGhhdCBJIG5lZWQgdG8gd2FpdC4gSSBkaWRu4oCZ dCB0aGluayB0aGF0IGEgbW92ZSB0byBpbnRlcm5hdGlvbmFsaXphdGlvbiBzaG91bGQgaW1wZWRl IGVmZm9ydHMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdXNlIGNhc2VzLg0KDQogDQoNCkkgbG9vayBm b3J3YXJkIHRvIHRhbGtpbmcgd2l0aCB5b3UgYXQgdGhlIGNvbmZlcmVuY2UuDQoNCiANCg0Kdi9y DQoNCiANCg0KTWlrZSBLaW5uZXkNCg0KUHJvamVjdCBEaXJlY3Rvcg0KDQpDb21wdXRlciBOZXR3 b3JrIERlZmVuc2UgUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgKENORCBSJlQpIE9mZmljZQ0KDQo5 ODAwIFNhdmFnZSBSb2FkIFN0ZSA2NzY3DQpGdCBNZWFkZSwgTUQgMjA3NTUtNjc2Nw0KUGhvbmU6 IDQxMC04NTQtNDQyMg0KTlNUUzogOTY4LTg4ODYNCkZheCA0MTAtODU0LTQ2ODENCg0KIDxtYWls dG86TS5raW5uZUByYWRpdW0ubmNzYy5taWw+IG1ha2lubjJAbnNhLmdvdg0KDQogDQoNCiANCg0K IA0KDQpGcm9tOnNjYXAtZGV2QG5pc3QuZ292IFttYWlsdG86c2NhcC1kZXZAbmlzdC5nb3ZdIE9u IEJlaGFsZiBPZiBXYWx0ZXJtaXJlLCBEYXZpZCBBLg0KU2VudDogTW9uZGF5LCBNYXkgMDcsIDIw MTIgNzowOSBQTQ0KVG86IE11bHRpcGxlIHJlY2lwaWVudHMgb2YgbGlzdA0KU3ViamVjdDogUkU6 IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlz OiBTdW1tZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQQ0KDQogDQoNCktlbnQsDQoNCiAN Cg0KSSBsaWtlIHdoYXQgeW91IGFyZSBzYXlpbmcgaGVyZS4gIFdlIGFyZSBhbHNvIGluIHN1cHBv cnQgb2YgdGhpcyB0eXBlIG9mIGFwcHJvYWNoLiAgV2Ugd291bGQgbGlrZSB0byBzZWUgc29tZSBj b21tdW5pdHkgZGlzY3Vzc2lvbiBhcm91bmQgd2hhdCBhcmUgdGhlIGtleSBhcmVhcy9wcmlvcml0 aWVzIHRoYXQgdGhlIGNvbW11bml0eSB3b3VsZCBsaWtlIHRvIHNlZSBkaXNjdXNzZWQgYXQgRGV2 IERheXMuICBZb3VyIHRvcGljcyBiZWxvdyBsb29rIGxpa2UgYSBnb29kIHN0YXJ0LiBUaGUgU0FD TSBsaXN0IG1pZ2h0IGJlIGEgYmV0dGVyIHZlbnVlIHRoYW4gdGhlIE9WQUwgbGlzdCBmb3IgdGhp cyBkaXNjdXNzaW9uLiAgRm9yIGVhY2ggYXJlYSB3ZSBzaG91bGQgZm9jdXMgdGhlIGRpc2N1c3Np b24gYXJvdW5kIGRldmVsb3Bpbmcgb2JqZWN0aXZlcyBmb3IgZWFjaCBzZXNzaW9uLiAgVGhlIHNl c3Npb25zIGNhbiBiZSB0aW1lIGJveGVkIGJhc2VkIG9uIHdoYXQgd291bGQgYmUgYSByZWFzb25h YmxlIGFtb3VudCBvZiB0aW1lIHRvIGFjY29tcGxpc2ggZWFjaCBvYmplY3RpdmUuICBGb3IgZXhh bXBsZSBpZiBjb250aW51b3VzIG1vbml0b3JpbmcgaXMgYSBwcmlvcml0eSBhbmQgY29sbGVjdGl2 ZWx5IGl0IHRha2VzIDMgZGF5cyB0byB3b3JrIHRocm91Z2ggYWxsIHRoZSBvYmplY3RpdmVzLCBJ IHNlZSBubyBwcm9ibGVtIHdpdGggdGhhdC4gIFdlIGNhbiBhbHNvIGtlZXAgYSBmZXcgc2Vzc2lv bnMg4oCcb24gZGVja+KAnSBpZiBhbGwgdGhlIG9iamVjdGl2ZXMgYXJlIHJlYWNoZWQgYW5kIHdl IGNvbXBsZXRlIGFsbCB0aGUgc2NoZWR1bGVkIHNlc3Npb25zIGVhcmx5Lg0KDQogDQoNClRob3Vn aHRzPw0KDQogDQoNClNpbmNlcmVseSwNCg0KIA0KDQpEYXZpZCBXYWx0ZXJtaXJlDQoNClNDQVAg QXJjaGl0ZWN0DQoNCk5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xv Z3kNCg0KKDMwMSkgOTc1LTMzOTANCg0KZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdg0KDQogDQoN CkZyb206c2NhcC1kZXZAbmlzdC5nb3YgW21haWx0bzpzY2FwLWRldkBuaXN0Lmdvdl0gT24gQmVo YWxmIE9mIEtlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20NClNlbnQ6IE1vbmRheSwgTWF5IDA3LCAy MDEyIDQ6MjUgUE0NClRvOiBTQ0FQLURFVg0KU3ViamVjdDogUmU6IFtPVkFMLURFVkVMT1BFUi1M SVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlzOiBTdW1tZXIgMjAxMiBhdCBN SVRSRSBpbiBCZWRmb3JkLCBNQQ0KDQogDQoNCkFsbCwNCg0KIA0KDQpJIHdvdWxkIGxpa2UgdG8g ZGlzY3VzcyB0aGUgZm9ybWF0IGZvciB0aGUgU0NBUCBEZXZlbG9wZXIgRGF5cyB0aGF0IHNlZW1z IHRvIGJlIGxpc3RlZCBiZWxvdy4NCg0KIA0KDQpJIHNlZSB0aGlzIGFwcGVhcnMgdG8gZm9sbG93 IGEgcGF0aCB3ZSBoYXZlIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCBhcyB0aGUgd2F5IG5vdCB0byBo b2xkIGEgRGV2IERheXMgZXZlbnQuICBXZSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGdldCBhd2F5IGZy b20gJ0RlYXRoIGJ5IFBvd2VycG9pbnQnIGFuZCBiYWNrIHRvIHRoZSB0eXBlIG9mIGV2ZW50IHdl IGhlbGQgeWVhcnMgYWdvIHdoZW4gd2Ugd2VyZSBoaWdobHkgcHJvZHVjdGl2ZS4gIEluIHRoZSBw YXN0IHdlIGhhZCBhIHRvcGljIHRvIGJlIGRpc2N1c3NlZCBhbmQgYSB0aW1lIGJveCB0byB3b3Jr IHdpdGhpbi4gIFRoYXQgYWxsb3dlZCB1cyB0byBoYXZlIHZlcnkgYWN0aXZlIGJyYWluc3Rvcm1p bmcgc2Vzc2lvbnMgaW4gYSBoaWdoIGJhbmR3aWR0aCBlbnZpcm9ubWVudC4NCg0KIA0KDQpBdCBw YXN0IFN1bW1lciBldmVudHMgd2UgaGF2ZSBnb3QgaW50byBhIHBhdHRlcm4gb2YgbG90cyBvZiBw b3dlcnBvaW50LCBsb3RzIG9mIHN0YXR1cyBvZiB0aGUgZWZmb3J0cyBhbmQgdmVyeSBsaXR0bGUg ZGlzY3Vzc2lvbiBhYm91dCB0aGluZ3MgdGhhdCBuZWVkIGFjdGl2ZSBkaXNjdXNzaW9ucy4gIFdl IG5lZWQgdG8ga2VlcCBtb3ZpbmcgZm9yd2FyZCBhbmQgbWFraW5nIHByb2dyZXNzIGFzIGFuIGVm Zm9ydC4gV2UgY2FuIGdldCBzdGF0dXMgZnJvbSB2YXJpb3VzIHBsYWNlcyBzdWNoIGFzIHRoZSBs aXN0cywgYSBwcmVzZW50YXRpb24gYmVpbmcgc2VudCBvdXQgaW4gYWR2YW5jZSwgYSB3ZWJpbmFy IGlmIGl0IGlzIGZlbHQgdGhlcmUgd2lsbCBiZSBxdWVzdGlvbnMgYW5kIGFuc3dlcnMgZnJvbSB0 aG9zZSB0aGF0IGFyZSBuZXcgdG8gdGhlIGVmZm9ydHMuICBXZSBoYXZlIGEgbGltaXRlZCBhbW91 bnQgb2YgdGltZSBhbmQgYWxsIHdobyBhcmUgYXR0ZW5kaW5nIGFyZSBpbnZlc3RpbmcgYSBncmVh dCBkZWFsIG9mIHRpbWUgYW5kIG1vbmV5IHRvIGJlIHRoZXJlLiAgV2Ugc2hvdWxkIG5vdCAgYmUg c3BlbmRpbmcgYSBncmVhdCBkZWFsIG9mIHRpbWUgcmVlZHVjYXRpbmcgZXZlcnlvbmUgd2hlbiB3 ZSBjb3VsZCBiZSBmb2N1c2VkIG9uIGFkdmFuY2luZyBuZWVkZWQgZWZmb3J0cy4NCg0KIA0KDQpU aGUgdHlwZSBvZiBhcHByb2FjaCB0byBhIERldiBEYXlzIGV2ZW50IHdhcyBkaXNjdXNzZWQgYXQg dGhlIGxhc3QgU3VtbWVyIERldiBEYXlzLiAgSSBoYXZlIHNlZW4gdGhlIGZvbGxvd2luZyB3b3Jr IHF1aXRlIHdlbGwgaW4gb3RoZXIgZWZmb3J0cy4NCg0KMS4JUHJlc2VudGF0aW9ucyBhcmUgc2Vu dCBvdXQgdG8gdGhlIGF0dGVuZGVlcyBhbmQgdGhlIGxpc3RzIGEgd2VlayBpbiBhZHZhbmNlLg0K Mi4JU3RhdHVzIGZvciBhbnkgZWZmb3J0IGlzIGxpbWl0ZWQgdG8gMzAgbWludXRlcw0KMy4JRm9j dXNlZCBicmFpbnN0b3JtaW5nIHRpbWUgc2hvdWxkIGJlIGVzdGFibGlzaGVkIGZvciBjZXJ0YWlu IGFyZWFzIHRoYXQgbmVlZCByZWFsIHdvcmsgYnkgdGhlIGNvbW11bml0eQ0KNC4JRWZmb3J0cyB0 byBiZSBkaXNjdXNzZWQgc2hvdWxkIGJlIGJhc2VkIG9uIG5lZWRzIG9mIHRoZSBzZWN1cml0eSBh dXRvbWF0aW9uIHNwYWNlIHRvIG1vdmUgZXhpc3RpbmcgZWZmb3J0cyB0byBjb21wbGV0aW9uLg0K DQpGb3IgZXhhbXBsZToNCg0KIA0KDQpDb250aW51b3VzIG1vbml0b3JpbmcgaXMgYSBtYWpvciBk aXJlY3Rpb24gdGhlIGVmZm9ydHMgYXJlIGJlY29taW5nIGludm9sdmVkIHdpdGguIFRoZXJlIGFy ZSBnb2luZyB0byBiZSB0aGluZ3Mgd2UgbmVlZCB0byBkbyBhcyBhIHNlY3VyaXR5IGF1dG9tYXRp b24gY29tbXVuaXR5IHRvIGJlIGFibGUgdG8gYWNjb21wbGlzaCB3aGF0IGlzIGxpc3RlZCBpbiB0 aGUgQ0FFU0FSUyBGRS4gIFRoZXJlIGFyZSBpbnRlcmZhY2VzIHRoYXQgbmVlZCB0byBiZSB3b3Jr ZWQgYW5kIGVzdGFibGlzaGVkLiAgVGhhdCBpcyBvbmUgYXJlYSB0aGF0IGlzIG5vdCBsaXN0ZWQg YmVsb3cuICBDTSB3aWxsIGhhdmUgYSBtYWpvciBpbXBhY3Qgb24gYWxsIG9mIHVzIGluIHRoZSBu ZXh0IGNvdXBsZSB5ZWFycyBhbmQgaXQgaXMgYmVpbmcgaWdub3JlZC4gIFdlIGNhbid0IGtlZXAg dHJ5aW5nIHRvIHNvbHZlIHdoYXQgaGFzIGFscmVhZHkgYmVlbiBzb2x2ZWQuICBXZSBuZWVkIHRv IGFkZHJlc3MgdGhlIG5lZWRlZCBpbnRlcmZhY2UgZGV2ZWxvcG1lbnQgbm93LiBUaGlzIGlzIGFu IGVmZm9ydCB0aGF0IGNvdWxkIHRha2UgbmVhcmx5IGEgd2hvbGUgZGF5IGJ5IGl0c2VsZi4NCg0K IA0KDQpPcGVyYXRpb25hbGx5IHdlIGhhdmUgYSByZWFsIG5lZWQgdG8gYmUgYWJsZSB0byBkZWxp dmVyIFNDQVAgY29udGVudCBpbnRlcm5hbGx5IHdpdGhpbiBhbiBvcmdhbml6YXRpb24uIFRvZGF5 IHRoZSBTQ0FQIHZlbmRvcnMgY2Fubm90IHNoYXJlIGEgc2luZ2xlIGxvY2FsIHNpdGUgc2VjdXJp dHkgcG9saWN5IChYQ0NERiArIE9WQUwgKyBDUEUgK+KApikgd2l0aG91dCB0aGUgc2l0ZSBzdGFm ZiBoYXZpbmcgdG8gZ28gdG8gZWFjaCBvZiB0aGUgaW5kaXZpZHVhbCBwcm9kdWN0cyBhbmQgZmln dXJpbmcgb3V0IGhvdyB0byBpbmplY3QgdGhhdCBuZXcgb3IgdXBkYXRlZCBwb2xpY3kgaW50byB0 aGF0IHByb2R1Y3RzIGRlbGl2ZXJ5IG1lY2hhbmlzbXMuICBUaGF0IGlzIGxpbWl0aW5nIHNpdGVz IGZyb20gd2FudGluZyB0byBidXkgbXVsdGlwbGUgZm9jdXNlZCBTQ0FQIHByb2R1Y3RzIHNpbmNl IHRoZXkgYXJlIHN1Y2ggYSBwYWluIHRvIG1hbmFnZSBmcm9tIGEgY29udGVudCBwZXJzcGVjdGl2 ZS4gIEl0IGlzIGVhc2llciB0byBidXkgZnJvbSBvbmUgdmVuZG9yIHRoYXQgaGFzIGEgc2luZ2xl IG1lYW5zIGZvciBkaXN0cmlidXRpbmcgY29udGVudCB0aGFuIGl0IGlzIHRvIGRlYWwgd2l0aCB0 aGUgbWFuYWdlbWVudCBpc3N1ZXMgdGhhdCBoYXZpbmcgbXVsdGlwbGUgU0NBUCBwcm9kdWN0cyBw cmVzZW50cy4gIFdlIG5lZWQgdG8gaGF2ZSBhdCBsZWFzdCBhbiBlbnRpcmUgMS8yIGEgZGF5IG9u IHRoZSBkZXZlbG9wbWVudCBvZiBhIENvbnRlbnQgUmVwb3NpdG9yeSBzcGVjaWZpY2F0aW9uLg0K DQogDQoNCk9DSUwgaXMgYSBwb3NpdGl2ZSBhbmQgYSBuZWdhdGl2ZSBhdCB0aGUgc2FtZSB0aW1l LiBJdCBoYXMgcmVhbCB2YWx1ZSB0aGF0IGlzIGJlaW5nIHVuZGVydXRpbGl6ZWQgYW5kIHVuZGVy IGltcGxlbWVudGVkIGJlY2F1c2Ugb2YgdGhlIGxpbWl0YXRpb25zIG9mIGhvdyBpdCBhZGRyZXNz ZXMgdXNlcyBpbiBhbiBlbnRlcnByaXNlIGVudmlyb25tZW50LiAgUGVvcGxlIGRvbid0IG5lZWQg c2VjdXJpdHkgYXV0b21hdGlvbiB0byBkbyB0aGluZ3Mgb24vZm9yIGEgc2luZ2xlIGhvc3QuICBU aGV5IG5lZWQgc2VjdXJpdHkgYXV0b21hdGlvbiB0byBmb2N1cyBvbiB0aGUgZW50ZXJwcmlzZSBp c3N1ZXMgdGhhdCByZWR1Y2UgdGhlaXIgY29zdHMgYW5kIGltcHJvdmUgdGhlaXIgZWZmaWNpZW5j aWVzLiAgT0NJTCBpcyBmYWlsaW5nIGluIHRoZSBlbnRlcnByaXNlIGFuZCB3ZSBhbGwgdW5kZXJz dGFuZCB0aGF0LiAgV2UgbmVlZCB0byBhZGRyZXNzIGRldmVsb3BpbmcgYSBkZWZpbml0aXZlIHNv bHV0aW9uIGZvciBpbmNvcnBvcmF0aW5nIE9DSUwgaW50byB0aGUgZW50ZXJwcmlzZSBhbmQgdGhh dCBtZWFucyBpbnRvIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy4gU2NoZWR1bGluZyBhbmQg dHJhY2tpbmcgYXJlIGtleSB0byBpdCdzIHN1Y2Nlc3MuICBXZSBuZWVkIHRvIG1ha2UgdGhhdCBo YXBwZW4uICBUaGlzIHRvbyBuZWVkcyBhIGZvY3VzZWQgYnJhaW5zdG9ybWluZyB0aW1lIGJveCB0 byBkaXNjdXNzIG9wdGlvbnMuDQoNCiANCg0KSSBhbSByZWFsbHkgZGlzYXBwb2ludGVkIHRoYXQg UmVtZWRpYXRpb24gaXMgbm90IG9uIHRoZSBsaXN0IGJlbG934oCmICBZZXMsIGxhc3QgU3VtbWVy IERldiBEYXlzLCB0aGUgdGltZSBzcGVudCBvbiBSZW1lZGlhdGlvbiB3YXMgd2FzdGVkIHRpbWUg YnV0IHRoYXQgZG9lcyBub3QgbWVhbiB3ZSBzaG91bGQgaWdub3JlIGl0IGFuZCBub3QgdHJ5IHRv IG1ha2Ugc29tZSByZWFsIHByb2dyZXNzLiAgQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkIHdlIG5l ZWQgdG8gcmVib290IHRoZSByZW1lZGlhdGlvbiBlZmZvcnQuICBXZSBjYW5ub3Qga2VlcCBiZWlu ZyB0aGUgc2V0IG9mIHNwZWNpZmljYXRpb25zIC8gdG9vbHMgdGhhdCBhY3QgYXMgdGhlIGxpdHRs ZSBib3kgY3J5aW5nICJXb2xmIiBpbiB0aGUgbmlnaHQuICBXZSBuZWVkIHRvIGJlIGFibGUgdG8g ZmluZCBhbmQgZml4IGlzc3VlcyBpZiB3ZSBhcmUgZ29pbmcgdG8gcmVhbGx5IG1ha2UgYSBkaWZm ZXJlbmNlIGluIG9yZ2FuaXphdGlvbmFsIHNlY3VyaXR5IHBvc3R1cmVzLiAgQnV0IHRvZGF5IHdl IHRoaW5rIGl0IGlzIHRvbyBoYXJkIHNvIHdlIGRvbid0IHRyeSA/ICBJIHRoaW5rIHdlIG5lZWQg YSBjb3VwbGUgaG91cnMgdG8gZGlzY3VzcyB0aGUgcmVib290IG9mIHRoZSBlZmZvcnQgZXZlbiBp ZiB0aGF0IG1lYW5zIG1pbmltaXppbmcgd29yayBhbHJlYWR5IGRvbmUuDQoNCiANCg0KQSBmb2N1 c2VkIGRpc2N1c3Npb24gb24gZW50ZXJwcmlzZSByZXBvcnRpbmcgaXMgYWxzbyBjcml0aWNhbGx5 IG5lZWRlZC4gIEZvciB0aGUgdmVuZG9ycyBoZXJlLCB3ZSBoYXZlIGFsbCBnb25lIHRocm91Z2gg dGhlIEN5YmVyc2NvcGUgZ29hdCByb3BlLCBkZWxpdmVyaW5nIGxpbWl0ZWQgY2FwYWJpbGl0aWVz IHRvIHNwZWNpZmljIGRhdGEgY2FsbCByZXF1aXJlbWVudHMgb2YgdGhlIEZlZGVyYWwgQWdlbmNp ZXMuICBUaGUgaW5pdGlhbCBlZmZvcnQgd2FzIGEgbWVzcywgZGlkIGxpdHRsZSBtb3JlIHRoYW4g cHJvdmUgaXQgd2FzIHBvc3NpYmxlIGFuZCBjYXVzZSB0aGUgdmVuZG9yIGNvbW11bml0eSBhIGdy ZWF0IGRlYWwgb2YgdGhyYXNoaW5nIHRvIHB1dCBhIGtsdWRnZXkgJ3NvbHV0aW9uJyBpbiBwbGFj ZS4gIFJlYWxpdHkgaXMgYWxsIG91ciBjdXN0b21lcnMgbmVlZCByb2xsIHVwIHJlcG9ydGluZyBh bmQgYW4gaW5mcmFzdHJ1Y3R1cmUgdGhhdCBzdXBwb3J0cyBpdC4gIEEgZGF0YSBjYWxsIHNob3Vs ZCBub3QgYmUgc3BlY2lhbCB0byBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgYWdlbmNpZXMgcmVzcG9u ZGluZy4gVGhlIHRvb2xzIHNob3VsZCBiZSBhYmxlIHRvIHNlbGVjdCB0aGUgdHlwZXMgb2YgZGF0 YSBuZWVkZWQgYW5kIGRlbGl2ZXIgdGhhdCBvbiBhIHNjaGVkdWxlZCBiYXNpcyBhdXRvbWF0aWNh bGx5LiAgICBFbnRlcnByaXNlIFJlcG9ydGluZyBwZXJ0YWlucyB0byBjb21tZXJjaWFsIGFzIHdl bGwgYXMgRmVkZXJhbCBjdXN0b21lcnMuICBXZSBuZWVkIHRvIGZvY3VzIHNvbWUgdGltZSBvbiB3 aGF0IHRoYXQgd291bGQgbG9vayBsaWtlIHVzaW5nIHRoZSBBUkYgYW5kIEFTUiBhcyB0aGUgZm91 bmRhdGlvbmFsIHBpZWNlcy4gIEJ1dCB0aGVyZSBhcmUgbWlzc2luZyBwaWVjZXPigKYuICBXZSBu ZWVkIHRoaXMgZGlzY3Vzc2VkLg0KDQogDQoNCkkgd291bGQgaG9wZSB3ZSBjYW4gbWFrZSB0aGlz IHN1bW1lcidzIFNDQVAgRGV2IERheXMgdXNlZnVsIGluIGFkdmFuY2luZyB0aGUgc2VjdXJpdHkg YXV0b21hdGlvbiBlZmZvcnRzIGJ5IGFkZHJlc3Npbmcgc29tZSBvZiB0aGUgbW9yZSBjcml0aWNh bCBpc3N1ZXMgb3VyIGN1c3RvbWVycyBhcmUgZmFjaW5nIG5vdyBvciB3aWxsIGJlIGZhY2luZyBp biB0aGUgdmVyeSBzaG9ydCB0ZXJtLiAgU3RhdHVzIHByZXNlbnRhdGlvbnMgYXJlIG5vdCBpbnRl cmVzdGluZyB0byB0aG9zZSBhY3RpdmUgaW4gdGhlIGVmZm9ydHMuICBMZXQncyB0cnkgdG8gZG8g dGhvc2UgYmVmb3JlIHdlIGdldCB0byBCZWRmb3JkIHNvIHdlIGNhbiByZWFsIG1ha2Ugc29tZSBw cm9ncmVzcyB3aGlsZSB3ZSBhcmUgYWxsIGluIHRoZSBzYW1lIHJvb20uICBUaGlzIGlzIGFsd2F5 cyBhIGJpZyBldmVudCBmb3IgdGhlICdjb25zZW5zdXMgb2YgdGhlIHdpbGxpbmcnIHRoYXQgYXNz ZW1ibGUgYW5kIGRyaXZlbiB0byBzZWUgc2VjdXJpdHkgYXV0b21hdGlvbiBtYWtlIGEgZGlmZmVy ZW5jZS4gIExldCdzIHNlZSBpZiB3ZSBjYW4gaGF2ZSBhbiBldmVudCB0aGF0LCB3aGVuIHdlIGFs bCB3YWxrIG91dCB0aGUgbGFzdCBkYXksIHdlIGFsbCBmZWVsIHRoYXQgZXZlcnkgbWludXRlIHdh cyB3ZWxsIHNwZW50IGFuZCBtb3ZlcyB1cyBmb3J3YXJkLg0KDQogDQoNClRoYW5rcy4NCg0KIA0K DQpLZW50IExhbmRmaWVsZA0KRGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJl IGFuZCBTdGFuZGFyZHMNCg0KTWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueQ0KNTAwMCBIZWFkcXVh cnRlcnMgRHIuDQpQbGFubywgVGV4YXMgNzUwMjQNCg0KRGlyZWN0OiArMS45NzIuOTYzLjcwOTYg DQpNb2JpbGU6ICsxLjgxNy42MzcuODAyNg0KV2ViOiB3d3cubWNhZmVlLmNvbSA8aHR0cDovL3d3 dy5tY2FmZWUuY29tLz4gDQoNCiANCg0KRnJvbTogPEJvY3plbm93c2tpPiwgU3RldmUgPHNib2N6 ZW5vQE1JVFJFLk9SRz4NClJlcGx5LVRvOiAiT1ZBTCBEZXZlbG9wZXIgTGlzdCAoQ2xvc2VkIFB1 YmxpYyBEaXNjdXNzaW9uKSIgPE9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPg0K VG86ICJPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRyIgPE9WQUwtREVWRUxPUEVS LUxJU1RATElTVFMuTUlUUkUuT1JHPg0KU3ViamVjdDogUmU6IFtPVkFMLURFVkVMT1BFUi1MSVNU XSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlzOiBTdW1tZXIgMjAxMiBhdCBNSVRS RSBpbiBCZWRmb3JkLCBNQQ0KDQogDQoNCkZyYW5rOw0KDQogDQoNCldlIGhvcGUgdG8gaGF2ZSB0 aGUgcmVnaXN0cmF0aW9uIHNpdGUgdXAgbmV4dCB3ZWVrLiAgVGhlIGV2ZW50IHdpbGwgYmUgZHVy aW5nIHRoZSB3ZWVrIG9mIEp1bHkgOSDigJMgc3RhcnRpbmcgTW9uZGF5IGF0IDEwOjAwIEFNIGFu ZCBlbmRpbmcgb24gRnJpZGF5IGF0IDEyOjAwLg0KDQogDQoNCk1lYW53aGlsZSwgd2UgYXJlIHdv cmtpbmcgb24gdGhlIGFnZW5kYSBhbmQgYXJlIGN1cnJlbnRseSBjb25zaWRlcmluZyB0aGlzIGxp c3Qgb2YgdG9waWNzOg0KDQogDQoNCkNDRQ0KDQpDUEUvU1dJRA0KDQpDRUUNCg0KWENDREYNCg0K T1ZBTA0KDQpBU1INCg0KRW50ZXJwcmlzZSBPQ0lMDQoNCkN5Yk9YL01BRUMNCg0KRmVkZXJhdGVk IENvbnRlbnQgUmVwb3NpdG9yeSBTcGVjDQoNCkVuZHBvaW50IFJlcG9ydGluZyBmb3IgQ29udGlu dW91cyBNb25pdG9yaW5nIGFuZCBDb21wbGlhbmNlIChFUkNDKQ0KDQpNSUxFDQoNClRBWElJDQoN CklGLU0gZm9yIFNDQVANCg0KSUYtTUFQDQoNClNDQVAgUmVsZWFzZXMNCg0KU0NBUCBhbmQgSUVU Rg0KDQpORVRDT05GIGFuZCBTQ0FQDQoNCiANCg0KU3RldmUNCg0KIA0KDQpGcm9tOiBGcmFuayBM aW5kc2F5IEFja2VyIFttYWlsdG86YWZyYW5rQE5PVkEuRURVXSANClNlbnQ6IFR1ZXNkYXksIE1h eSAwMSwgMjAxMiA5OjMyIEFNDQpUbzogb3ZhbC1kZXZlbG9wZXItbGlzdCBPVkFMIERldmVsb3Bl ciBMaXN0L0Nsb3NlZCBQdWJsaWMgRGlzY3Vzc2lvbg0KU3ViamVjdDogUmU6IFtPVkFMLURFVkVM T1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlzOiBTdW1tZXIgMjAx MiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQQ0KDQogDQoNClN0ZXZlLi4uLg0KDQpIYXMgdGhlcmUg YmVlbiBhbnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhpcyBldmVudD8NCg0K VGhhbmtzLA0KRnJhbmsgQWNrZXINCg0KDQogIF9fX19fICANCg0KDQpGcm9tOiBCb2N6ZW5vd3Nr aSwgU3RldmUgW3Nib2N6ZW5vQE1JVFJFLk9SR10NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAy MDEyIDE2OjM4DQpUbzogT1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkcNClN1Ympl Y3Q6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBE YXlzOiBTdW1tZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQQ0KDQpTYXZlIHRoZSBEYXRl OiB3ZWVrIG9mIEp1bHkgOSwgMjAxMg0KDQogDQoNClRoaXMgeWVhcuKAmXMgTUlUUkUtaG9zdGVk IFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXMgZXZlbnQgd2lsbCBiZSBoZWxkIGR1 cmluZyB0aGUgd2VlayBvZiBKdWx5IDksIDIwMTIgYXQgTUlUUkXigJlzIGZhY2lsaXR5IGluIEJl ZGZvcmQsIE1BLg0KDQogDQoNCkRldGFpbHMgdG8gZm9sbG93Lg0KDQogDQoNClJlZ2FyZHMsDQoN CiAgICBTdGV2ZQ0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KU3RlcGhlbiBQLiBCb2N6ZW5vd3NraQ0KDQogICAgICBUaGUgTUlUUkUgQ29y cG9yYXRpb24NCg0KICAgICAgT2ZmaWNlOiAoNzgxKSAyNzEtNzY4Mg0KDQogICAgICBDZWxsOiAo OTc4KSAzMDItMzg0OQ0KDQogICAgIHNib2N6ZW5vQG1pdHJlLm9yZw0KDQogDQoNClRvIHVuc3Vi c2NyaWJlLCBzZW5kIGFuIGVtYWlsIG1lc3NhZ2UgdG8gTElTVFNFUlZATElTVFMuTUlUUkUuT1JH IHdpdGggU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRoZSBtZXNz YWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIE9WQUwtREVWRUxPUEVSLUxJ U1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkcuIA0KDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBl bWFpbCBtZXNzYWdlIHRvIExJU1RTRVJWQExJU1RTLk1JVFJFLk9SRyB3aXRoIFNJR05PRkYgT1ZB TC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUgbWVzc2FnZS4gSWYgeW91IGhhdmUg ZGlmZmljdWx0aWVzLCB3cml0ZSB0byBPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMu TUlUUkUuT1JHLiANCg0KVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0byBM SVNUU0VSVkBMSVNUUy5NSVRSRS5PUkcgd2l0aCBTSUdOT0ZGIE9WQUwtREVWRUxPUEVSLUxJU1Qg aW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdSBoYXZlIGRpZmZpY3VsdGllcywgd3Jp dGUgdG8gT1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRy4gDQoNCiAN Cg0KICBfX19fXyAgDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnNhY20gbWFpbGluZyBsaXN0DQpzYWNtQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20NCg0K ------_=_NextPart_001_01CD3206.BA5284FC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQt VHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2Vu ZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48IS0t W2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1JVFJFO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBw bGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1MTUwNjk4NTA7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xMzEyNTQ3NTcyO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE3OTg5MTIy NDk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00NzU4OTA2NDg7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVs Ng0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZl LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5QZXJoYXBzIHlvdSBjYW4gaGF2ZSBhIG1lZXRpbmcgaW4gdGhlIGV2ZW5pbmcgb3Ig ZXh0ZW5kIHRoZSBzdGF5IHRvIEZyaWRheSB0byBnZXQgaW5wdXQuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPnYvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NaWtlIEtpbm5leTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q0lTU1AsIENF SCwgQ05EQTxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+STQxMSBTZWN1cml0eSBDb250 ZW50IEF1dG9tYXRpb24gT2ZmaWNlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Qcm9qZWN0IERpcmVjdG9yPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Db21wdXRlciBO ZXR3b3JrIERlZmVuc2UgUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgKENORCBSJmFtcDtUKSBPZmZp Y2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjk4MDAgU2F2YWdlIFJvYWQgU3RlIDY3Njc8YnI+RnQgTWVhZGUsIE1EIDIwNzU1LTY3 Njc8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGhvbmU6IDQxMC04NTQtNDQyMjxi cj5OU1RTOiA5NjgtODg4Njxicj5GYXggNDEwLTg1NC00NjgxPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48YSBocmVmPSJtYWlsdG86TS5raW5uZUByYWRpdW0ubmNzYy5taWwiPjxz cGFuIHN0eWxlPSdjb2xvcjojNjYwMDAwJz5tYWtpbm4yQG5zYS5nb3Y8L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4g V2FsdGVybWlyZSwgRGF2aWQgQS4gW21haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292XSA8 YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDE0LCAyMDEyIDM6MDQgUE08YnI+PGI+VG86PC9i PiBLaW5uZXksIE1pY2hhZWwgQTsgZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ7IEtlbnRfTGFuZGZp ZWxkQE1jQWZlZS5jb207IFNDQVAtREVWOyBzYWNtQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9i PiBSRTogW3NhY21dIFJlcXVlc3QgZm9yIHBhcnRpY2lwYW50cyAtIENvbnRlbnQgUmVwb3NpdG9y eSBTcGVjaWZpY2F0aW9uIERldmVsb3BtZW50PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NaWtlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBh bSB3b3JraW5nIHRvIGdldCBhIHNlc3Npb24gb24gdGhlIGFnZW5kYSBhdCBEZXYgRGF5cyB0byBk aXNjdXNzIHZhcmlvdXMgYXNwZWN0cyBvZiBjb250ZW50IHJlcG9zaXRvcnkgZnVuY3Rpb24uJm5i c3A7IEkgc2VlIHRoaXMgYXMgYW4gYXJlYSB0aGF0IGhhcyBicm9hZCBhcHBlYWwgdGhhdCBtaWdo dCBiZSBhIGdvb2QgY29uc2lkZXJhdGlvbiBmb3Igb25lIG9mIHRoZSBpbml0aWFsIHdvcmsgaXRl bXMgZm9yIFNBQ00uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNpbmNlcmVseSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGF2 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IEtpbm5leSwgTWljaGFlbCBBIFttYWlsdG86bS5raW5uZUByYWRpdW0ubmNz Yy5taWxdIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMTQsIDIwMTIgNzoxMCBBTTxicj48 Yj5Ubzo8L2I+IGRhdmlkLm9saXZhQHZlcml6b24ubmV0OyBLZW50X0xhbmRmaWVsZEBNY0FmZWUu Y29tOyBXYWx0ZXJtaXJlLCBEYXZpZCBBLjsgU0NBUC1ERVY7IHNhY21AaWV0Zi5vcmc8YnI+PGI+ U3ViamVjdDo8L2I+IFJFOiBbc2FjbV0gUmVxdWVzdCBmb3IgcGFydGljaXBhbnRzIC0gQ29udGVu dCBSZXBvc2l0b3J5IFNwZWNpZmljYXRpb24gRGV2ZWxvcG1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPktlbnQsIEkgcmUtcmVhZCB5 b3VyIGNvbW1lbnRzLCBhbmQgdW5kZXJzdGFuZCB5b3VyIHBvaW50cy4gR2xhZCBzb21lb25lIGlz IHNldHRpbmcgdXAgYW5vdGhlciBTQ0FQIHJlcG9zaXRvcnksIEkgd291bGQgbGlrZSB0byBiZSBp bmNsdWRlZCwgc28gd2lsbCB0aGlzIGJlIGRpc2N1c3NlZCBhdCBkZXZlbG9wZXIgZGF5cywgb3Ig U0FDTSwgb3Igd2lsbCBpcyBzb21lb25lIGdvaW5nIHRvIHNldHVwIGFub3RoZXIgd29ya2luZyBn cm91cD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SXQgd2lsbCBiZSBpbnRlcmVzdGluZyB0byBnZXQgZXZlcnlvbmUgdG8gY3Jl YXRlIGFuZCBzaGFyZSBjb250ZW50LCBhcmUgeW91IG9mZmVyaW5nIHVwIHNoYXJpbmcgb2YgTWNB ZmVlIGNvbnRlbnQ/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LU1pa2U8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86ZGF2aWQub2xpdmFAdmVy aXpvbi5uZXQiPmRhdmlkLm9saXZhQHZlcml6b24ubmV0PC9hPiA8YSBocmVmPSJtYWlsdG86W21h aWx0bzpkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldF0iPlttYWlsdG86ZGF2aWQub2xpdmFAdmVyaXpv bi5uZXRdPC9hPiA8YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXkgMTIsIDIwMTIgMzo0NiBQ TTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29t Ij5LZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPC9hPjsgS2lubmV5LCBNaWNoYWVsIEE7IDxhIGhy ZWY9Im1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Ij5kYXZpZC53YWx0ZXJtaXJlQG5p c3QuZ292PC9hPjsgPGEgaHJlZj0ibWFpbHRvOlNDQVAtREVWQG5pc3QuZ292Ij5TQ0FQLURFVkBu aXN0LmdvdjwvYT47IDxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3Jn PC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBSZXF1ZXN0IGZvciBwYXJ0aWNpcGFu dHMgLSBDb250ZW50IFJlcG9zaXRvcnkgU3BlY2lmaWNhdGlvbiBEZXZlbG9wbWVudDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5U byBhbGw6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5JIGFtIGludGVyZXN0ZWQgaW4g bG9jYXRpbmcgY29udGVudCBmb3IgU0NBUCAxLjIuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkluIHBhcnRpY3VsYXIs IGNvbnRlbnQgZm9yIHRoZSBzcGVjaWZpY2F0aW9ucyBhZGRlZCBhZnRlciAxLjAuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPkFyZSB5b3UgYWxsIHRhbGtpbmcgYWJvdXQgU0NBUCAxLjIgQ29udGVudD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPkRhdmlkIE9saXZhPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPk9uIDA1LzExLzEyLCA8YSBocmVmPSJtYWlsdG86S2VudF9M YW5kZmllbGRATWNBZmVlLmNvbSI+S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTwvYT4gd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk1pa2UgSSBs b3ZlIGl0IHdoZW4geW91IHRlZSBzb21ldGhpbmcgdXAgbGlrZSB0aGF04oCmLiA7LSkgJm5ic3A7 VGhhbmsgeW91LiA7KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn Pk1pa2Ugd3JvdGU6Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHN0 aWxsIHRoaW5rIHRoYXQgYW55IHNwZWNpZmljYXRpb24gZm9yIGEgcmVwb3NpdG9yeSBpcyB3aXNo ZnVsIHRoaW5raW5nIHVudGlsIHNvbWVvbmUgYnVpbGRzIG9uZSBhbmQgbGVhcm5zIHRoZSBsZXNz b25zIGl0IHdpbGwganVzdCBiZSBhbm90aGVyIHdoaXRlcGFwZXIgc3BlYy4gJm5ic3A7SSBiZWxp ZXZlIHRoZSBEb0QgbmVlZHMgdG8gaW5jb3Jwb3JhdGUgYSBtZXRhZGF0YSByZXBvc2l0b3J5IGFz IHBhcnQgb2YgaXQgYW5kIG90aGVyIGN1c3RvbWl6YXRpb25zIHRoYXQgbWF5IG5vdCBiZSB1c2Vm dWwgZm9yIGV2ZXJ5b25lLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgbmVl ZCB0byB0YWxrIG1vcmXigKY8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+SWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGEgaG9saXN0aWMsIGNvbXBsZXRlIGZl ZGVyYXRlZCBhcHByb2FjaCB0byBhIGNvbnRlbnQgcmVwb3NpdG9yeSwgSSBzb21lIHdoYXQgYWdy ZWUuICZuYnNwO0lmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBhbiBvcmdhbml6YXRpb25hbCByZXBv c2l0b3J5LCBJIHRvdGFsbHkgZGlzYWdyZWUuIEJ1dCB5b3Uga25ldyBJIHdvdWxkLiA7KTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+SGVyZSBpcyBob3cgSSBzZWUgdGhlIHByb2JsZW0uICZuYnNw O1RoZXJlIGlzIGFuIGltbWVkaWF0ZSBuZWVkIGZvciBTQ0FQIGFuZCBvdGhlciByZWxhdGVkIGNv bnRlbnQgdG8gYmUgc2VydmVkIHVwIGluc2lkZSBhbiBvcmdhbml6YXRpb24uICZuYnNwO1RvZGF5 IHdlIGhhdmUgc2l0dWF0aW9uIHdoZXJlIHRoZSBzdGFuZGFyZHMgYWxsb3cgdXMgdG8gcHJvdmlk ZSBzaXRlcyB0aGUgY2FwYWJpbGl0eSB0byBoYXZlIGEgc2luZ2xlIFNDQVAgaW1wbGVtZW50ZWQg cG9saWN5IHRoZXkgY2FsbCBvZmZpY2lhbCBmb3IgdGhlaXIgZW52aXJvbm1lbnQuIFllcyB0aGlz IGlzIGEgcmF0aGVyIHNpbXBsaXN0aWMgc2luY2UgdGhlcmUgYXJlIHRoaW5ncyBzdWNoIGFzIHRh cmdldGluZyBzcGVjaWZpYyBwbGF0Zm9ybXMsIHNwZWNpZmljIG9wZXJhdGlvbmFsIHVzZSBuZWVk cywgYnV0IGZvciBub3cgbGV0cyBhZ3JlZSBTQ0FQIGlzIGEgbWFzc2l2ZSBpbXByb3ZlbWVudCBv dmVyIHRoZSBwcm9wcmlldGFyeSBzaXR1YXRpb25zIG9mIHRoZSBwYXN0LiBXaGlsZSB3ZSBoYXZl IGNyZWF0ZWQgdGhpcyBzdGFuZGFyZCBjb250ZW50IHNvIHRoYXQgc2l0ZXMgY2FuIGltcGxlbWVu dCB0aGVpciBsb2NhbCBzaXRlIHNlY3VyaXR5IG9uY2UgYW5kIHRoZW4gYXNzdXJlIHRoZXkgYXJl IG1lYXN1cmluZyBhbGwgYXBwcm9wcmlhdGVseSB0YXJnZXRlZCBkZXZpY2VzIHRoZSBzYW1lIHdh eSwgd2UgaGF2ZSBmYWlsZWQgdG8gc3VwcG9ydCB0aGUgb3BlcmF0aW9uYWwgbmVlZHMgb2YgdGhl IHNpdGVzLiAmbmJzcDtXZSBoYXZlIGEgc2l0dWF0aW9uIHdoZXJlIG5vIHR3byB2ZW5kb3JzIGRp c3RyaWJ1dGUgY29udGVudCB0aGUgc2FtZSB3YXkuICZuYnNwO1RoaXMgY2F1c2VzIG1hc3NpdmUg cHJvYmxlbXMgZm9yIHRoZSBhZG1pbmlzdHJhdGlvbiBzdGFmZiB3aGVuIHRoZXkgbmVlZCB0byBp bmNvcnBvcmF0ZSBhIG5ldyBTQ0FQIGVuYWJsZWQgcHJvZHVjdCBpbnRvIHRoZWlyIGFyY2hpdGVj dHVyZS4gJm5ic3A7VGhleSBuZWVkIHRvIGRpc2NvdmVyIGhvdyB0aGUgbmV3IHByb2R1Y3Qgc3Vw cG9ydHMgZGlzdHJpYnV0aW5nIFNDQVAgY29udGVudCB0byBpdCdzIHZhcmlvdXMgY29tcG9uZW50 cy4gJm5ic3A7SWYgdGhleSBoYXZlIG9uZSBwcm9kdWN0IHRoZW4gdGhleSBkbyB0aGlzIG9uZSBh bmQgdGhleSBhcmUgZG9uZS4gJm5ic3A7SWYgdGhleSBoYXZlIG11bHRpcGxlIHByb2R1Y3RzIHRo ZXkgd2lsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgaG93IHRvIG1pbmltaXplIHRoZSBpbXBhY3QgYnkg aW5jb3Jwb3JhdGluZyB0aGUgdXBkYXRlIHByb2Nlc3MgZm9yIHRoZSBuZXcgcHJvZHVjdCBpbnRv IHRoZSBleGlzdGluZyBTQ0FQIHNlY3VyaXR5IGNvbnRlbnQgcHJvY2Vzc2VzLiBOb3cgd2hlbiB0 aGUgaW5ldml0YWJsZSBoYXBwZW5zIGFuZCB0aGUgc2l0ZSBzdGFmZiBuZWVkcyB0byBtYWtlIGEg Y2hhbmdlIHRvIHRoZWlyIHNlY3VyaXR5IHBvbGljeSwgdGhleSBoYXZlIHRvIG1ha2UgdGhlIG1v ZGlmaWNhdGlvbnMgdG8gdGhlIGJlbmNobWFyayBvciBjaGVja3Mgb3IgYm90aCBhbmQgdGhlbiBk aXN0cmlidXRlIHRob3NlIHVwZGF0ZXMgYWNyb3NzIHRoZWlyIG5ldHdvcmsuICZuYnNwO0ZvciBl YWNoIFNDQVAgZW5hYmxlZCBwcm9kdWN0IHRoZXkgaGF2ZSBpbiBwbGFjZSwgdGhleSBoYXZlIGRv dWJsZWQsIHRyaXBsZWQgb3IgbW9yZSB0aGUgd29yayBuZWVkZWQgdG8gbWFrZSB0aG9zZSB1cGRh dGVzIGF2YWlsYWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoZXJlIGlzIGFu b3RoZXIgY29udGVudCByZXBvc2l0b3J5IHByb2JsZW0gYW5kIHRoYXQgaXMgdGhlIEZlZGVyYXRl ZCBDb250ZW50IERpc3RyaWJ1dGlvbi4gJm5ic3A7SWYgeW91IHRoaW5rIGdsb2JhbCBETlMgeW91 IGhhdmUgYSBnZW5lcmFsIGZyYW1lIG9mIHJlZmVyZW5jZS4gJm5ic3A7VGhlIGd1aWRhbmNlIGF1 dGhvcnMgbmVlZCB0byBiZSBhYmxlIHRvIHB1Ymxpc2ggY29udGVudCBpbiBhbiBhdXRob3JpdGF0 aXZlIG1hbm5lciBzbyB0aGVpciBjb250ZW50IGlzIHVwZGF0ZWQgaW4gYSB0aW1lbHkgZmFzaGlv bi4gJm5ic3A7VGhpcyBpcyBhIG11Y2ggaGFyZGVyIHByb2JsZW0gdG8gc29sdmUgaWYgdGhlcmUg aXMgbm8gbG9jYWwgb3JnYW5pemF0aW9uYWwgaW5mcmFzdHJ1Y3R1cmUgdG8gc3VwcG9ydCBpdC4g Oyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlNvIGhlcmUgaXMgd2hhdCBJIGFtIHRoaW5raW5n 4oCmICZuYnNwO1dlIHNob3VsZCBjb25zaWRlciBhZGRyZXNzaW5nIHRoZXNlIGFzIHR3byBzZXBh cmF0ZSBidXQgaW50ZWdyYXRlZCBlZmZvcnRzLiAmbmJzcDtJIGJlbGlldmUgdGhlIE9yZ2FuaXph dGlvbmFsIENvbnRlbnQgUmVwb3NpdG9yeSBpcyB0aGUgbW9yZSBjcml0aWNhbCBwaWVjZSB0aGF0 IGlzIGFjdHVhbGx5IGVhc2llciB0byBhZGRyZXNzLiAmbmJzcDtUaGUgRmVkZXJhdGVkIENvbnRl bnQgRGlzdHJpYnV0aW9uIHNob3VsZCBiZSBhIHN1YnNlcXVlbnQgZWZmb3J0IGludGVncmF0aW5n IC8gYXVnbWVudGluZyB0aGUgT3JnYW5pemF0aW9uYWwgcmVwb3NpdG9yeSBzcGVjaWZpY2F0aW9u LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+TWlrZSwgdG8geW91ciBwb2ludCB0aGF0 IHdlIG5lZWQgc29tZW9uZSB0byBidWlsZCBvbmUgZmlyc3TigKYgVGhhdCBoYXMgaGFwcGVuZWQg YWxyZWFkeS4gJm5ic3A7SSBoYXZlIG9uZSBhcyBkbyBvdGhlciB2ZW5kb3JzIGJ1dCB3aGF0IHdl IGRvbuKAmXQgaGF2ZSBpcyB0aGUgYWNjZXNzIHNwZWNpZmljYXRpb24uICZuYnNwO091cnMgYXJl IGZvY3VzZWQgb24gb3VyIHNwZWNpZmljIHByb2R1Y3QgbmVlZHMuICZuYnNwO0FkZGl0aW9uYWxs eSB0aGVyZSBpcyBhIGNvbXBhbnkgdGhhdCBoYXMgZGV2ZWxvcGVkIGEgY29tbWVyY2lhbCBTQ0FQ IGNvbnRlbnQgcmVwb3NpdG9yeSB0aGF0IHdpbGwgYmUgYW5ub3VuY2VkIGxhdGVyIHRoaXMgbW9u dGguIEkgd29uJ3Qgc3RlYWwgdGhlaXIgdGh1bmRlciBidXQgSSB3YXMgcmVjZW50bHkgZ2l2ZW4g YSBzbmVhayBwZWVrIGF0IGl0IGFuZCBJIG11c3QgYWRtaXQgSSB3YXMgdmVyeSBpbXByZXNzZWQu ICZuYnNwO0FnYWluLCB0byB5b3VyIHBvaW50LCBpdCBoYXMgYmVlbiBkb25lLiBXaGF0IGlzIG5l ZWRlZCB0byBhZGRyZXNzIHRoZSBpbml0aWFsIG9wZXJhdGlvbmFsIHByb2JsZW0gaXMgdG8gZGV2 ZWxvcCBhIHNwZWNpZmljYXRpb24gdGhhdCBwcm92aWRlcyBhIGNvbnNpc3RlbnQgbWVhbnMgZm9y IGFsbCBTQ0FQIHByb2R1Y3RzIHRvIHJldHJpZXZlIHRoZSBhcHByb3ByaWF0ZSBjb250ZW50IGFz IGNvbmZpZ3VyZWQgYW5kIG1hbmFnZWQgYnV0IHRoZSBzaXRlLiAmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPlRPIFRIQVQgRU5E4oCmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+SSBh bSByZXF1ZXN0aW5nIHBhcnRpY2lwYXRpb24gZnJvbSB0aG9zZSBpbiB0aGUgY29tbXVuaXR5IHRo YXQgc2VlIHRoZSBuZWVkIGFuZCB3YW50IHRvIHB1dCBpbiB0aGUgd29yayB0byBtYWtlIHRoaXMg c3BlY2lmaWNhdGlvbiBoYXBwZW4uICZuYnNwO0kgaGF2ZSB0YWxrZWQgdG8gYSBjb3VwbGUgb2Yg eW91IGJ1dCBJIGRvIG5vdCB3YW50IHRvIGFzc3VtZSB5b3VyIHBhcnRpY2lwYXRpb24uICZuYnNw O0lmIHlvdSBhcmUgaW50ZXJlc3RlZCBwbGVhc2UgY29udGFjdCBtZSBzbyB3ZSBjYW4gZ2V0IHRo aXMgc3RhcnRlZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoYW5rcyE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPktlbnQgTGFuZGZpZWxkPC9zcGFu Pjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxl LXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJlIGFuZCBTdGFuZGFy ZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwvc3Bhbj48L3N0cm9uZz48 YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41MDAwIEhlYWRxdWFydGVycyBEci48L3Nw YW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+UGxhbm8sIFRleGFzIDc1MDI0PC9z cGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3Q6ICsxLjk3Mi45 NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5Nb2Jp bGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8L3NwYW4+PC9zdHJvbmc+PHNw YW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3Lm1jYWZlZS5jb20v IiB0YXJnZXQ9Il9ibGFuayI+d3d3Lm1jYWZlZS5jb208L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp bic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jmx0O0tpbm5leSZndDssIE1pY2hhZWwgQSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm0ua2lubmVAcmFkaXVtLm5jc2MubWlsIiB0YXJnZXQ9Il9ibGFuayI+ bS5raW5uZUByYWRpdW0ubmNzYy5taWw8L2E+Jmd0Ozxicj48Yj5UbzogPC9iPkRhdmlkIFdhbHRl cm1pcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292IiB0YXJn ZXQ9Il9ibGFuayI+ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjwvYT4mZ3Q7LCBTQ0FQLURFViAm bHQ7PGEgaHJlZj0ibWFpbHRvOlNDQVAtREVWQG5pc3QuZ292IiB0YXJnZXQ9Il9ibGFuayI+U0NB UC1ERVZAbmlzdC5nb3Y8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zYWNtQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNhY21AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWNtQGlldGYub3JnPC9hPiZn dDs8YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbc2FjbV0gW09WQUwtREVWRUxPUEVSLUxJU1RdIFNl Y3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1JVFJFIGlu IEJlZGZvcmQsIE1BPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43 NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 JyBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkRhdmUsPC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JIGhhdmUgbm8gcHJv YmxlbSB3aXRoIHdlYmluYXJzLCBJIGRvIHdhbnQgdG8ga2VlcCBkZXZlbG9wZXIgZGF5cyBhY3Rp b25hYmxlIGFuZCB1c2UgaXQgdG8gbWFrZSBkZWNpc2lvbnMsIGFuZCB2b3RlIGFuZCBhY2NvbXBs aXNoIHRoaW5ncyBnb29kIG9yIGJhZC4mbmJzcDsgSSBkbyBub3Qgd2FudCB0aGlzIHRvIGJlIGFu IGluZm9ybWF0aW9uYWwgYnJpZWZpbmcgY29uZmVyZW5jZS48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyBmb3IgdGhlIGxpbmtzLjwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JIHN0aWxsIHRoaW5rIHRoYXQgYW55IHNw ZWNpZmljYXRpb24gZm9yIGEgcmVwb3NpdG9yeSBpcyB3aXNoZnVsIHRoaW5raW5nIHVudGlsIHNv bWVvbmUgYnVpbGRzIG9uZSBhbmQgbGVhcm5zIHRoZSBsZXNzb25zIGl0IHdpbGwganVzdCBiZSBh bm90aGVyIHdoaXRlcGFwZXIgc3BlYy4gJm5ic3A7SSBiZWxpZXZlIHRoZSBEb0QgbmVlZHMgdG8g aW5jb3Jwb3JhdGUgYSBtZXRhZGF0YSByZXBvc2l0b3J5IGFzIHBhcnQgb2YgaXQgYW5kIG90aGVy IGN1c3RvbWl6YXRpb25zIHRoYXQgbWF5IG5vdCBiZSB1c2VmdWwgZm9yIGV2ZXJ5b25lLjwvc3Bh bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2UgbmVlZCB0byB0YWxr IG1vcmXigKY8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+LU1pa2Um bmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gV2Fs dGVybWlyZSwgRGF2aWQgQS4gWzxhIGhyZWY9Im1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3Qu Z292IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8L2E+ XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAwOCwgMjAxMiAxMDo0NCBBTTxicj48Yj5U bzo8L2I+IEtpbm5leSwgTWljaGFlbCBBOyBTQ0FQLURFVjsgPGEgaHJlZj0ibWFpbHRvOnNhY21A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWNtQGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0 OjwvYj4gUkU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVs b3BlciBEYXlzOiBTdW1tZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQTwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+TWlrZSw8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ V2hhdCBhYm91dCBoYXZpbmcgd2ViaW5hcnMgaW4tcGxhY2Ugb2YgdGhlIDMwIG1pbnV0ZSBicmll ZnM/PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZGluZyBj b250ZW50IG1hbmFnZW1lbnQsIHdlIGFyZSBidWlsZGluZyB0aGUgcHJvdG90eXBlIGNvbnRlbnQg cmVwb3NpdG9yeSBmb3IgdXNlIGluIGEgcHJvZHVjdGlvbiBlbnZpcm9ubWVudC4mbmJzcDsgQXMg YW4gb3BlbiBzb3VyY2UgcHJvamVjdCwgaXQgd2lsbCBiZSBmcmVlIGZvciB1c2UgYnkgYW55b25l IGludGVyZXN0ZWQuJm5ic3A7IE15IHRoaW5raW5nIGlzIHRoYXQgdGhpcyBwcm9qZWN0IGNhbiBi cmlkZ2UgdGhlIGdhcCB1bnRpbCBjb21tZXJjaWFsIHNvbHV0aW9ucyBhcmUgYXZhaWxhYmxlIHRv IGF1Z21lbnQgaXQuJm5ic3A7IFRoaXMgaXMgYSBzaW1pbGFyIHBhdGggdGhhdCB3YXMgZm9sbG93 ZWQgd2l0aCBETlMgKGJpbmQpIGFuZCBIVFRQIChhcGFjaGUpLiZuYnNwOyBXaGVuIGl0IGlzIHJl YWR5IGZvciB1c2UsIEkgYW0gaG9waW5nIHRvIHVzZSBpdCB0byBob3N0IFVTR0NCIGNvbnRlbnQu Jm5ic3A7IFlvdSB3b3VsZCBiZSB3ZWxjb21lIHRvIHVzZSBpdCBmb3IgeW91ciBuZWVkcy48L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SXQgaXMgZ29vZCB0aGF0IE9D SUwgaXMgbW92aW5nIGZvcndhcmQuJm5ic3A7IFRoaXMgaXMgYW4gaW1wb3J0YW50IHBpZWNlIG9m IHN1cHBvcnRpbmcgcmlzayBtYW5hZ2VtZW50IGFuZCBhc3BlY3RzIG9mIGNvbnRpbnVvdXMgbW9u aXRvcmluZy4mbmJzcDsgSSB3b3VsZCBhbHNvIGxpa2UgdG8gc2VlIHNvbWUgZGlzY3Vzc2lvbiBv biBPQ0lMIGF0IERldmVsb3BlciBEYXlzLiZuYnNwOyBXaXRoIHRoZSBwcm9wb3NhbHMgd2Ugd2ls bCBsaWtlbHkgaGF2ZSBhIHNlbnNlIG9mIHdoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGFuZCB3 aGF0IHdlIGNhbiBhY2hpZXZlIGNvbnNlbnN1cyBvbiBvdXRzaWRlIHRoZSBtZWV0aW5nLjwvc3Bh bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5SZW1lZGlhdGlvbiBpcyBhIHRv cGljIG5lYXIgYW5kIGRlYXIgdG8gbXkgaGVhcnQuJm5ic3A7IEkgdG9vIHdvdWxkIGxpa2UgdG8g c2VlIGl0IG1vdmUgZm9yd2FyZC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+V2UganVzdCBwdWJsaXNoZWQgdGhlIGRyYWZ0IEFTUiBzcGVjaWZpY2F0aW9uIGZvciBw dWJsaWMgY29tbWVudC4mbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIHN1cHBvcnRzIGVudGVycHJp c2UgYWdncmVnYXRlIHJlcG9ydGluZyB3aGljaCBncmVhdGx5IHJlZHVjZXMgdGhlIGRhdGEgdm9s dW1lcyBuZWVkZWQgdmVyc2VzIGRldGFpbGVkIGhvc3QtYmFzZWQgcmVwb3J0cy4gVGhpcyBzcGVj aWZpY2F0aW9uIGhhcyBiZWVuIGRlc2lnbmVkIGFzIGEgbW9yZSByb2J1c3QgcmVwbGFjZW1lbnQg Zm9yIExBU1IuJm5ic3A7IEl0IGNhbiBiZSB1c2VkIGluIGNvbnRpbnVvdXMgbW9uaXRvcmluZyBh cHBsaWNhdGlvbnMgdG8gc3VwcG9ydCBhZ2dyZWdhdGUgZGF0YSByZXBvcnRpbmcgbmVlZHMgKGUu Zy4gRklTTUEgcmVwb3J0aW5nLCAmbmJzcDtDeWJlclNjb3BlKS48L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SGVyZSBhcmUgdGhlIGxpbmtzOjwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vY3NyYy5uaXN0Lmdv di9wdWJsaWNhdGlvbnMvUHVic0RyYWZ0cy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2Nz cmMubmlzdC5nb3YvcHVibGljYXRpb25zL1B1YnNEcmFmdHMuaHRtbDwvYT48L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9jc3JjLm5p c3QuZ292L3B1YmxpY2F0aW9ucy9QdWJzTklTVElScy5odG1sI05JU1QtSVItNzg0OCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9QdWJzTklTVElScy5o dG1sI05JU1QtSVItNzg0ODwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+VGhlIHByaW1hcnkgcmVhc29uIHdlIGhhdmUgc3VnZ2VzdGVkIHdhaXRpbmcgb24gWEND REYgaXMgbm90IHRoZSBpbnRlcm5hdGlvbmFsaXphdGlvbiBpc3N1ZS4gTWFueSB2ZW5kb3JzIGhh dmUgY29tbWVudGVkIHRoYXQgdGhleSBhcmUgc3RpbGwgd29ya2luZyBvbiBpbXBsZW1lbnRpbmcg dGhlIFhDQ0RGIDEuMi4xIHNwZWNpZmljYXRpb24uIFdlIHdpbGwgYmUgaW4gYSBiZXR0ZXIgcGxh Y2UgaW4gYSBmZXcgbW9udGhzIG9uY2UgbW9yZSBkZXZlbG9wbWVudCBhcm91bmQgWENDREYgaGFz IG9jY3VycmVkLiZuYnNwOyBBcyB3ZSBjb25zaWRlciBjaGFuZ2VzIHRvIHRoZSBTQ0FQIHN0YWNr IHRvIGFkZHJlc3MgT0NJTCBhbmQgb3RoZXIgaXNzdWVzLCB3ZSB3aWxsIGlkZW50aWZ5IGFyZWFz IHRoYXQgbmVlZCBpbXByb3ZlbWVudCBpbiBYQ0NERi4mbmJzcDsgVGhlc2UgYXJlIGdvb2QgYW5k IG5lY2Vzc2FyeSBkaXNjdXNzaW9ucyB0byBoYXZlIG5vdywgYnV0IHdlIGhhdmUgYSBnb29kIGRl YWwgb2Ygd29yayB0byBkbyBiZWZvcmUgd2UgYXJlIHJlYWR5IHRvIG9wZW4gdXAgWENDREYuJm5i c3A7IE15IHN1Z2dlc3Rpb24gaXMgdG8gd29yayBvbiB0aGVzZSByZWxhdGVkIGFyZWFzIGFuZCB0 aGVuIHdvcmsgdXAgY2hhbmdlIHByb3Bvc2FscyBmb3IgWENDREYgYXMgbmVlZGVkLiZuYnNwOyBC eSB0aGF0IHRpbWUgd2Ugc2hvdWxkIGJlIHJlYWR5IHRvIHdvcmsgb24gYSBuZXcgcmV2aXNpb24g b2YgWENDREYuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgYW0g YWxzbyBsb29raW5nIGZvcndhcmQgdG8gdGhlIGRpc2N1c3Npb25zIGF0IHRoZSBjb25mZXJlbmNl LiZuYnNwOyBJdCBoYXMgYmVlbiB0b28gbG9uZy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5TaW5jZXJlbHksPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5EYXZlPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz4gS2lubmV5LCBNaWNoYWVsIEEgWzxhIGhyZWY9Im1haWx0bzpt Lmtpbm5lQHJhZGl1bS5uY3NjLm1pbCIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptLmtpbm5lQHJh ZGl1bS5uY3NjLm1pbDwvYT5dIDxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDA4LCAyMDEy IDc6MDkgQU08YnI+PGI+VG86PC9iPiBTQ0FQLURFVjxicj48Yj5DYzo8L2I+IFdhbHRlcm1pcmUs IERhdmlkIEEuPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW09WQUwtREVWRUxPUEVSLUxJU1RdIFNl Y3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1JVFJFIGlu IEJlZGZvcmQsIE1BPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5LZW50LDwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JdOKAmXMgZ29vZCB0byByZWFkIHlvdXIgdGhvdWdodHMs IGFuZCBhIHJlYWxpc3RpYyBhY3Rpb25hYmxlIGFwcHJvYWNoIGlzIGluZGVlZCBuZWVkZWQuICZu YnNwO1NpbmNlIGFsbCB0aGUgYWN0aXZpdHkgaGFzbuKAmXQgYmVlbiBvbiB0aGUgbGlzdHMgYSBi cmllZiAxxb0yIGhvdXIgcmVjYXAgbWF5IGJlIGluIG9yZGVyIHRvIGJyaW5nIGV2ZXJ5b25lIHVw IHRvIHNwZWVkIHNpbmNlIHRoZXJlIGhhcyBiZWVuIGEgbG90IG9mIGFjdGl2aXR5IG9uIENQRS9T V0lELCBPQ0lsLCBNQUVDL0N5Yk9YIENFRSBhbmQgb3RoZXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5XZSBjb3VsZCB3cml0ZSBhIGNvbnRlbnQgcmVwb3NpdG9y eSBzcGVjaWZpY2F0aW9uLCBidXQgd2l0aG91dCBzb21lb25lIHdpbGxpbmcgdG8gc3RhbmQgb25l IHVwIGl0IHdpbGwgYmUgYXMgdmFsdWFibGUgYXMgdGhlIENDU1Mgc3BlY2lmaWNhdGlvbiBpcyB0 b2RheS4gJm5ic3A7SeKAmXZlIGJlZW4gdHJ5aW5nIGZvciB0d28geWVhcnMgdG8gZ2V0IG15IG1h bmFnZW1lbnQgdG8gZ2V0IGEgY29vcmRpbmF0ZWQgZWZmb3J0IHRvZ2V0aGVyIGZvciB0aGUgRG9E IHRvIHN0YW5kIHVwIGEgcmVwb3NpdG9yeSwgaXQgaXMgYSB0b3VnaCBwcm9ibGVtIGFuZCB3aWxs IHJlcXVpcmUgZnVuZGluZyB3aXRoIGEgdGFpbCwgSeKAmW0gbm90IHN1cmUgYSBzcGVjaWZpY2F0 aW9uIHdpbGwgc29sdmUgdGhhdCBwcm9ibGVtLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz5XZSAoRG9EKSBoYXZlIGJlZW4gcHV0dGluZyBhIGxvdCBvZiBlZmZvcnQg aW50byBPQ0lMIG92ZXIgdGhlIGxhc3QgeWVhciB0cnlpbmcgdG8gbWFrZSBpdCB1c2VmdWwgaW4g YW4gZW50ZXJwcmlzZSBlbnZpcm9ubWVudCBhbmQgd2lsbCBiZSBwb3N0aW5nIG91ciBpZGVhcyB0 byB0aGUgbGlzdCBiZWZvcmUgZGV2ZWxvcGVyIGRheXMgaXQgc2hvdWxkIGhhdmUgYWxyZWFkeSBz dGFydGVkLCB3ZSBuZWVkIHRvIGdldCBjb25zZW5zdXMgYW5kIGEgdm90ZSBvbiBob3cgdGhlIGNv bW11bml0eSB3aXNoZXMgdG8gcHJvY2VlZC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+UmVtZWRpYXRpb24gaXMgc3RhbGxlZCBidXQgSeKAmW0gbWFraW5nIGV2ZXJ5 IGVmZm9ydCB0byBnZXQgaXQga2ljayBzdGFydGVkIGZyb20gb3VyIHBlcnNwZWN0aXZlLiBJIGhv cGUgdG8gYXNzaXN0IGluIGdldHRpbmcgdGhlIGRyYWZ0IEVSSSBmaW5pc2hlZCB0aGlzIHllYXIu ICZuYnNwO1dlIGFyZSB3cml0aW5nIHNvbWUgbmV3IFNUSUcgY29udGVudCBhbmQgaW50ZW5kIHRv IHVzZWQgdGhlIGRyYWZ0IENSRSBzcGVjaWZpY2F0aW9uIHRvIGluc2VydCBDUkUgaW50byB0aGUg Y29udGVudCBzbyB3ZSAoRG9EKSBjYW4gZG8gc29tZSBhdXRvbWF0aWMgY29uZmlndXJhdGlvbiBm aXhlcywgcGFydCBvZiBhIHNlbGYgaGVhbGluZyBuZXR3b3JrIGNvbmNlcHQuIEl0IGlzIGp1c3Qg YSBzdGFydCBidXQgdGhlIGJlc3Qgd2UgY2FuIGRvIGF0IHRoaXMgcG9pbnQuPC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkVudGVycHJpc2UgcmVwb3J0aW5nIGlzIGFu IGludGVyZXN0aW5nIHN1YmplY3QsIHNpbmNlIFhNTCBhZGRzIHNpemUgdG8gYW5kIGNvbnRlbnQg dG8gcm9sbCB1cCByZXBvcnRpbmcsIGluIGFueSBlbnRlcnByaXNlIG9mIHNpemUgdGhlIHByb2Js ZW0gZ2V0cyBncmVhdGVyLCBJIGxvb2sgZm9yd2FyZCB0byB5b3VyIHRob3VnaHRzIG9uIHRoYXQg c3ViamVjdC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSBhbSBj b25jZXJuZWQgdGhhdCB0aGUgaW50ZXJuYXRpb25hbGl6YXRpb24gZWZmb3J0cyBhcmUgZGV0cmFj dGluZyBmcm9tIGVmZm9ydHMgdG8gbWVldCB1c2UgY2FzZXMsIHdlIGhhdmUgc29tZSB0aGluZ3Mg d2Ugd291bGQgbGlrZSBjaGFuZ2VkIGluIFhDQ0RGIHRvIHN1cHBvcnQgb3VyIE9DSWwgdXNlIGNh c2UgYW5kIEkgaGF2ZSBiZWVuIHRvbGQgdGhhdCBJIG5lZWQgdG8gd2FpdC4gSSBkaWRu4oCZdCB0 aGluayB0aGF0IGEgbW92ZSB0byBpbnRlcm5hdGlvbmFsaXphdGlvbiBzaG91bGQgaW1wZWRlIGVm Zm9ydHMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdXNlIGNhc2VzLjwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5JIGxvb2sgZm9yd2FyZCB0byB0YWxraW5nIHdpdGggeW91 IGF0IHRoZSBjb25mZXJlbmNlLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPnYv cjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TWlrZSBLaW5uZXk8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UHJvamVjdCBEaXJlY3Rvcjwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Db21wdXRlciBOZXR3b3JrIERlZmVuc2UgUmVzZWFyY2gg YW5kIFRlY2hub2xvZ3kgKENORCBSJmFtcDtUKSBPZmZpY2U8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+OTgwMCBTYXZhZ2UgUm9hZCBTdGUgNjc2Nzxicj5GdCBNZWFkZSwg TUQgMjA3NTUtNjc2Nzxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6IzFGNDk3RCc+UGhvbmU6IDQxMC04NTQtNDQyMjxicj5OU1RTOiA5NjgtODg4Njxicj5GYXgg NDEwLTg1NC00NjgxPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhy ZWY9Im1haWx0bzpNLmtpbm5lQHJhZGl1bS5uY3NjLm1pbCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSdjb2xvcjojNjYwMDAwJz5tYWtpbm4yQG5zYS5nb3Y8L3NwYW4+PC9hPjwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpzY2FwLWRldkBu aXN0LmdvdiIgdGFyZ2V0PSJfYmxhbmsiPnNjYXAtZGV2QG5pc3QuZ292PC9hPiA8YSBocmVmPSJt YWlsdG86W21haWx0bzpzY2FwLWRldkBuaXN0Lmdvdl0iIHRhcmdldD0iX2JsYW5rIj5bbWFpbHRv OnNjYXAtZGV2QG5pc3QuZ292XTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5XYWx0ZXJtaXJlLCBE YXZpZCBBLjxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMDcsIDIwMTIgNzowOSBQTTxicj48 Yj5Ubzo8L2I+IE11bHRpcGxlIHJlY2lwaWVudHMgb2YgbGlzdDxicj48Yj5TdWJqZWN0OjwvYj4g UkU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBE YXlzOiBTdW1tZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQTwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+S2VudCw8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSBsaWtl IHdoYXQgeW91IGFyZSBzYXlpbmcgaGVyZS4mbmJzcDsgV2UgYXJlIGFsc28gaW4gc3VwcG9ydCBv ZiB0aGlzIHR5cGUgb2YgYXBwcm9hY2guJm5ic3A7IFdlIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUg Y29tbXVuaXR5IGRpc2N1c3Npb24gYXJvdW5kIHdoYXQgYXJlIHRoZSBrZXkgYXJlYXMvcHJpb3Jp dGllcyB0aGF0IHRoZSBjb21tdW5pdHkgd291bGQgbGlrZSB0byBzZWUgZGlzY3Vzc2VkIGF0IERl diBEYXlzLiZuYnNwOyBZb3VyIHRvcGljcyBiZWxvdyBsb29rIGxpa2UgYSBnb29kIHN0YXJ0LiBU aGUgU0FDTSBsaXN0IG1pZ2h0IGJlIGEgYmV0dGVyIHZlbnVlIHRoYW4gdGhlIE9WQUwgbGlzdCBm b3IgdGhpcyBkaXNjdXNzaW9uLiZuYnNwOyBGb3IgZWFjaCBhcmVhIHdlIHNob3VsZCBmb2N1cyB0 aGUgZGlzY3Vzc2lvbiBhcm91bmQgZGV2ZWxvcGluZyBvYmplY3RpdmVzIGZvciBlYWNoIHNlc3Np b24uJm5ic3A7IFRoZSBzZXNzaW9ucyBjYW4gYmUgdGltZSBib3hlZCBiYXNlZCBvbiB3aGF0IHdv dWxkIGJlIGEgcmVhc29uYWJsZSBhbW91bnQgb2YgdGltZSB0byBhY2NvbXBsaXNoIGVhY2ggb2Jq ZWN0aXZlLiZuYnNwOyBGb3IgZXhhbXBsZSBpZiBjb250aW51b3VzIG1vbml0b3JpbmcgaXMgYSBw cmlvcml0eSBhbmQgY29sbGVjdGl2ZWx5IGl0IHRha2VzIDMgZGF5cyB0byB3b3JrIHRocm91Z2gg YWxsIHRoZSBvYmplY3RpdmVzLCBJIHNlZSBubyBwcm9ibGVtIHdpdGggdGhhdC4mbmJzcDsgV2Ug Y2FuIGFsc28ga2VlcCBhIGZldyBzZXNzaW9ucyDigJxvbiBkZWNr4oCdIGlmIGFsbCB0aGUgb2Jq ZWN0aXZlcyBhcmUgcmVhY2hlZCBhbmQgd2UgY29tcGxldGUgYWxsIHRoZSBzY2hlZHVsZWQgc2Vz c2lvbnMgZWFybHkuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRo b3VnaHRzPzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlNp bmNlcmVseSw8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkRhdmlkIFdhbHRlcm1pcmU8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlNDQVAgQXJjaGl0ZWN0PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5OYXRpb25hbCBJbnN0aXR1dGUgb2YgU3Rh bmRhcmRzIGFuZCBUZWNobm9sb2d5PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz4oMzAxKSA5NzUtMzM5MDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292IiB0 YXJnZXQ9Il9ibGFuayI+ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PjxhIGhyZWY9Im1haWx0bzpzY2FwLWRldkBuaXN0LmdvdiIgdGFyZ2V0PSJfYmxhbmsiPnNjYXAt ZGV2QG5pc3QuZ292PC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpzY2FwLWRldkBuaXN0Lmdv dl0iIHRhcmdldD0iX2JsYW5rIj5bbWFpbHRvOnNjYXAtZGV2QG5pc3QuZ292XTwvYT4gPGI+T24g QmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86S2VudF9MYW5kZmllbGRAbWNhZmVlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPktlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb208L2E+PGJyPjxiPlNlbnQ6 PC9iPiBNb25kYXksIE1heSAwNywgMjAxMiA0OjI1IFBNPGJyPjxiPlRvOjwvYj4gU0NBUC1ERVY8 YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2VjdXJpdHkgQXV0 b21hdGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwg TUE8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkFsbCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+SSB3b3VsZCBsaWtlIHRvIGRp c2N1c3MgdGhlIGZvcm1hdCBmb3IgdGhlIFNDQVAgRGV2ZWxvcGVyIERheXMgdGhhdCBzZWVtcyB0 byBiZSBsaXN0ZWQgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPkkgc2VlIHRoaXMgYXBwZWFycyB0byBmb2xsb3cgYSBwYXRoIHdlIGhhdmUg ZGlzY3Vzc2VkIGluIHRoZSBwYXN0IGFzIHRoZSB3YXkgbm90IHRvIGhvbGQgYSBEZXYgRGF5cyBl dmVudC4gJm5ic3A7V2UgaGF2ZSBiZWVuIHRyeWluZyB0byBnZXQgYXdheSBmcm9tICdEZWF0aCBi eSBQb3dlcnBvaW50JyBhbmQgYmFjayB0byB0aGUgdHlwZSBvZiBldmVudCB3ZSBoZWxkIHllYXJz IGFnbyB3aGVuIHdlIHdlcmUgaGlnaGx5IHByb2R1Y3RpdmUuICZuYnNwO0luIHRoZSBwYXN0IHdl IGhhZCBhIHRvcGljIHRvIGJlIGRpc2N1c3NlZCBhbmQgYSB0aW1lIGJveCB0byB3b3JrIHdpdGhp bi4gJm5ic3A7VGhhdCBhbGxvd2VkIHVzIHRvIGhhdmUgdmVyeSBhY3RpdmUgYnJhaW5zdG9ybWlu ZyBzZXNzaW9ucyBpbiBhIGhpZ2ggYmFuZHdpZHRoIGVudmlyb25tZW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5BdCBwYXN0IFN1bW1lciBldmVu dHMgd2UgaGF2ZSBnb3QgaW50byBhIHBhdHRlcm4gb2YgbG90cyBvZiBwb3dlcnBvaW50LCBsb3Rz IG9mIHN0YXR1cyBvZiB0aGUgZWZmb3J0cyBhbmQgdmVyeSBsaXR0bGUgZGlzY3Vzc2lvbiBhYm91 dCB0aGluZ3MgdGhhdCBuZWVkIGFjdGl2ZSBkaXNjdXNzaW9ucy4gJm5ic3A7V2UgbmVlZCB0byBr ZWVwIG1vdmluZyBmb3J3YXJkIGFuZCBtYWtpbmcgcHJvZ3Jlc3MgYXMgYW4gZWZmb3J0LiBXZSBj YW4gZ2V0IHN0YXR1cyBmcm9tIHZhcmlvdXMgcGxhY2VzIHN1Y2ggYXMgdGhlIGxpc3RzLCBhIHBy ZXNlbnRhdGlvbiBiZWluZyBzZW50IG91dCBpbiBhZHZhbmNlLCBhIHdlYmluYXIgaWYgaXQgaXMg ZmVsdCB0aGVyZSB3aWxsIGJlIHF1ZXN0aW9ucyBhbmQgYW5zd2VycyBmcm9tIHRob3NlIHRoYXQg YXJlIG5ldyB0byB0aGUgZWZmb3J0cy4gJm5ic3A7V2UgaGF2ZSBhIGxpbWl0ZWQgYW1vdW50IG9m IHRpbWUgYW5kIGFsbCB3aG8gYXJlIGF0dGVuZGluZyBhcmUgaW52ZXN0aW5nIGEgZ3JlYXQgZGVh bCBvZiB0aW1lIGFuZCBtb25leSB0byBiZSB0aGVyZS4gJm5ic3A7V2Ugc2hvdWxkIG5vdCAmbmJz cDtiZSBzcGVuZGluZyBhIGdyZWF0IGRlYWwgb2YgdGltZSByZWVkdWNhdGluZyBldmVyeW9uZSB3 aGVuIHdlIGNvdWxkIGJlIGZvY3VzZWQgb24gYWR2YW5jaW5nIG5lZWRlZCBlZmZvcnRzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGUgdHlwZSBv ZiBhcHByb2FjaCB0byBhIERldiBEYXlzIGV2ZW50IHdhcyBkaXNjdXNzZWQgYXQgdGhlIGxhc3Qg U3VtbWVyIERldiBEYXlzLiAmbmJzcDtJIGhhdmUgc2VlbiB0aGUgZm9sbG93aW5nIHdvcmsgcXVp dGUgd2VsbCBpbiBvdGhlciBlZmZvcnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48b2wg c3RhcnQ9MSB0eXBlPTE+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nY29sb3I6YmxhY2s7bXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzMnPlByZXNlbnRhdGlvbnMgYXJlIHNlbnQgb3V0IHRvIHRoZSBhdHRlbmRl ZXMgYW5kIHRoZSBsaXN0cyBhIHdlZWsgaW4gYWR2YW5jZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPlN0YXR1 cyBmb3IgYW55IGVmZm9ydCBpcyBsaW1pdGVkIHRvIDMwIG1pbnV0ZXM8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMn PkZvY3VzZWQgYnJhaW5zdG9ybWluZyB0aW1lIHNob3VsZCBiZSBlc3RhYmxpc2hlZCBmb3IgY2Vy dGFpbiBhcmVhcyB0aGF0IG5lZWQgcmVhbCB3b3JrIGJ5IHRoZSBjb21tdW5pdHk8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzMnPkVmZm9ydHMgdG8gYmUgZGlzY3Vzc2VkIHNob3VsZCBiZSBiYXNlZCBvbiBuZWVkcyBv ZiB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBzcGFjZSB0byBtb3ZlIGV4aXN0aW5nIGVmZm9ydHMg dG8gY29tcGxldGlvbi48bzpwPjwvbzpwPjwvbGk+PC9vbD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Rm9yIGV4YW1wbGU6PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkNvbnRpbnVvdXMgbW9uaXRvcmlu ZyBpcyBhIG1ham9yIGRpcmVjdGlvbiB0aGUgZWZmb3J0cyBhcmUgYmVjb21pbmcgaW52b2x2ZWQg d2l0aC4gVGhlcmUgYXJlIGdvaW5nIHRvIGJlIHRoaW5ncyB3ZSBuZWVkIHRvIGRvIGFzIGEgc2Vj dXJpdHkgYXV0b21hdGlvbiBjb21tdW5pdHkgdG8gYmUgYWJsZSB0byBhY2NvbXBsaXNoIHdoYXQg aXMgbGlzdGVkIGluIHRoZSBDQUVTQVJTIEZFLiAmbmJzcDtUaGVyZSBhcmUgaW50ZXJmYWNlcyB0 aGF0IG5lZWQgdG8gYmUgd29ya2VkIGFuZCBlc3RhYmxpc2hlZC4gJm5ic3A7VGhhdCBpcyBvbmUg YXJlYSB0aGF0IGlzIG5vdCBsaXN0ZWQgYmVsb3cuICZuYnNwO0NNIHdpbGwgaGF2ZSBhIG1ham9y IGltcGFjdCBvbiBhbGwgb2YgdXMgaW4gdGhlIG5leHQgY291cGxlIHllYXJzIGFuZCBpdCBpcyBi ZWluZyBpZ25vcmVkLiAmbmJzcDtXZSBjYW4ndCBrZWVwIHRyeWluZyB0byBzb2x2ZSB3aGF0IGhh cyBhbHJlYWR5IGJlZW4gc29sdmVkLiAmbmJzcDtXZSBuZWVkIHRvIGFkZHJlc3MgdGhlIG5lZWRl ZCBpbnRlcmZhY2UgZGV2ZWxvcG1lbnQgbm93LiBUaGlzIGlzIGFuIGVmZm9ydCB0aGF0IGNvdWxk IHRha2UgbmVhcmx5IGEgd2hvbGUgZGF5IGJ5IGl0c2VsZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T3BlcmF0aW9uYWxseSB3ZSBoYXZlIGEgcmVh bCBuZWVkIHRvIGJlIGFibGUgdG8gZGVsaXZlciBTQ0FQIGNvbnRlbnQgaW50ZXJuYWxseSB3aXRo aW4gYW4gb3JnYW5pemF0aW9uLiBUb2RheSB0aGUgU0NBUCB2ZW5kb3JzIGNhbm5vdCBzaGFyZSBh IHNpbmdsZSBsb2NhbCBzaXRlIHNlY3VyaXR5IHBvbGljeSAoWENDREYgKyBPVkFMICsgQ1BFICvi gKYpIHdpdGhvdXQgdGhlIHNpdGUgc3RhZmYgaGF2aW5nIHRvIGdvIHRvIGVhY2ggb2YgdGhlIGlu ZGl2aWR1YWwgcHJvZHVjdHMgYW5kIGZpZ3VyaW5nIG91dCBob3cgdG8gaW5qZWN0IHRoYXQgbmV3 IG9yIHVwZGF0ZWQgcG9saWN5IGludG8gdGhhdCBwcm9kdWN0cyBkZWxpdmVyeSBtZWNoYW5pc21z LiAmbmJzcDtUaGF0IGlzIGxpbWl0aW5nIHNpdGVzIGZyb20gd2FudGluZyB0byBidXkgbXVsdGlw bGUgZm9jdXNlZCBTQ0FQIHByb2R1Y3RzIHNpbmNlIHRoZXkgYXJlIHN1Y2ggYSBwYWluIHRvIG1h bmFnZSBmcm9tIGEgY29udGVudCBwZXJzcGVjdGl2ZS4gJm5ic3A7SXQgaXMgZWFzaWVyIHRvIGJ1 eSBmcm9tIG9uZSB2ZW5kb3IgdGhhdCBoYXMgYSBzaW5nbGUgbWVhbnMgZm9yIGRpc3RyaWJ1dGlu ZyBjb250ZW50IHRoYW4gaXQgaXMgdG8gZGVhbCB3aXRoIHRoZSBtYW5hZ2VtZW50IGlzc3VlcyB0 aGF0IGhhdmluZyBtdWx0aXBsZSBTQ0FQIHByb2R1Y3RzIHByZXNlbnRzLiAmbmJzcDtXZSBuZWVk IHRvIGhhdmUgYXQgbGVhc3QgYW4gZW50aXJlIDEvMiBhIGRheSBvbiB0aGUgZGV2ZWxvcG1lbnQg b2YgYSBDb250ZW50IFJlcG9zaXRvcnkgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T0NJTCBpcyBhIHBvc2l0aXZlIGFuZCBh IG5lZ2F0aXZlIGF0IHRoZSBzYW1lIHRpbWUuIEl0IGhhcyByZWFsIHZhbHVlIHRoYXQgaXMgYmVp bmcgdW5kZXJ1dGlsaXplZCBhbmQgdW5kZXIgaW1wbGVtZW50ZWQgYmVjYXVzZSBvZiB0aGUgbGlt aXRhdGlvbnMgb2YgaG93IGl0IGFkZHJlc3NlcyB1c2VzIGluIGFuIGVudGVycHJpc2UgZW52aXJv bm1lbnQuICZuYnNwO1Blb3BsZSBkb24ndCBuZWVkIHNlY3VyaXR5IGF1dG9tYXRpb24gdG8gZG8g dGhpbmdzIG9uL2ZvciBhIHNpbmdsZSBob3N0LiAmbmJzcDtUaGV5IG5lZWQgc2VjdXJpdHkgYXV0 b21hdGlvbiB0byBmb2N1cyBvbiB0aGUgZW50ZXJwcmlzZSBpc3N1ZXMgdGhhdCByZWR1Y2UgdGhl aXIgY29zdHMgYW5kIGltcHJvdmUgdGhlaXIgZWZmaWNpZW5jaWVzLiAmbmJzcDtPQ0lMIGlzIGZh aWxpbmcgaW4gdGhlIGVudGVycHJpc2UgYW5kIHdlIGFsbCB1bmRlcnN0YW5kIHRoYXQuICZuYnNw O1dlIG5lZWQgdG8gYWRkcmVzcyBkZXZlbG9waW5nIGEgZGVmaW5pdGl2ZSBzb2x1dGlvbiBmb3Ig aW5jb3Jwb3JhdGluZyBPQ0lMIGludG8gdGhlIGVudGVycHJpc2UgYW5kIHRoYXQgbWVhbnMgaW50 byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMuIFNjaGVkdWxpbmcgYW5kIHRyYWNraW5nIGFy ZSBrZXkgdG8gaXQncyBzdWNjZXNzLiAmbmJzcDtXZSBuZWVkIHRvIG1ha2UgdGhhdCBoYXBwZW4u ICZuYnNwO1RoaXMgdG9vIG5lZWRzIGEgZm9jdXNlZCBicmFpbnN0b3JtaW5nIHRpbWUgYm94IHRv IGRpc2N1c3Mgb3B0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+SSBhbSByZWFsbHkgZGlzYXBwb2ludGVkIHRoYXQgUmVtZWRpYXRpb24gaXMg bm90IG9uIHRoZSBsaXN0IGJlbG934oCmICZuYnNwO1llcywgbGFzdCBTdW1tZXIgRGV2IERheXMs IHRoZSB0aW1lIHNwZW50IG9uIFJlbWVkaWF0aW9uIHdhcyB3YXN0ZWQgdGltZSBidXQgdGhhdCBk b2VzIG5vdCBtZWFuIHdlIHNob3VsZCBpZ25vcmUgaXQgYW5kIG5vdCB0cnkgdG8gbWFrZSBzb21l IHJlYWwgcHJvZ3Jlc3MuICZuYnNwO0FzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCB3ZSBuZWVkIHRv IHJlYm9vdCB0aGUgcmVtZWRpYXRpb24gZWZmb3J0LiAmbmJzcDtXZSBjYW5ub3Qga2VlcCBiZWlu ZyB0aGUgc2V0IG9mIHNwZWNpZmljYXRpb25zIC8gdG9vbHMgdGhhdCBhY3QgYXMgdGhlIGxpdHRs ZSBib3kgY3J5aW5nICZxdW90O1dvbGYmcXVvdDsgaW4gdGhlIG5pZ2h0LiAmbmJzcDtXZSBuZWVk IHRvIGJlIGFibGUgdG8gZmluZCBhbmQgZml4IGlzc3VlcyBpZiB3ZSBhcmUgZ29pbmcgdG8gcmVh bGx5IG1ha2UgYSBkaWZmZXJlbmNlIGluIG9yZ2FuaXphdGlvbmFsIHNlY3VyaXR5IHBvc3R1cmVz LiAmbmJzcDtCdXQgdG9kYXkgd2UgdGhpbmsgaXQgaXMgdG9vIGhhcmQgc28gd2UgZG9uJ3QgdHJ5 ID8gJm5ic3A7SSB0aGluayB3ZSBuZWVkIGEgY291cGxlIGhvdXJzIHRvIGRpc2N1c3MgdGhlIHJl Ym9vdCBvZiB0aGUgZWZmb3J0IGV2ZW4gaWYgdGhhdCBtZWFucyBtaW5pbWl6aW5nIHdvcmsgYWxy ZWFkeSBkb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5BIGZvY3VzZWQgZGlzY3Vzc2lvbiBvbiBlbnRlcnByaXNlIHJlcG9ydGluZyBpcyBhbHNv IGNyaXRpY2FsbHkgbmVlZGVkLiAmbmJzcDtGb3IgdGhlIHZlbmRvcnMgaGVyZSwgd2UgaGF2ZSBh bGwgZ29uZSB0aHJvdWdoIHRoZSBDeWJlcnNjb3BlIGdvYXQgcm9wZSwgZGVsaXZlcmluZyBsaW1p dGVkIGNhcGFiaWxpdGllcyB0byBzcGVjaWZpYyBkYXRhIGNhbGwgcmVxdWlyZW1lbnRzIG9mIHRo ZSBGZWRlcmFsIEFnZW5jaWVzLiAmbmJzcDtUaGUgaW5pdGlhbCBlZmZvcnQgd2FzIGEgbWVzcywg ZGlkIGxpdHRsZSBtb3JlIHRoYW4gcHJvdmUgaXQgd2FzIHBvc3NpYmxlIGFuZCBjYXVzZSB0aGUg dmVuZG9yIGNvbW11bml0eSBhIGdyZWF0IGRlYWwgb2YgdGhyYXNoaW5nIHRvIHB1dCBhIGtsdWRn ZXkgJ3NvbHV0aW9uJyBpbiBwbGFjZS4gJm5ic3A7UmVhbGl0eSBpcyBhbGwgb3VyIGN1c3RvbWVy cyBuZWVkIHJvbGwgdXAgcmVwb3J0aW5nIGFuZCBhbiBpbmZyYXN0cnVjdHVyZSB0aGF0IHN1cHBv cnRzIGl0LiAmbmJzcDtBIGRhdGEgY2FsbCBzaG91bGQgbm90IGJlIHNwZWNpYWwgdG8gYW55b25l IG90aGVyIHRoYW4gdGhlIGFnZW5jaWVzIHJlc3BvbmRpbmcuIFRoZSB0b29scyBzaG91bGQgYmUg YWJsZSB0byBzZWxlY3QgdGhlIHR5cGVzIG9mIGRhdGEgbmVlZGVkIGFuZCBkZWxpdmVyIHRoYXQg b24gYSBzY2hlZHVsZWQgYmFzaXMgYXV0b21hdGljYWxseS4gJm5ic3A7ICZuYnNwO0VudGVycHJp c2UgUmVwb3J0aW5nIHBlcnRhaW5zIHRvIGNvbW1lcmNpYWwgYXMgd2VsbCBhcyBGZWRlcmFsIGN1 c3RvbWVycy4gJm5ic3A7V2UgbmVlZCB0byBmb2N1cyBzb21lIHRpbWUgb24gd2hhdCB0aGF0IHdv dWxkIGxvb2sgbGlrZSB1c2luZyB0aGUgQVJGIGFuZCBBU1IgYXMgdGhlIGZvdW5kYXRpb25hbCBw aWVjZXMuICZuYnNwO0J1dCB0aGVyZSBhcmUgbWlzc2luZyBwaWVjZXPigKYuICZuYnNwO1dlIG5l ZWQgdGhpcyBkaXNjdXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPkkgd291bGQgaG9wZSB3ZSBjYW4gbWFrZSB0aGlzIHN1bW1lcidzIFNDQVAg RGV2IERheXMgdXNlZnVsIGluIGFkdmFuY2luZyB0aGUgc2VjdXJpdHkgYXV0b21hdGlvbiBlZmZv cnRzIGJ5IGFkZHJlc3Npbmcgc29tZSBvZiB0aGUgbW9yZSBjcml0aWNhbCBpc3N1ZXMgb3VyIGN1 c3RvbWVycyBhcmUgZmFjaW5nIG5vdyBvciB3aWxsIGJlIGZhY2luZyBpbiB0aGUgdmVyeSBzaG9y dCB0ZXJtLiAmbmJzcDtTdGF0dXMgcHJlc2VudGF0aW9ucyBhcmUgbm90IGludGVyZXN0aW5nIHRv IHRob3NlIGFjdGl2ZSBpbiB0aGUgZWZmb3J0cy4gJm5ic3A7TGV0J3MgdHJ5IHRvIGRvIHRob3Nl IGJlZm9yZSB3ZSBnZXQgdG8gQmVkZm9yZCBzbyB3ZSBjYW4gcmVhbCBtYWtlIHNvbWUgcHJvZ3Jl c3Mgd2hpbGUgd2UgYXJlIGFsbCBpbiB0aGUgc2FtZSByb29tLiAmbmJzcDtUaGlzIGlzIGFsd2F5 cyBhIGJpZyBldmVudCBmb3IgdGhlICdjb25zZW5zdXMgb2YgdGhlIHdpbGxpbmcnIHRoYXQgYXNz ZW1ibGUgYW5kIGRyaXZlbiB0byBzZWUgc2VjdXJpdHkgYXV0b21hdGlvbiBtYWtlIGEgZGlmZmVy ZW5jZS4gJm5ic3A7TGV0J3Mgc2VlIGlmIHdlIGNhbiBoYXZlIGFuIGV2ZW50IHRoYXQsIHdoZW4g d2UgYWxsIHdhbGsgb3V0IHRoZSBsYXN0IGRheSwgd2UgYWxsIGZlZWwgdGhhdCBldmVyeSBtaW51 dGUgd2FzIHdlbGwgc3BlbnQgYW5kIG1vdmVzIHVzIGZvcndhcmQuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPktlbnQgTGFuZGZpZWxk PC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJyPjxzcGFuIGNsYXNzPWFwcGxl LXN0eWxlLXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJlIGFuZCBT dGFuZGFyZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwvc3Bhbj48L3N0 cm9uZz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41MDAwIEhlYWRxdWFydGVycyBE ci48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+UGxhbm8sIFRleGFzIDc1 MDI0PC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3Q6ICsx Ljk3Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bh bj5Nb2JpbGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8L3NwYW4+PC9zdHJv bmc+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3Lm1jYWZl ZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+d3d3Lm1jYWZlZS5jb208L2E+PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbHQ7 Qm9jemVub3dza2kmZ3Q7LCBTdGV2ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNib2N6ZW5vQE1JVFJF Lk9SRyIgdGFyZ2V0PSJfYmxhbmsiPnNib2N6ZW5vQE1JVFJFLk9SRzwvYT4mZ3Q7PGJyPjxiPlJl cGx5LVRvOiA8L2I+JnF1b3Q7T1ZBTCBEZXZlbG9wZXIgTGlzdCAoQ2xvc2VkIFB1YmxpYyBEaXNj dXNzaW9uKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElT VFMuTUlUUkUuT1JHIiB0YXJnZXQ9Il9ibGFuayI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5N SVRSRS5PUkc8L2E+Jmd0Ozxicj48Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpPVkFM LURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRyIgdGFyZ2V0PSJfYmxhbmsiPk9WQUwtREVW RUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHIiB0YXJnZXQ9Il9ibGFuayI+T1ZB TC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8L2E+Jmd0Ozxicj48Yj5TdWJqZWN0OiA8 L2I+UmU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3Bl ciBEYXlzOiBTdW1tZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdjb2xvcjojMjU0MDYxJz5GcmFuazs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2NvbG9yOiMyNTQwNjEnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29s b3I6IzI1NDA2MSc+V2UgaG9wZSB0byBoYXZlIHRoZSByZWdpc3RyYXRpb24gc2l0ZSB1cCBuZXh0 IHdlZWsuJm5ic3A7IFRoZSBldmVudCB3aWxsIGJlIGR1cmluZyB0aGUgd2VlayBvZiBKdWx5IDkg 4oCTIHN0YXJ0aW5nIE1vbmRheSBhdCAxMDowMCBBTSBhbmQgZW5kaW5nIG9uIEZyaWRheSBhdCAx MjowMC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+TWVhbndoaWxl LCB3ZSBhcmUgd29ya2luZyBvbiB0aGUgYWdlbmRhIGFuZCBhcmUgY3VycmVudGx5IGNvbnNpZGVy aW5nIHRoaXMgbGlzdCBvZiB0b3BpY3M6PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdj b2xvcjojMjU0MDYxJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDouNWluJz48 c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+Q0NFPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPkNQRS9TV0lEPC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPkNFRTwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0 MDYxJz5YQ0NERjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdjb2xvcjojMjU0MDYxJz5PVkFMPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+ PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPkFTUjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0MDYxJz5FbnRlcnByaXNlIE9DSUw8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2 MSc+Q3liT1gvTUFFQzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdjb2xvcjojMjU0MDYxJz5GZWRlcmF0ZWQgQ29udGVudCBSZXBvc2l0b3J5IFNwZWM8L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2 MSc+RW5kcG9pbnQgUmVwb3J0aW5nIGZvciBDb250aW51b3VzIE1vbml0b3JpbmcgYW5kIENvbXBs aWFuY2UgKEVSQ0MpPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2NvbG9yOiMyNTQwNjEnPk1JTEU8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+VEFYSUk8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2MSc+SUYtTSBmb3IgU0NBUDwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0 MDYxJz5JRi1NQVA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nY29sb3I6IzI1NDA2MSc+U0NBUCBSZWxlYXNlczwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMjU0MDYxJz5TQ0FQIGFuZCBJRVRGPC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEn Pk5FVENPTkYgYW5kIFNDQVA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMy NTQwNjEnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6IzI1NDA2 MSc+U3RldmU8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMyNTQwNjEnPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjIuMGluJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPiBGcmFuayBMaW5kc2F5IEFja2VyIFs8YSBocmVmPSJtYWlsdG86YWZy YW5rQE5PVkEuRURVIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmFmcmFua0BOT1ZBLkVEVTwvYT5d IDxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDAxLCAyMDEyIDk6MzIgQU08YnI+PGI+VG86 PC9iPiBvdmFsLWRldmVsb3Blci1saXN0IE9WQUwgRGV2ZWxvcGVyIExpc3QvQ2xvc2VkIFB1Ymxp YyBEaXNjdXNzaW9uPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09WQUwtREVWRUxPUEVSLUxJU1Rd IFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1JVFJF IGluIEJlZGZvcmQsIE1BPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+U3RldmUuLi4uPGJyPjxicj5IYXMgdGhlcmUgYmVlbiBhbnkgYWRkaXRpb25hbCBp bmZvcm1hdGlvbiByZWdhcmRpbmcgdGhpcyBldmVudD88YnI+PGJyPlRoYW5rcyw8YnI+RnJhbmsg QWNrZXI8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PGRpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48ZGl2IGNsYXNzPU1zb05vcm1h bCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9k aXY+PC9kaXY+PGRpdiBpZD1kaXZScEY5NTUyMzY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4w cHQ7bWFyZ2luLWxlZnQ6LjVpbic+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gQm9jemVub3dza2ksIFN0ZXZlIFs8YSBocmVmPSJtYWls dG86c2JvY3plbm9ATUlUUkUuT1JHIiB0YXJnZXQ9Il9ibGFuayI+c2JvY3plbm9ATUlUUkUuT1JH PC9hPl08YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDE2OjM4PGJyPjxi PlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUu T1JHIiB0YXJnZXQ9Il9ibGFuayI+T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc8 L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2VjdXJpdHkgQXV0 b21hdGlvbiBEZXZlbG9wZXIgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwg TUE8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TYXZlIHRoZSBEYXRlOiB3ZWVrIG9mIEp1bHkgOSwgMjAx MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5UaGlzIHllYXLigJlzIE1JVFJFLWhvc3RlZCBTZWN1cml0eSBBdXRvbWF0aW9uIERl dmVsb3BlciBEYXlzIGV2ZW50IHdpbGwgYmUgaGVsZCBkdXJpbmcgdGhlIHdlZWsgb2YgSnVseSA5 LCAyMDEyIGF0IE1JVFJF4oCZcyBmYWNpbGl0eSBpbiBCZWRmb3JkLCBNQS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RGV0YWls cyB0byBmb2xsb3cuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDsmbmJzcDsmbmJzcDsgU3RldmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjM0My41cHQ7bWFyZ2luLWJvdHRvbTo0LjBwdDtt YXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDozNDMuNXB0O21hcmdpbi1ib3R0b206NC4wcHQ7 bWFyZ2luLWxlZnQ6LjVpbic+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlN0ZXBoPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz5lbiBQLiBCb2N6ZW5vd3NraTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDozNDMuNXB0O21hcmdpbi1ib3R0b206Mi4w cHQ7bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6TUlUUkU7Y29sb3I6IzMzNjZGRic+TUlUUkU8L3NwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+IENvcnBvcmF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MzQzLjVwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t bGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9mZmljZTogKDc4MSkgMjcxLTc2ODI8L3NwYW4+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDozNDMu NXB0O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Q2VsbDogKDk3OCkgMzAyLTM4NDk8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6MGluO21hcmdpbi1yaWdodDozNDMuNXB0O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1s ZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJtYWlsdG86c2JvY3plbm9AbWl0cmUu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2JvY3plbm9AbWl0cmUub3JnPC9hPjwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBl bWFpbCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkci IHRhcmdldD0iX2JsYW5rIj5MSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc8L2E+IHdpdGggU0lHTk9G RiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRoZSBtZXNzYWdlLiBJZiB5b3Ug aGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIDxhIGhyZWY9Im1haWx0bzpPVkFMLURFVkVMT1BF Ui1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIiB0YXJnZXQ9Il9ibGFuayI+T1ZBTC1ERVZF TE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRzwvYT4uIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1h aWwgbWVzc2FnZSB0byA8YSBocmVmPSJtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHIiB0 YXJnZXQ9Il9ibGFuayI+TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPC9hPiB3aXRoIFNJR05PRkYg T1ZBTC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUgbWVzc2FnZS4gSWYgeW91IGhh dmUgZGlmZmljdWx0aWVzLCB3cml0ZSB0byA8YSBocmVmPSJtYWlsdG86T1ZBTC1ERVZFTE9QRVIt TElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRyIgdGFyZ2V0PSJfYmxhbmsiPk9WQUwtREVWRUxP UEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc8L2E+LiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbyB1bnN1 YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdlIHRvIDxhIGhyZWY9Im1haWx0bzpMSVNUU0VS VkBMSVNUUy5NSVRSRS5PUkciIHRhcmdldD0iX2JsYW5rIj5MSVNUU0VSVkBMSVNUUy5NSVRSRS5P Ukc8L2E+IHdpdGggU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRo ZSBtZXNzYWdlLiBJZiB5b3UgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvIDxhIGhyZWY9Im1h aWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHIiB0YXJnZXQ9 Il9ibGFuayI+T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRzwvYT4u IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9k aXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249 Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGhyIHNp emU9MSB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPnNhY20gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0 bzpzYWNtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2FjbUBpZXRmLm9yZzwvYT48YnI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CD3206.BA5284FC-- From david.waltermire@nist.gov Tue May 15 15:14: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 D8B0421F85E5 for ; Tue, 15 May 2012 15:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga8SZU+u0xic for ; Tue, 15 May 2012 15:14:37 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15221F85DD for ; Tue, 15 May 2012 15:14: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.355.2; Tue, 15 May 2012 18:14:21 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 15 May 2012 18:13:22 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Tue, 15 May 2012 18:14:34 -0400 Thread-Topic: Updated SACM Use Case Document Thread-Index: Ac0y6AFpXqaj6hh5T4O/PcSmEzyhGg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B994AAF8FMBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sacm] Updated SACM Use Case Document 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, 15 May 2012 22:14:38 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B994AAF8FMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" I have posted an updated revision of the SACM Use Cases (link below). I have included notes based on the list discussion and outlined a few areas to consider in each of the use case sections. At this point I would like to get some help from a few of you as co-editors to work specific use cases and to assist with completing the remainder of the document. I would like to work on UC4 and can support editing everything together as needed. Anyone else interested in working one or more of the use case sections? Posted document: http://www.ietf.org/staging/draft-waltermire-sacm-use-cases-00.txt Sincerely, Dave Waltermire --_000_D7A0423E5E193F40BE6E94126930C4930B994AAF8FMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5U ZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5Q bGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+SSBoYXZlIHBvc3RlZCBh biB1cGRhdGVkIHJldmlzaW9uIG9mIHRoZSBTQUNNIFVzZSBDYXNlcyAobGluayBiZWxvdykuJm5i c3A7IEkgaGF2ZSBpbmNsdWRlZCBub3RlcyBiYXNlZCBvbiB0aGUgbGlzdCBkaXNjdXNzaW9uIGFu ZCBvdXRsaW5lZCBhIGZldyBhcmVhcyB0byBjb25zaWRlciBpbiBlYWNoIG9mIHRoZSB1c2UgY2Fz ZSBzZWN0aW9ucy4mbmJzcDsgQXQgdGhpcyBwb2ludCBJIHdvdWxkIGxpa2UgdG8gZ2V0IHNvbWUg aGVscCBmcm9tIGEgZmV3IG9mIHlvdSBhcyBjby1lZGl0b3JzIHRvIHdvcmsgc3BlY2lmaWMgdXNl IGNhc2VzIGFuZCB0byBhc3Npc3Qgd2l0aCBjb21wbGV0aW5nIHRoZSByZW1haW5kZXIgb2YgdGhl IGRvY3VtZW50LiZuYnNwOyBJIHdvdWxkIGxpa2UgdG8gd29yayBvbiBVQzQgYW5kIGNhbiBzdXBw b3J0IGVkaXRpbmcgZXZlcnl0aGluZyB0b2dldGhlciBhcyBuZWVkZWQuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5BbnlvbmUgZWxzZSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb25lIG9yIG1vcmUgb2YgdGhlIHVz ZSBjYXNlIHNlY3Rpb25zPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+UG9zdGVkIGRvY3VtZW50OjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L3N0YWdpbmcvZHJhZnQtd2FsdGVybWlyZS1zYWNtLXVzZS1jYXNlcy0wMC50eHQiPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvc3RhZ2luZy9kcmFmdC13YWx0ZXJtaXJlLXNhY20tdXNlLWNhc2VzLTAwLnR4 dDwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+RGF2ZSBXYWx0ZXJtaXJlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930B994AAF8FMBCLUSTERxcha_-- From david.waltermire@nist.gov Wed May 16 12:39: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 A9E8221F8593 for ; Wed, 16 May 2012 12:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.442 X-Spam-Level: X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfaBDhWcAGQu for ; Wed, 16 May 2012 12:38:59 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE6221F858E for ; Wed, 16 May 2012 12:38:58 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 16 May 2012 15:38:39 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 16 May 2012 15:37:40 -0400 From: "Waltermire, David A." To: SCAP-DEV , "sacm@ietf.org" Date: Wed, 16 May 2012 15:38:55 -0400 Thread-Topic: Request for participants - Content Repository Specification Development Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQAArCrAAQEd+jA= Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> In-Reply-To: <66930F41F45C954AA119D59EE69C06E90C69E6098D@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_D7A0423E5E193F40BE6E94126930C4930B994AB4FDMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 16 May 2012 19:39:14 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B994AB4FDMBCLUSTERxcha_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I just posted a skeleton I/D on this topic. I have included an initial sec= tion that focuses on identifying the overall problem space relating to cont= ent repositories. I'd appreciate any comments. Here is the draft: http://www.ietf.org/id/draft-waltermire-content-repository-00.txt Sincerely, Dave From: Waltermire, David A. Sent: Friday, May 11, 2012 1:13 PM To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV; sacm@ie= tf.org Subject: RE: Request for participants - Content Repository Specification De= velopment Kent, I have already started work on a draft specification in this area. My hope= is that this work could be used as an initial draft within SACM at the app= ropriate time. Count me in. I mostly agree with what you are describing below. The only area I disagre= e with is in regards to federation. If we do not implement the specificati= on for an organizational repository in the right way, we may need to make m= ajor changes to support federation. This is not good for anyone. In my mi= nd these two concepts cannot be decoupled. We need to insure that any work= towards supporting an organizational repository provides a foundation for = supporting a federated repository network. Imagine if DNS was designed wit= h a single organization mindset first without thinking about federation. T= op Level Domains (TLDs) and subdomains would not likely exist as concepts. = An individual DNS server would likely not support caching, time-to-live an= d delegating capabilities that are necessary for federation to happen. All= of these things would need to be retrofitted. To prevent this, we need to= address the building blocks of federation in the basic design. Sincerely, Dave From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Friday, May 11, 2012 12:36 PM To: m.kinne@radium.ncsc.mil; Waltermire, Da= vid A.; SCAP-DEV; sacm@ietf.org Subject: Request for participants - Content Repository Specification Develo= pment Mike I love it when you tee something up like that.... ;-) Thank you. ;) Mike wrote: I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more... If you are talking about a holistic, complete federated approach to a conte= nt repository, I some what agree. If you are talking about an organization= al repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and oth= er related content to be served up inside an organization. Today we have s= ituation where the standards allow us to provide sites the capability to ha= ve a single SCAP implemented policy they call official for their environmen= t. Yes this is a rather simplistic since there are things such as targeting= specific platforms, specific operational use needs, but for now lets agree= SCAP is a massive improvement over the proprietary situations of the past.= While we have created this standard content so that sites can implement th= eir local site security once and then assure they are measuring all appropr= iately targeted devices the same way, we have failed to support the operati= onal needs of the sites. We have a situation where no two vendors distribu= te content the same way. This causes massive problems for the administrati= on staff when they need to incorporate a new SCAP enabled product into thei= r architecture. They need to discover how the new product supports distrib= uting SCAP content to it's various components. If they have one product th= en they do this one and they are done. If they have multiple products they= will have to figure out how to minimize the impact by incorporating the up= date process for the new product into the existing SCAP security content pr= ocesses. Now when the inevitable happens and the site staff needs to make a= change to their security policy, they have to make the modifications to th= e benchmark or checks or both and then distribute those updates across thei= r network. For each SCAP enabled product they have in place, they have dou= bled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Conte= nt Distribution. If you think global DNS you have a general frame of refer= ence. The guidance authors need to be able to publish content in an author= itative manner so their content is updated in a timely fashion. This is a = much harder problem to solve if there is no local organizational infrastruc= ture to support it. ;) So here is what I am thinking... We should consider addressing these as tw= o separate but integrated efforts. I believe the Organizational Content Re= pository is the more critical piece that is actually easier to address. Th= e Federated Content Distribution should be a subsequent effort integrating = / augmenting the Organizational repository specification. Mike, to your point that we need someone to build one first... That has hap= pened already. I have one as do other vendors but what we don't have is th= e access specification. Ours are focused on our specific product needs. A= dditionally there is a company that has developed a commercial SCAP content= repository that will be announced later this month. I won't steal their th= under but I was recently given a sneak peek at it and I must admit I was ve= ry impressed. Again, to your point, it has been done. What is needed to ad= dress the initial operational problem is to develop a specification that pr= ovides a consistent means for all SCAP products to retrieve the appropriate= content as configured and managed but the site. TO THAT END.... I am requesting participation from those in the community that see the need= and want to put in the work to make this specification happen. I have tal= ked to a couple of you but I do not want to assume your participation. If = you are interested please contact me so we can get this started. Thanks! Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Michael A > To: David Waltermire >, SCAP-DEV >, "sacm@ietf= .org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionabl= e and use it to make decisions, and vote and accomplish things good or bad.= I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more... -Mike From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content reposit= ory for use in a production environment. As an open source project, it wil= l be free for use by anyone interested. My thinking is that this project c= an bridge the gap until commercial solutions are available to augment it. = This is a similar path that was followed with DNS (bind) and HTTP (apache).= When it is ready for use, I am hoping to use it to host USGCB content. Y= ou would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supp= orting risk management and aspects of continuous monitoring. I would also = like to see some discussion on OCIL at Developer Days. With the proposals = we will likely have a sense of what needs to be discussed and what we can a= chieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see = it move forward. We just published the draft ASR specification for public comment. This spe= cification supports enterprise aggregate reporting which greatly reduces th= e data volumes needed verses detailed host-based reports. This specificatio= n has been designed as a more robust replacement for LASR. It can be used = in continuous monitoring applications to support aggregate data reporting n= eeds (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internatio= nalization issue. Many vendors have commented that they are still working o= n implementing the XCCDF 1.2.1 specification. We will be in a better place = in a few months once more development around XCCDF has occurred. As we con= sider changes to the SCAP stack to address OCIL and other issues, we will i= dentify areas that need improvement in XCCDF. These are good and necessary= discussions to have now, but we have a good deal of work to do before we a= re ready to open up XCCDF. My suggestion is to work on these related areas= and then work up change proposals for XCCDF as needed. By that time we sh= ould be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has bee= n too long. Sincerely, Dave From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, It's good to read your thoughts, and a realistic actionable approach is ind= eed needed. Since all the activity hasn't been on the lists a brief 1=AE2 = hour recap may be in order to bring everyone up to speed since there has be= en a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone will= ing to stand one up it will be as valuable as the CCSS specification is tod= ay. I've been trying for two years to get my management to get a coordinat= ed effort together for the DoD to stand up a repository, it is a tough prob= lem and will require funding with a tail, I'm not sure a specification will= solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year try= ing to make it useful in an enterprise environment and will be posting our = ideas to the list before developer days it should have already started, we = need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I'm making every effort to get it kick started f= rom our perspective. I hope to assist in getting the draft ERI finished thi= s year. We are writing some new STIG content and intend to used the draft = CRE specification to insert CRE into the content so we (DoD) can do some au= tomatic configuration fixes, part of a self healing network concept. It is = just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and = content to roll up reporting, in any enterprise of size the problem gets gr= eater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from ef= forts to meet use cases, we have some things we would like changed in XCCDF= to support our OCIl use case and I have been told that I need to wait. I d= idn't think that a move to internationalization should impede efforts to mo= ve forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of ap= proach. We would like to see some community discussion around what are the= key areas/priorities that the community would like to see discussed at Dev= Days. Your topics below look like a good start. The SACM list might be a = better venue than the OVAL list for this discussion. For each area we shou= ld focus the discussion around developing objectives for each session. The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective. For example if continuous monitoring is = a priority and collectively it takes 3 days to work through all the objecti= ves, I see no problem with that. We can also keep a few sessions "on deck"= if all the objectives are reached and we complete all the scheduled sessio= ns early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.com<= mailto:Kent_Landfield@mcafee.com> Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation being sent out in advance, a webinar if it is felt there will be = questions and answers from those that are new to the efforts. We have a li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in ad= vance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas tha= t need real work by the community 4. Efforts to be discussed should be based on needs of the security autom= ation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d with. There are going to be things we need to do as a security automation= community to be able to accomplish what is listed in the CAESARS FE. Ther= e are interfaces that need to be worked and established. That is one area = that is not listed below. CM will have a major impact on all of us in the = next couple years and it is being ignored. We can't keep trying to solve w= hat has already been solved. We need to address the needed interface devel= opment now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +...) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e they are such a pain to manage from a content perspective. It is easier = to buy from one vendor that has a single means for distributing content tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that = is being underutilized and under implemented because of the limitations of = how it addresses uses in an enterprise environment. People don't need secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. Scheduling and tracking are key to it's success. We need to make that= happen. This too needs a focused brainstorming time box to discuss option= s. I am really disappointed that Remediation is not on the list below... Yes,= last Summer Dev Days, the time spent on Remediation was wasted time but th= at does not mean we should ignore it and not try to make some real progress= . As far as I am concerned we need to reboot the remediation effort. We c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. But today we think it is too hard so we don't try ? I think we need = a couple hours to discuss the reboot of the effort even if that means minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al Agencies. The initial effort was a mess, did little more than prove it = was possible and cause the vendor community a great deal of thrashing to pu= t a kludgey 'solution' in place. Reality is all our customers need roll up= reporting and an infrastructure that supports it. A data call should not = be special to anyone other than the agencies responding. The tools should b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces.... We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess while we are all in the same room. This is always a big event for the = 'consensus of the willing' that assemble and driven to see security automat= ion make a difference. Let's see if we can have an event that, when we all= walk out the last day, we all feel that every minute was well spent and mo= ves us forward. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng the week of July 9 - starting Monday at 10:00 AM and ending on Friday at= 12:00. Meanwhile, we are working on the agenda and are currently considering this = list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year's MITRE-hosted Security Automation Developer Days event will be h= eld during the week of July 9, 2012 at MITRE's facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. --_000_D7A0423E5E193F40BE6E94126930C4930B994AB4FDMBCLUSTERxcha_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

I just posted a skeleton I/D on this topic.=A0 I have include= d an initial section that focuses on identifying the overall problem space = relating to content repositories.=A0 I’d appreciate any comments.

&= nbsp;

He= re is the draft:

http://www.ietf.org/id/draft-waltermire-content-repository= -00.txt

 

Sincerely,

Dave

 

From: Waltermire, David A.
Sent: Friday, Ma= y 11, 2012 1:13 PM
To: 'Kent_Landfield@McAfee.com'; m.kinne@radiu= m.ncsc.mil; SCAP-DEV; sacm@ietf.org
Subject: RE: Request for part= icipants - Content Repository Specification Development

 

Kent,

 

I have already started work on a dra= ft specification in this area.  My hope is that this work could be use= d as an initial draft within SACM at the appropriate time.  Count me i= n.

=  

I mostly agree with what you are describing below.  The only area = I disagree with is in regards to federation.  If we do not implement t= he specification for an organizational repository in the right way, we may = need to make major changes to support federation.  This is not good fo= r anyone.  In my mind these two concepts cannot be decoupled.  We= need to insure that any work towards supporting an organizational reposito= ry provides a foundation for supporting a federated repository network.&nbs= p; Imagine if DNS was designed with a single organization mindset first wit= hout thinking about federation.  Top Level Domains (TLDs) and subdomai= ns would not likely exist as concepts.  An individual DNS server would= likely not support caching, time-to-live and delegating capabilities that = are necessary for federation to happen.  All of these things would nee= d to be retrofitted.  To prevent this, we need to address the building= blocks of federation in the basic design.

 

Sincerely,

Dave

 = ;

From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] =
Sent: Friday, May 11, 2012 12:36 PM
To: m.kinne@radium.ncsc.mil; Waltermire, David= A.; SCAP-DEV; sacm@ietf.org
Sub= ject: Request for participants - Content Repository Specification Devel= opment

 

Mike= I love it when you tee something up like that…. ;-)  Thank you.= ;)

 

Mike wrote: 

= I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec.  I believe the DoD needs to incorporate a metadata reposi= tory as part of it and other customizations that may not be useful for ever= yone.

We need to talk more…

 

If you are talking about a holistic, complete federa= ted approach to a content repository, I some what agree.  If you are t= alking about an organizational repository, I totally disagree. But you knew= I would. ;)

 

Here is how I see the problem.  There is an i= mmediate need for SCAP and other related content to be served up inside an = organization.  Today we have situation where the standards allow us to= provide sites the capability to have a single SCAP implemented policy they= call official for their environment. Yes this is a rather simplistic since= there are things such as targeting specific platforms, specific operationa= l use needs, but for now lets agree SCAP is a massive improvement over the = proprietary situations of the past. While we have created this standard con= tent so that sites can implement their local site security once and then as= sure they are measuring all appropriately targeted devices the same way, we= have failed to support the operational needs of the sites.  We have a= situation where no two vendors distribute content the same way.  This= causes massive problems for the administration staff when they need to inc= orporate a new SCAP enabled product into their architecture.  They nee= d to discover how the new product supports distributing SCAP content to it'= s various components.  If they have one product then they do this one = and they are done.  If they have multiple products they will have to f= igure out how to minimize the impact by incorporating the update process fo= r the new product into the existing SCAP security content processes. Now wh= en the inevitable happens and the site staff needs to make a change to thei= r security policy, they have to make the modifications to the benchmark or = checks or both and then distribute those updates across their network. &nbs= p;For each SCAP enabled product they have in place, they have doubled, trip= led or more the work needed to make those updates available. 

 

There is an= other content repository problem and that is the Federated Content Distribu= tion.  If you think global DNS you have a general frame of reference. =  The guidance authors need to be able to publish content in an authori= tative manner so their content is updated in a timely fashion.  This i= s a much harder problem to solve if there is no local organizational infras= tructure to support it. ;)

 

So here is what I am thinking…  We shoul= d consider addressing these as two separate but integrated efforts.  I= believe the Organizational Content Repository is the more critical piece t= hat is actually easier to address.  The Federated Content Distribution= should be a subsequent effort integrating / augmenting the Organizational = repository specification. 

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

Mike, to your point that we need someone to bu= ild one first… That has happened already.  I have one as do othe= r vendors but what we don’t have is the access specification.  O= urs are focused on our specific product needs.  Additionally there is = a company that has developed a commercial SCAP content repository that will= be announced later this month. I won't steal their thunder but I was recen= tly given a sneak peek at it and I must admit I was very impressed.  A= gain, to your point, it has been done. What is needed to address the initia= l operational problem is to develop a specification that provides a consist= ent means for all SCAP products to retrieve the appropriate content as conf= igured and managed but the site.  

 

TO THAT END….<= /p>

 

I am requesting parti= cipation from those in the community that see the need and want to put in t= he work to make this specification happen.  I have talked to a couple = of you but I do not want to assume your participation.  If you are int= erested please contact me so we can get this started. 

 

Thanks!=

 

Kent Landfiel= d
Director Content St= rategy, Architecture and Standards

McAfee | An Intel Company5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

<= p class=3DMsoNormal> 

 

Dave,

I have no problem with webinars, I do want to keep developer days ac= tionable and use it to make decisions, and vote and accomplish things good = or bad.  I do not want this to be an informational briefing conference= .

Thanks for the links.

 <= /p>

I still think that an= y specification for a repository is wishful thinking until someone builds o= ne and learns the lessons it will just be another whitepaper spec.  I = believe the DoD needs to incorporate a metadata repository as part of it an= d other customizations that may not be useful for everyone.

We need to talk more…

 

-Mike 

 <= /p>

From: Waltermir= e, David A. [mailto:david.walt= ermire@nist.gov]
Sent: Tuesday, May 08, 2012 10:44 AM
= To: Kinney, Michael A; SCAP-DEV; sacm@= ietf.org
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automati= on Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-place of the 30 m= inute briefs?

 

Regarding content management, we are building the prototype conte= nt repository for use in a production environment.  As an open source = project, it will be free for use by anyone interested.  My thinking is= that this project can bridge the gap until commercial solutions are availa= ble to augment it.  This is a similar path that was followed with DNS = (bind) and HTTP (apache).  When it is ready for use, I am hoping to us= e it to host USGCB content.  You would be welcome to use it for your n= eeds.

 

It is good that OCIL is moving forward.  This is an important piece = of supporting risk management and aspects of continuous monitoring.  I= would also like to see some discussion on OCIL at Developer Days.  Wi= th the proposals we will likely have a sense of what needs to be discussed = and what we can achieve consensus on outside the meeting.

 <= /p>

Remediation is a topi= c near and dear to my heart.  I too would like to see it move forward.=

 <= o:p>

We = just published the draft ASR specification for public comment.  This s= pecification supports enterprise aggregate reporting which greatly reduces = the data volumes needed verses detailed host-based reports. This specificat= ion has been designed as a more robust replacement for LASR.  It can b= e used in continuous monitoring applications to support aggregate data repo= rting needs (e.g. FISMA reporting,  CyberScope).

 

<= p class=3DMsoNormal>Here are the links:

 

http://csrc.nist.gov= /publications/PubsDrafts.html

http:/= /csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

 

The primary reaso= n we have suggested waiting on XCCDF is not the internationalization issue.= Many vendors have commented that they are still working on implementing th= e XCCDF 1.2.1 specification. We will be in a better place in a few months o= nce more development around XCCDF has occurred.  As we consider change= s to the SCAP stack to address OCIL and other issues, we will identify area= s that need improvement in XCCDF.  These are good and necessary discus= sions to have now, but we have a good deal of work to do before we are read= y to open up XCCDF.  My suggestion is to work on these related areas a= nd then work up change proposals for XCCDF as needed.  By that time we= should be ready to work on a new revision of XCCDF.

 

I am also looking forward = to the discussions at the conference.  It has been too long.

 =

Sincerel= y,

Dave<= o:p>

 

From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil= ]
Sent: Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
= Cc: Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST= ] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

It’s good to read your= thoughts, and a realistic actionable approach is indeed needed.  Sinc= e all the activity hasn’t been on the lists a brief 1=AE2 hour recap = may be in order to bring everyone up to speed since there has been a lot of= activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

 <= /p>

We could write a cont= ent repository specification, but without someone willing to stand one up i= t will be as valuable as the CCSS specification is today.  I’ve = been trying for two years to get my management to get a coordinated effort = together for the DoD to stand up a repository, it is a tough problem and wi= ll require funding with a tail, I’m not sure a specification will sol= ve that problem.

 

We (DoD) have been putting a lot of effort into OCIL over th= e last year trying to make it useful in an enterprise environment and will = be posting our ideas to the list before developer days it should have alrea= dy started, we need to get consensus and a vote on how the community wishes= to proceed.

 

Remediation is stalled but I’m making every effort to get it= kick started from our perspective. I hope to assist in getting the draft E= RI finished this year.  We are writing some new STIG content and inten= d to used the draft CRE specification to insert CRE into the content so we = (DoD) can do some automatic configuration fixes, part of a self healing net= work concept. It is just a start but the best we can do at this point.

 <= /o:p>

Enterpri= se reporting is an interesting subject, since XML adds size to and content = to roll up reporting, in any enterprise of size the problem gets greater, I= look forward to your thoughts on that subject.

 

I am concerned that the interna= tionalization efforts are detracting from efforts to meet use cases, we hav= e some things we would like changed in XCCDF to support our OCIl use case a= nd I have been told that I need to wait. I didn’t think that a move t= o internationalization should impede efforts to move forward with use cases= .

 =

I = look forward to talking with you at the conference.

 

v/r

 =

Mike Kinney

Projec= t Director

Computer Network Defense Research and Technology (CND R&a= mp;T) Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767Phone: 410-854-4422<= br>NSTS: 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

=  

From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Beh= alf Of Waltermire, David A.
Sent: Monday, May 07, 2012 7:09 P= M
To: Multiple recipients of list
Subject: RE: [OVAL-DE= VELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in B= edford, MA

 

Kent,

 

I like what you = are saying here.  We are also in support of this type of approach.&nbs= p; We would like to see some community discussion around what are the key a= reas/priorities that the community would like to see discussed at Dev Days.=   Your topics below look like a good start. The SACM list might be a b= etter venue than the OVAL list for this discussion.  For each area we = should focus the discussion around developing objectives for each session.&= nbsp; The sessions can be time boxed based on what would be a reasonable am= ount of time to accomplish each objective.  For example if continuous = monitoring is a priority and collectively it takes 3 days to work through a= ll the objectives, I see no problem with that.  We can also keep a few= sessions “on deck” if all the objectives are reached and we co= mplete all the scheduled sessions early.=

&n= bsp;

Thoughts?

 

Sincerely,

 

David Waltermire=

SC= AP Architect

National Institute of Standard= s and Technology

(301) 975-3390

david.walte= rmire@nist.gov

 =

From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of <= a href=3D"mailto:Kent_Landfield@mcafee.com">Kent_Landfield@mcafee.comSent: Monday, May 07, 2012 4:25 PM
To: SCAP-DEV
Su= bject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Su= mmer 2012 at MITRE in Bedford, MA

 

All,

 

I would like to discuss the = format for the SCAP Developer Days that seems to be listed below.

&nb= sp;

I see this appears to follow a path we have discussed in the past= as the way not to hold a Dev Days event.  We have been trying to get = away from 'Death by Powerpoint' and back to the type of event we held years= ago when we were highly productive.  In the past we had a topic to be= discussed and a time box to work within.  That allowed us to have ver= y active brainstorming sessions in a high bandwidth environment.=

&nbs= p;

At past Summer events we have got into a pattern of lots of powerp= oint, lots of status of the efforts and very little discussion about things= that need active discussions.  We need to keep moving forward and mak= ing progress as an effort. We can get status from various places such as th= e lists, a presentation being sent out in advance, a webinar if it is felt = there will be questions and answers from those that are new to the efforts.=  We have a limited amount of time and all who are attending are inves= ting a great deal of time and money to be there.  We should not  = be spending a great deal of time reeducating everyone when we could be focu= sed on advancing needed efforts.

 

=

The type of approach = to a Dev Days event was discussed at the last Summer Dev Days.  I have= seen the following work quite well in other efforts.

=
  1. Pr= esentations are sent out to the attendees and the lists a week in advance.<= o:p>
  2. Status for any e= ffort is limited to 30 minutes
  3. Focused brainstorming time should be established for certa= in areas that need real work by the community
  4. Efforts to be discussed should be based on ne= eds of the security automation space to move existing efforts to completion= .

For example:

 

Continuous monitoring is a major direction= the efforts are becoming involved with. There are going to be things we ne= ed to do as a security automation community to be able to accomplish what i= s listed in the CAESARS FE.  There are interfaces that need to be work= ed and established.  That is one area that is not listed below.  = CM will have a major impact on all of us in the next couple years and it is= being ignored.  We can't keep trying to solve what has already been s= olved.  We need to address the needed interface development now. This = is an effort that could take nearly a whole day by itself.

 

Operationally we have a real need to be able to deliver SCAP content int= ernally within an organization. Today the SCAP vendors cannot share a singl= e local site security policy (XCCDF + OVAL + CPE +…) without the site= staff having to go to each of the individual products and figuring out how= to inject that new or updated policy into that products delivery mechanism= s.  That is limiting sites from wanting to buy multiple focused SCAP p= roducts since they are such a pain to manage from a content perspective. &n= bsp;It is easier to buy from one vendor that has a single means for distrib= uting content than it is to deal with the management issues that having mul= tiple SCAP products presents.  We need to have at least an entire 1/2 = a day on the development of a Content Repository specification.<= /span>

 = ;

OCIL is a positive and a negative at the same time. It has real val= ue that is being underutilized and under implemented because of the limitat= ions of how it addresses uses in an enterprise environment.  People do= n't need security automation to do things on/for a single host.  They = need security automation to focus on the enterprise issues that reduce thei= r costs and improve their efficiencies.  OCIL is failing in the enterp= rise and we all understand that.  We need to address developing a defi= nitive solution for incorporating OCIL into the enterprise and that means i= nto the existing specifications. Scheduling and tracking are key to it's su= ccess.  We need to make that happen.  This too needs a focused br= ainstorming time box to discuss options.

 

=

I am really dis= appointed that Remediation is not on the list below…  Yes, last = Summer Dev Days, the time spent on Remediation was wasted time but that doe= s not mean we should ignore it and not try to make some real progress. &nbs= p;As far as I am concerned we need to reboot the remediation effort.  = We cannot keep being the set of specifications / tools that act as the litt= le boy crying "Wolf" in the night.  We need to be able to fi= nd and fix issues if we are going to really make a difference in organizati= onal security postures.  But today we think it is too hard so we don't= try ?  I think we need a couple hours to discuss the reboot of the ef= fort even if that means minimizing work already done.

=

 

A = focused discussion on enterprise reporting is also critically needed.  = ;For the vendors here, we have all gone through the Cyberscope goat rope, d= elivering limited capabilities to specific data call requirements of the Fe= deral Agencies.  The initial effort was a mess, did little more than p= rove it was possible and cause the vendor community a great deal of thrashi= ng to put a kludgey 'solution' in place.  Reality is all our customers= need roll up reporting and an infrastructure that supports it.  A dat= a call should not be special to anyone other than the agencies responding. = The tools should be able to select the types of data needed and deliver tha= t on a scheduled basis automatically.    Enterprise Reporting per= tains to commercial as well as Federal customers.  We need to focus so= me time on what that would look like using the ARF and ASR as the foundatio= nal pieces.  But there are missing pieces….  We need this d= iscussed.

 

I would hope we can make this summer's SCAP D= ev Days useful in advancing the security automation efforts by addressing s= ome of the more critical issues our customers are facing now or will be fac= ing in the very short term.  Status presentations are not interesting = to those active in the efforts.  Let's try to do those before we get t= o Bedford so we can real make some progress while we are all in the same ro= om.  This is always a big event for the 'consensus of the willing' tha= t assemble and driven to see security automation make a difference.  L= et's see if we can have an event that, when we all walk out the last day, w= e all feel that every minute was well spent and moves us forward.

&nb= sp;

Thanks.

 

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfe= e | An Intel Company
5000= Headquarters Dr.
Plano, Texas 750= 24

Direct: +1.972.963.7096&nbs= p;
Mobile: +1.817.637.8026<= br>Web: www.mcafee.com

 

From: <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply-To: "OVAL Developer List = (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: = "OVAL-DEVELOPER= -LIST@LISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
Subject: = Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 20= 12 at MITRE in Bedford, MA

 

<= p class=3DMsoNormal>Frank;

 <= /p>

We hope to have the r= egistration site up next week.  The event will be during the week of J= uly 9 – starting Monday at 10:00 AM and ending on Friday at 12:00.

=  

Meanwh= ile, we are working on the agenda and are currently considering this list o= f topics:

 

CCE

CPE/SWID

CEE

=

XCCDF

OVAL<= /span>

ASR

Enterprise OCIL

CybOX/MAEC

Federated Content Repository Spec=

Endpoint Report= ing for Continuous Monitoring and Compliance (ERCC)

MILE=

TAXII

IF-M for SCAP<= /span>

IF-MAP

SCAP Releases

<= p class=3DMsoNormal style=3D'margin-left:.5in'>SCAP and IETF

= NETCONF and SCAP

 

Steve

 

From: Frank Lindsay Acke= r [mailto:afrank@NOVA.EDU]
Se= nt: Tuesday, May 01, 2012 9:32 AM
To: oval-developer-list OVA= L Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVE= LOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bed= ford, MA

 

Steve....

Has there been any additional information reg= arding this event?

Thanks,
Frank Acker

From: Boczenowski= , Steve [sboczeno@MITRE.ORG]
<= b>Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG=
Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA

Save the Date: week of July 9, 2012

 

This year’s MITRE-h= osted Security Automation Developer Days event will be held during the week= of July 9, 2012 at MITRE’s facility in Bedford, MA.

 

Details to follow.

=

 

Regards,

  &n= bsp; Steve

 

______________________________________________

Stephen P. Boczenowski<= /i>

      The MITRE Cor= poration

   &nb= sp;  Office: (781) 271-7682

      Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an= email message to LISTSERV@LIST= S.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message= . If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG. <= /span>

<= p class=3DMsoNormal style=3D'margin-left:.5in'>To unsubscribe, send= an email message to LISTSERV@L= ISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the mess= age. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG= .

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVEL= OPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER= -LIST-request@LISTS.MITRE.ORG. =

= --_000_D7A0423E5E193F40BE6E94126930C4930B994AB4FDMBCLUSTERxcha_-- From Kent_Landfield@mcafee.com Wed May 16 12:40: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 5132721F85B9 for ; Wed, 16 May 2012 12:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-SeqLBaON5O for ; Wed, 16 May 2012 12:40:17 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 819E921F8593 for ; Wed, 16 May 2012 12:40:17 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 5cce_69a5_3617eb29_cb44_4f32_9fb4_db5cfc0c9d82; Wed, 16 May 2012 14:40:12 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 16 May 2012 14:39:04 -0500 From: To: , Date: Wed, 16 May 2012 14:39:43 -0500 Thread-Topic: [sacm] Updated SACM Use Case Document Thread-Index: Ac0zm4zmUnYLNk1VQou+bpT+T0hW3Q== 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.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD96AAF33500kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Updated SACM Use Case Document 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, 16 May 2012 19:40:18 -0000 --_000_CBD96AAF33500kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dave, Sorry, coming up for air=85 ;-) I will help and volunteer to work on UC3. Please include me as one of the co-authors. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > To: "sacm@ietf.org" > Subject: [sacm] Updated SACM Use Case Document I have posted an updated revision of the SACM Use Cases (link below). I ha= ve included notes based on the list discussion and outlined a few areas to = consider in each of the use case sections. At this point I would like to g= et some help from a few of you as co-editors to work specific use cases and= to assist with completing the remainder of the document. I would like to = work on UC4 and can support editing everything together as needed. Anyone else interested in working one or more of the use case sections? Posted document: http://www.ietf.org/staging/draft-waltermire-sacm-use-cases-00.txt Sincerely, Dave Waltermire --_000_CBD96AAF33500kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dave,
=

Sorry, coming up for air=85 ;-)  I will help and v= olunteer to work on UC3.  

Please include me = as one of the co-authors. 

Thanks.
=

Director Content Strategy, Architecture and Standards
<= span class=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb(96, 10= 6, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-sp= acing: 1px; font-family: Arial, Helvetica, sans-serif; ">
McAfee | An Inte= l Company

Plano, Texas 75024


Mobile: +1.817.637.8026
Web: www.mcafee.com<= /span>

From: <Waltermire>, David Waltermire <david.waltermire@nist.gov>
To: "sacm@ietf.org" <sacm@ietf.= org>
Subject: [sacm] Upd= ated SACM Use Case Document

I have poste= d an updated revision of the SACM Use Cases (link below).  I have incl= uded notes based on the list discussion and outlined a few areas to conside= r in each of the use case sections.  At this point I would like to get= some help from a few of you as co-editors to work specific use cases and to assist w= ith completing the remainder of the document.  I would like to work on= UC4 and can support editing everything together as needed.

<= p class=3D"MsoNormal"> 

Anyone el= se interested in working one or more of the use case sections?

 

Posted= document:

http://www.ietf.org/= staging/draft-waltermire-sacm-use-cases-00.txt

 

Sincerely,<= /o:p>

Dave Waltermire

 

 --_000_CBD96AAF33500kentlandfieldmcafeecom_-- From kathleen.moriarty@emc.com Wed May 16 12:59:33 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 BA60B21F85E6 for ; Wed, 16 May 2012 12:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NevPRM9zZEEH for ; Wed, 16 May 2012 12:59:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD5521F85E3 for ; Wed, 16 May 2012 12:59:32 -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 q4GJxTLi008918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 May 2012 15:59:31 -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, 16 May 2012 15:59:25 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4GJxODn025631; Wed, 16 May 2012 15:59:25 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 16 May 2012 15:59:25 -0400 From: To: , , Date: Wed, 16 May 2012 15:59:23 -0400 Thread-Topic: [sacm] Updated SACM Use Case Document Thread-Index: Ac0zm4zmUnYLNk1VQou+bpT+T0hW3QAAsDSw 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_AE31510960917D478171C79369B660FA0E96B66EB5MX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Updated SACM Use Case Document 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, 16 May 2012 19:59:33 -0000 --_000_AE31510960917D478171C79369B660FA0E96B66EB5MX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I would like to help on UC5. I should have time in the next week to get so= mething to you. Thank you! Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Wednesday, May 16, 2012 3:40 PM To: david.waltermire@nist.gov; sacm@ietf.org Subject: Re: [sacm] Updated SACM Use Case Document Dave, Sorry, coming up for air... ;-) I will help and volunteer to work on UC3. Please include me as one of the co-authors. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > To: "sacm@ietf.org" > Subject: [sacm] Updated SACM Use Case Document I have posted an updated revision of the SACM Use Cases (link below). I ha= ve included notes based on the list discussion and outlined a few areas to = consider in each of the use case sections. At this point I would like to g= et some help from a few of you as co-editors to work specific use cases and= to assist with completing the remainder of the document. I would like to = work on UC4 and can support editing everything together as needed. Anyone else interested in working one or more of the use case sections? Posted document: http://www.ietf.org/staging/draft-waltermire-sacm-use-cases-00.txt Sincerely, Dave Waltermire --_000_AE31510960917D478171C79369B660FA0E96B66EB5MX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

I would like to help on UC5.&nb= sp; I should have time in the next week to get something to you.=

 

Thank you= !

K= athleen

 

From:= sac= m-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_= Landfield@McAfee.com
Sent: Wednesday, May 16, 2012 3:40 PM
= To: david.waltermire@nist.gov; sacm@ietf.org
Subject: Re: [sa= cm] Updated SACM Use Case Document

 

Dave,

 

=

Sorry, coming up for air&#= 8230; ;-)  I will help and volunteer to work on UC3.  =

 

Please include me as one of the co-authors. 

 = ;

Thanks.

 

Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An = Intel Company
5000 Headqu= arters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.m= cafee.com

 

From: <W= altermire>, David Waltermire <david.waltermire@nist.gov>
To: "sacm@ietf.org" <sacm@ietf.org>
Subject: [sacm] Updated SACM Use Case D= ocument

&= nbsp;

I have posted an updated revision of the SA= CM Use Cases (link below).  I have included notes based on the list di= scussion and outlined a few areas to consider in each of the use case secti= ons.  At this point I would like to get some help from a few of you as= co-editors to work specific use cases and to assist with completing the re= mainder of the document.  I would like to work on UC4 and can support = editing everything together as needed.

 

Anyone else interested in working one o= r more of the use case sections?

=  

Posted document:

http://www.ietf.org/stagin= g/draft-waltermire-sacm-use-cases-00.txt

 

Sincerely,

=

Dave Waltermire=

 

= --_000_AE31510960917D478171C79369B660FA0E96B66EB5MX06Acorpemcc_-- From Kent_Landfield@mcafee.com Wed May 16 13:01:33 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 B3AEC21F85E6 for ; Wed, 16 May 2012 13:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.081 X-Spam-Level: X-Spam-Status: No, score=-6.081 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbmCrB2sW1TO for ; Wed, 16 May 2012 13:01:33 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id CD7C521F85E3 for ; Wed, 16 May 2012 13:01:32 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 5ced_05d9_d2a36f94_556d_4256_b64a_68084ac9344d; Wed, 16 May 2012 15:01:26 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Wed, 16 May 2012 15:00:52 -0500 From: To: , Date: Wed, 16 May 2012 15:01:31 -0500 Thread-Topic: Continuous Monitoring and SCAP Developer Days Thread-Index: Ac0znpgg2DZdr3GDQBuysGDNKJJVag== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD941F033378kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: [sacm] Continuous Monitoring and SCAP Developer Days 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, 16 May 2012 20:01:33 -0000 --_000_CBD941F033378kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, I know this is a bit early but I want to give everyone time to prepare for = the Continuous Monitoring (CM) sessions at SCAP Developer Days. If you are = attending I would encourage you to do a little homework before you come. L= et's make sure we can have highly productive sessions around Continuous Mon= itoring. The following documents are the basic background needed to make r= eal progress in the F2F. CM efforts are going to leverage existing SCAP spe= cifications but will also need to have additional interfaces defined to be = able to appropriately implement CM Instances. If we are prepared then as a = group we can be much more productive and not leave anyone behind. Here is a list of the CM related documents. - DHS Federal Network Security (FNS) Branch - =94Continuous Asset Evaluatio= n, Situational Awareness, and Risk Scoring Reference Architecture Report (C= AESARS)=94 =96 http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf - NIST Interagency Report 7756 - CAESARS Framework Extension: An Enterprise= Continuous Monitoring Technical Reference Architecture (Draft) - http://cs= rc.nist.gov/publications/drafts/nistir-7756/Draft-NISTIR-7756_second-public= -draft.pdf - NIST Special Publication (SP) 800-137 - Information Security Continuous M= onitoring (ISCM) for Federal Information Systems and Organizations - http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf - NIST Interagency Report (IR) 7799 =96 Continuous Monitoring Reference Mod= el Workflow, Subsystem, and Interface Specifications (Draft) - http://csrc.= nist.gov/publications/drafts/nistir-7799/Draft-NISTIR-7799.pdf - NIST Interagency Report 7800 - Applying the Continuous Monitoring Technic= al Reference Model to the Asset, Configuration, and Vulnerability Managemen= t Domains (Draft) - http://csrc.nist.gov/publications/drafts/nistir-7800/Dr= aft-NISTIR-7800.pdf Thanks! Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CBD941F033378kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Al= l,

I know this= is a bit early but I want to give everyone time to prepare for the Continu= ous Monitoring (CM) sessions at SCAP Developer Days. If you are attending I= would encourage you to do a little homework before you come.  Let's m= ake sure we can have highly productive sessions around Continuous Monitorin= g.  The following documents are the basic background needed to make re= al progress in the F2F. CM efforts are going to leverage existing SCAP spec= ifications but will also need to have additional interfaces defin= ed to be able to appropriately implement CM Instances. If we are prepared t= hen as a group we can be much more productive and not leave anyone behind.<= /div>

Here is a list= of the CM related documents.

- DHS Federal Network Security (FNS) Branch - =94Co= ntinuous Ass= et Evaluation, Situational Awareness, and Risk Scoring Reference Architecture Report (CAESARS)=94 =96 http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf=

= - NIST Inter= agency Report 7756 - http://csrc.nist.gov/publications/drafts/= nistir-7756/Draft-NISTIR-7756_second-public-draft.pdf

- NIST Spec= ial Publication (SP) 800-137 - Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizati= ons - 

- NIST Interagency Report (IR) 7799 =96 Continuous Monitoring Refer= ence Model Workflow, Subsystem, and Interface Specifications (Draft) - http://csrc.nist.gov/publications/drafts/nistir-7799/Draft-NISTIR-= 7799.pdf

- NIST Interagency Report 7800 - Applying the Continuous Monitoring Technical Reference Model to the Asset, Configuration, and Vulnerability Management Domains (Draft) - http://csrc.nist.gov/p= ublications/drafts/nistir-7800/Draft-NISTIR-7800.pdf

Thanks!

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

McAfee | An Intel Co= mpany
50= 00 Headquarters Dr.


D= irect: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com
--_000_CBD941F033378kentlandfieldmcafeecom_-- From Kent_Landfield@mcafee.com Wed May 16 13:16: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 2CE0521F8665 for ; Wed, 16 May 2012 13:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngc7EC6KnLtM for ; Wed, 16 May 2012 13:16:15 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id C7B5921F865B for ; Wed, 16 May 2012 13:16:14 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 5ced_08d7_bc143378_d83d_4fbb_98d4_83b12770c79e; Wed, 16 May 2012 15:16:08 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 16 May 2012 15:16:02 -0500 From: To: , , Date: Wed, 16 May 2012 15:16:42 -0500 Thread-Topic: [scap-dev] Continuous Monitoring and SCAP Developer Days Thread-Index: Ac0zoLc2+7InCOBgSRKGpsLRJsAcYA== Message-ID: In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78B91@DUMFDPEXMB01.disanet.disa-u.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD974A833578kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] [scap-dev] Continuous Monitoring and SCAP Developer Days 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, 16 May 2012 20:16:16 -0000 --_000_CBD974A833578kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agreed and my understanding is they are reaching out as we speak. Not sure= about stump the dummy though=85 ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , JOSEPH L CIV DISA PEO-MA > To: "scap-dev@nist.gov" >, "sacm@ietf.org" > Subject: Re: [scap-dev] Continuous Monitoring and SCAP Developer Days Any chance the Dev Days sponsors could reach out to Dept State and/or Dept = Justice to discuss their current status and plans for the data they plan to= collect and the metrics/scoring techniques they plan to use to build capab= ilities for both continuous compliance monitoring and risk scoring? Seems like we would want to be able to play stump the dummy with the pionee= rs in the field. Figuring out how SCAP will support continuous monitoring should (I think) s= tart by understanding where continuous monitoring is evolving. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:s= cap-dev-bounces@nist.gov] On Behalf Of Kent_Landfield@mcafee.com Sent: Wednesday, May 16, 2012 4:02 PM To: scap-dev@nist.gov; sacm@ietf.org Subject: [scap-dev] Continuous Monitoring and SCAP Developer Days Hi All, I know this is a bit early but I want to give everyone time to prepare for = the Continuous Monitoring (CM) sessions at SCAP Developer Days. If you are = attending I would encourage you to do a little homework before you come. L= et's make sure we can have highly productive sessions around Continuous Mon= itoring. The following documents are the basic background needed to make r= eal progress in the F2F. CM efforts are going to leverage existing SCAP spe= cifications but will also need to have additional interfaces defined to be = able to appropriately implement CM Instances. If we are prepared then as a = group we can be much more productive and not leave anyone behind. Here is a list of the CM related documents. - DHS Federal Network Security (FNS) Branch - "Continuous Asset Evaluation,= Situational Awareness, and Risk Scoring Reference Architecture Report (CAE= SARS)" - http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf - NIST Interagency Report 7756 - CAESARS Framework Extension: An Enterprise= Continuous Monitoring Technical Reference Architecture (Draft) - http://cs= rc.nist.gov/publications/drafts/nistir-7756/Draft-NISTIR-7756_second-public= -draft.pdf - NIST Special Publication (SP) 800-137 - Information Security Continuous M= onitoring (ISCM) for Federal Information Systems and Organizations - http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf - NIST Interagency Report (IR) 7799 - Continuous Monitoring Reference Model= Workflow, Subsystem, and Interface Specifications (Draft) - http://csrc.ni= st.gov/publications/drafts/nistir-7799/Draft-NISTIR-7799.pdf - NIST Interagency Report 7800 - Applying the Continuous Monitoring Technic= al Reference Model to the Asset, Configuration, and Vulnerability Managemen= t Domains (Draft) - http://csrc.nist.gov/publications/drafts/nistir-7800/Dr= aft-NISTIR-7800.pdf Thanks! Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com --_000_CBD974A833578kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Agreed and = my understanding is they are reaching out as we speak.  Not sure about= stump the dummy though=85 ;-)

Kent Landfield=
Director Content= Strategy, Architecture and Standards

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

Direct: +1.972.963.7096 = ;
Mobile: +1.= 817.637.8026Web: www.mcafee.com
=
From: <WOLFKIEL&= gt;, JOSEPH L CIV DISA PEO-MA <joseph.wolfkiel@disa.mil>
To:= "scap-dev@nist.gov&q= uot; <scap-dev@nist.gov>, &q= uot;sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [scap-dev] Continuous Monitoring and SCAP Develo= per Days

Any chance the Dev Days sponsors could reach out t= o Dept State and/or Dept Justice to discuss their current status and plans = for the data they plan to collect and the metrics/scoring techniques they p= lan to use to build capabilities for both continuous compliance monitoring = and risk scoring?

Seems like we would want to be a= ble to play stump the dummy with the pioneers in the field.

<= /div>
Figuring out how SCAP will support continuous monitoring should (= I think) start by understanding where continuous monitoring is evolving.

Joseph L. Wolfkiel
Engineering Group Lead<= /div>
DISA PEO MA/IA52
(301) 225-8820

<= /div>

-----Original Message-----
Sent: Wednesday, May 16, 2012 4:02 PM
Subject: [scap-dev] Continu= ous Monitoring and SCAP Developer Days

Hi All,

I know this is a bit early but I want to give everyon= e time to prepare for the Continuous Monitoring (CM) sessions at SCAP Devel= oper Days. If you are attending I would encourage you to do a little homewo= rk before you come.  Let's make sure we can have highly productiv= e sessions around Continuous Monitoring.  The following documents= are the basic background needed to make real progress in the F2F. CM effor= ts are going to leverage existing SCAP specifications but will also need to= have additional interfaces defined to be able to appropriately implement C= M Instances. If we are prepared then as a group we can be much more product= ive and not leave anyone behind.

Here is a list of= the CM related documents.

- DHS Federal Network S= ecurity (FNS) Branch - "Continuous Asset Evaluation, Situational Aware= ness, and Risk Scoring Reference Architecture Report (CAESARS)" - http://www.dhs.g= ov/xlibrary/assets/fns-caesars.pdf


<= div>- NIST Interagency Report 7756 - CAESARS Framework Extension: An Enterp= rise Continuous Monitoring Technical Reference Architecture (Draft) - http://csrc.nist.gov/publications/drafts/nistir-= 7756/Draft-NISTIR-7756_second-public-draft.pdf


- NIST Special Publication (SP) 800-137 - Information Secur= ity Continuous Monitoring (ISCM) for Federal Information Systems and Organi= zations -


- NIST= Interagency Report (IR) 7799 - Continuous Monitoring Reference Model Workf= low, Subsystem, and Interface Specifications (Draft) - http://c= src.nist.gov/publications/drafts/nistir-7799/Draft-NISTIR-7799.pdf

- NIST Interagency Report 7800 - Applying the Continuo= us Monitoring Technical Reference Model to the Asset, Configuration, and Vu= lnerability Management Domains (Draft) - http://csrc.nist.gov/p= ublications/drafts/nistir-7800/Draft-NISTIR-7800.pdf


Thanks!


Kent = Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarte= rs Dr.
Plano, Texas 75024

Direct: +1= .972.963.7096
Mobile: +1.817.637.8026
Web: www.mca= fee.com <http://www.mcafee.com/&g= t;

--_000_CBD974A833578kentlandfieldmcafeecom_-- From anton.chuvakin@gmail.com Wed May 16 14:23:05 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 7D08C21F8758 for ; Wed, 16 May 2012 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu6HtkIv3jOY for ; Wed, 16 May 2012 14:23:04 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5133421F8753 for ; Wed, 16 May 2012 14:23:04 -0700 (PDT) Received: by bkty8 with SMTP id y8so1188284bkt.31 for ; Wed, 16 May 2012 14:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=imJdxRTjf7b3csS/cjCsamuhn+XBHhTuednArOOL/ZQ=; b=wL5ygPdYV15+H6NBOEhN89TY0gADPkSbbyLES4ozABJm0Xu8KGOTjxFeM5iaOSWdBa 8BbfGDhT+5C/LhQ/WRE1AJ/yc7ZhZp5LDezweVPR3pD4pkAMu5ITQADmBFYWiwphVLcT F8JW2G+0SoJ1F45z/M+wubRH0uT0j7H8XiJM65+NuiFwcMRGTnbJeb/gvrBhYljIA5pJ SwXwp8JEkCepOGNqZGpznpmpyXCuBnZZtaIg5nUgSgmUbQip/oyhwu+PGgyHWlkcV4w5 LW4uc+OXVvnhEEK/o9aMVQ/zknpxOEMb5ZnzWbxYf8av01PfApLJ5DJ8xmtbjN8YaGb4 hSIA== Received: by 10.204.130.89 with SMTP id r25mr1771530bks.48.1337203383167; Wed, 16 May 2012 14:23:03 -0700 (PDT) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.204.119.9 with HTTP; Wed, 16 May 2012 14:22:32 -0700 (PDT) In-Reply-To: References: From: Anton Chuvakin Date: Wed, 16 May 2012 14:22:32 -0700 X-Google-Sender-Auth: aI3jMAQ3cRca5j72pZnPkkAnSnY Message-ID: To: "Waltermire, David A." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated SACM Use Case Document 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, 16 May 2012 21:23:05 -0000 > I have posted an updated revision of the SACM Use Cases (link below).=A0 = I > have included notes based on the list discussion and outlined a few areas= to > consider in each of the use case sections.=A0 At this point I would like = to > get some help from a few of you as co-editors to work specific use cases = and > to assist with completing the remainder of the document.=A0 I would like = to > work on UC4 and can support editing everything together as needed. > Anyone else interested in working one or more of the use case sections? Happy to help with UC2 and maybe others. --=20 Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin From gunnar.engelbach@threatguard.com Thu May 17 10:08: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 AAE3721F86C6 for ; Thu, 17 May 2012 10:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.845 X-Spam-Level: X-Spam-Status: No, score=0.845 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3p9HbmZGKFn for ; Thu, 17 May 2012 10:08:39 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89321F86AB for ; Thu, 17 May 2012 10:08:39 -0700 (PDT) Received: (qmail 24978 invoked from network); 17 May 2012 11:11:56 -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); 17 May 2012 11:11:56 -0700 Message-ID: <4FB53096.3060703@ThreatGuard.com> Date: Thu, 17 May 2012 13:08:38 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: scap-dev@nist.gov, sacm@ietf.org References: <0C700A7ED1FE57488BB17782F397264B05F78B91@DUMFDPEXMB01.disanet.disa-u.mil> <0C700A7ED1FE57488BB17782F397264B05F78C41@DUMFDPEXMB01.disanet.disa-u.mil> <865EE34F8C9B2446874070EF2544657016156DCECA@TELOS20.Telos.Corp> <0C700A7ED1FE57488BB17782F397264B05F78D0A@DUMFDPEXMB01.disanet.disa-u.mil> In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78D0A@DUMFDPEXMB01.disanet.disa-u.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] [scap-dev] Finding Severity Assignments 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, 17 May 2012 17:08:40 -0000 An unreported/untested/mis-reported check is really not related to your actual exposure. Id est, a result of "not checked," "not reported," "error," etc, don't give you an indication of whether or not you have an actual exposure to attack or not, but they might be an indication of a procedural issue, content error, software error, and so on. The remediation for each is different, but folding all into a single score loses the information necessary to apply the proper remediation. And giving unreported checks a higher score means you might be spending limited resources dealing with exposures that you aren't actually susceptible to. At the same time an unreported result for a check whose exposure is minimal is also not the highest priority. So it sounds like what you're looking for is to preserve both the severity of the check along with the result. Then you have the information to decide if the solution is a technical fix vice an administrative action. --gun On 5/17/2012 12:13 PM, WOLFKIEL, JOSEPH L CIV DISA PEO-MA wrote: > Maybe a little rationale is required. > > First, CVSS is a type of "severity" measurement. It measures a relative risk of one vulnerability at a time. It doesn't apply across multiple vulnerabilities (i.e. comparing two patches that each remediate multiple vulnerabilities). It also doesn't apply to protective measures, for example the value of deploying or not deploying an AV or HIPS signature or of having a specific service active on a device. While CVSS is useful in assigning severities to individual vulnerabilities, it's not sufficient to build risk scores for all the types of data we need to quantify, measure, and score. > > Based on what I ~think~ we learned from Department of State, we have assigned different scoring methodologies to be applied to different data. > > The worst state we can possibly be in is ignorance, effectively "not checked" or "not reported" since we can't apply countermeasures if we don't know the state of a given vulnerability/configuration. Also, from a human perspective, we don't ever want to reward someone for withholding information, so I generally want to reserve the right to treat "not checked" or "not reported" as being worse than "fail." > > "error" and "fail" can be considered about the same, but (in known cases), some checks may return an "error" condition when run on a subset of endpoints that isn't directly related to the security of the configuration. In those cases, we'll want to assign different severities to "error" than to "fail." > > Finally, "fixed" is (I think) an attestation made by a human that they are overriding sensor data due to applying a non-supported remediation action. I'd like the flexibility to associate a different level of risk with human reported data versus sensor reported data. > > I suppose my question is really whether others agree that we need to preserve the ability to assign different risks per finding versus being rigidly forced to only be able to assign either a fixed severity or no severity at the rule level. > > Joseph L. Wolfkiel > Engineering Group Lead > DISA PEO MA/IA52 > (301) 225-8820 > Joseph.Wolfkiel@DISA.mil > > > -----Original Message----- > From: Wilson, David [mailto:David.Wilson@telos.com] > Sent: Thursday, May 17, 2012 9:40 AM > To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; scap-dev@nist.gov; sacm@ietf.org > Cc: Clingaman, Rodney J CTR DISA PEO-MA > Subject: RE: Finding Severity Assignments > > Joe, I may be missing the difference between what you're calling a severity and its relationship, or not, to other scores such as CVSS.... > At any rate, I like the latter: "severities should be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't." > In other words, your results of pass, N/A, and fixed should have no severity. > > David Wilson | Director of CyberSecurity Strategy > (703)726-2238 o | (571)274-9946 c > david.wilson@telos.com | twitter.com/djwils285 > > > -----Original Message----- > From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA > Sent: Thursday, May 17, 2012 8:35 AM > To: scap-dev@nist.gov; sacm@ietf.org > Cc: Clingaman, Rodney J CTR DISA PEO-MA > Subject: [scap-dev] Finding Severity Assignments > > Not sure where/how to broach this subject, but I was working with one of our developers yesterday and we were discussing the assignment of severities to findings to generate scores. > > The question is whether severities should be assigned to XCCDF rule IDs, or to the tuple of (ruleID, result). > > I'm currently of the mind that we'll have to track severities at the tuple level due to the ambiguity and potentially changing nature of how we allocate severities to findings. > > For example, a given rule (in XCCDF) can have results of pass, fail, not checked, error, not applicable, or fixed. > > We can assign a severity of "3" to a group that includes [fail, error], a severity of 4 to [not checked], 1 to "fixed", and 0 to [pass, not applicable]. > > Do we need this level of flexibility, or can/should severities be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't? > > As an aside, I've decided to call the "quantity" of "risk" or "added vulnerability" per finding a "severity", and call the sum of one or more severities allocated to an asset due to "findings" a "score." Not sure if that fits within standard terminology. Feel free to correct me if I got it wrong. > > Joseph L. Wolfkiel > Engineering Group Lead > DISA PEO MA/IA52 > (301) 225-8820 > Joseph.Wolfkiel@DISA.mil > > > > > > _______________________________________________ > scap-dev mailing list > scap-dev@nist.gov > To unsubscribe, send an email message to scap-dev-unsubscribe@nist.gov. From bfrantz@cisecurity.org Thu May 17 09:19: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 17A7521F862B for ; Thu, 17 May 2012 09:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR72kIXNebtV for ; Thu, 17 May 2012 09:19:51 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4428E21F85F0 for ; Thu, 17 May 2012 09:19:51 -0700 (PDT) X-Env-Sender: bfrantz@cisecurity.org X-Msg-Ref: server-3.tower-86.messagelabs.com!1337271589!41047181!1 X-Originating-IP: [69.195.43.86] X-StarScan-Version: 6.5.10; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 14426 invoked from network); 17 May 2012 16:19:49 -0000 Received: from mail.msisac.org (HELO Exchange.msisac.org.local) (69.195.43.86) by server-3.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 17 May 2012 16:19:49 -0000 Received: from EXCHANGE.msisac.org.local ([::1]) by Exchange.msisac.org.local ([::1]) with mapi id 14.01.0355.002; Thu, 17 May 2012 12:19:49 -0400 From: Blake Frantz To: "WOLFKIEL, JOSEPH L CIV DISA PEO-MA" , "scap-dev@nist.gov" , "sacm@ietf.org" Thread-Topic: Finding Severity Assignments Thread-Index: AQHNNCnmL8J58mIGlES69iemcblcjZbOE+CA Date: Thu, 17 May 2012 16:19:47 +0000 Message-ID: <37B94C562431DD4698C918992117B1F91D36DE9A@Exchange.msisac.org.local> References: <0C700A7ED1FE57488BB17782F397264B05F78B91@DUMFDPEXMB01.disanet.disa-u.mil> <0C700A7ED1FE57488BB17782F397264B05F78C41@DUMFDPEXMB01.disanet.disa-u.mil> In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78C41@DUMFDPEXMB01.disanet.disa-u.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.235.3.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 17 May 2012 10:10:50 -0700 Cc: "Clingaman, Rodney J CTR DISA PEO-MA" Subject: Re: [sacm] Finding Severity Assignments 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, 17 May 2012 16:19:52 -0000 It seems the Rule/@severity attribute may have some relationship to the Ru= le/@weight attribute. Is that true in your use case?=20 If we throw CCSS into the mix, the @weight attribute would be based on the= actual state found on the box, not necessarily the outcome of the Rule's = evaluation.=20 It's my understanding the SCAP 1.2 allows tools to override Rule/@weight a= t runtime with a dynamically selected CCSS rating. Perhaps a dynamically s= et @severity attribute makes some sense too.=20 Blake -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Beha= lf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 5:38 AM To: scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: [scap-dev] Finding Severity Assignments Not sure where/how to broach this subject, but I was working with one of o= ur developers yesterday and we were discussing the assignment of severitie= s to findings to generate scores. The question is whether severities should be assigned to XCCDF rule IDs, o= r to the tuple of (ruleID, result). I'm currently of the mind that we'll have to track severities at the tuple= level due to the ambiguity and potentially changing nature of how we allo= cate severities to findings. For example, a given rule (in XCCDF) can have results of pass, fail, not c= hecked, error, not applicable, or fixed. We can assign a severity of "3" to a group that includes [fail, error], a = severity of 4 to [not checked], 1 to "fixed", and 0 to [pass, not applicab= le]. Do we need this level of flexibility, or can/should severities be assigned= at the rule ID level and only two possible outcomes be possible where if = you fall in one group you get the severity added to your score and if you = fall in the other, you don't? As an aside, I've decided to call the "quantity" of "risk" or "added vulne= rability" per finding a "severity", and call the sum of one or more severi= ties allocated to an asset due to "findings" a "score." Not sure if that = fits within standard terminology. Feel free to correct me if I got it wro= ng. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil ... This message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is stric= tly prohibited. Please notify the sender immediately and permanently dele= te the message and any attachments. From m.kinne@radium.ncsc.mil Thu May 17 09:29: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 49BE121F8643 for ; Thu, 17 May 2012 09:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.633 X-Spam-Level: X-Spam-Status: No, score=-7.633 tagged_above=-999 required=5 tests=[AWL=-2.034, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1WlpqubVp3t for ; Thu, 17 May 2012 09:29:13 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 01F2B21F85E5 for ; Thu, 17 May 2012 09:29:12 -0700 (PDT) X-TM-IMSS-Message-ID: <80a4a30700118438@nsa.gov> Received: from MSCS-GH1-UEA01.corp.nsa.gov ([10.215.224.47]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 80a4a30700118438 ; Thu, 17 May 2012 12:30:35 -0400 Received: from MSIS-GH1-UEA10.corp.nsa.gov ([10.215.229.132]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 May 2012 12:29:02 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 17 May 2012 12:29:01 -0400 Message-ID: <15D0981C9BE53042A4C9D0F3D0B6826B29014D@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78D0A@DUMFDPEXMB01.disanet.disa-u.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scap-dev] Finding Severity Assignments Thread-Index: Ac0zoLc2+7InCOBgSRKGpsLRJsAcYAAhlsfAAAJ/7UAAA+HvIAACHCiw References: <0C700A7ED1FE57488BB17782F397264B05F78B91@DUMFDPEXMB01.disanet.disa-u.mil><0C700A7ED1FE57488BB17782F397264B05F78C41@DUMFDPEXMB01.disanet.disa-u.mil><865EE34F8C9B2446874070EF2544657016156DCECA@TELOS20.Telos.Corp> <0C700A7ED1FE57488BB17782F397264B05F78D0A@DUMFDPEXMB01.disanet.disa-u.mil> From: "Kinney, Michael A" To: "WOLFKIEL, JOSEPH L CIV DISA PEO-MA" , "Wilson, David" , , X-OriginalArrivalTime: 17 May 2012 16:29:02.0014 (UTC) FILETIME=[2B2BFDE0:01CD344A] X-Mailman-Approved-At: Thu, 17 May 2012 10:11:05 -0700 Cc: "Clingaman, Rodney J CTR DISA PEO-MA" Subject: Re: [sacm] [scap-dev] Finding Severity Assignments 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, 17 May 2012 16:29:14 -0000 Joe, Glad you mentioned configuration, Is DISA going to provide the DoD with CCSS scoring now that the Spec is final? Are you thinking we will we need a separate metric for patches instead of adding up the CVSS score for each? In the case where we decide to blacklist adobe while we are waiting for a patch would you score this differently because it was mitigated and then a different value once a patch was applied and adobe was no longer blacklisted? How diluted will each score become as we add different scoring mechanisms and how complex will this become? I think the Department Of State used a much simpler metric, unless I'm mistaken. v/r Mike Kinney Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov =20 -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 12:13 PM To: Wilson, David; scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: Re: [scap-dev] Finding Severity Assignments Maybe a little rationale is required. First, CVSS is a type of "severity" measurement. It measures a relative risk of one vulnerability at a time. It doesn't apply across multiple vulnerabilities (i.e. comparing two patches that each remediate multiple vulnerabilities). It also doesn't apply to protective measures, for example the value of deploying or not deploying an AV or HIPS signature or of having a specific service active on a device. While CVSS is useful in assigning severities to individual vulnerabilities, it's not sufficient to build risk scores for all the types of data we need to quantify, measure, and score. Based on what I ~think~ we learned from Department of State, we have assigned different scoring methodologies to be applied to different data. =20 The worst state we can possibly be in is ignorance, effectively "not checked" or "not reported" since we can't apply countermeasures if we don't know the state of a given vulnerability/configuration. Also, from a human perspective, we don't ever want to reward someone for withholding information, so I generally want to reserve the right to treat "not checked" or "not reported" as being worse than "fail." "error" and "fail" can be considered about the same, but (in known cases), some checks may return an "error" condition when run on a subset of endpoints that isn't directly related to the security of the configuration. In those cases, we'll want to assign different severities to "error" than to "fail." Finally, "fixed" is (I think) an attestation made by a human that they are overriding sensor data due to applying a non-supported remediation action. I'd like the flexibility to associate a different level of risk with human reported data versus sensor reported data. I suppose my question is really whether others agree that we need to preserve the ability to assign different risks per finding versus being rigidly forced to only be able to assign either a fixed severity or no severity at the rule level. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil -----Original Message----- From: Wilson, David [mailto:David.Wilson@telos.com]=20 Sent: Thursday, May 17, 2012 9:40 AM To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: RE: Finding Severity Assignments Joe, I may be missing the difference between what you're calling a severity and its relationship, or not, to other scores such as CVSS.... At any rate, I like the latter: "severities should be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't." In other words, your results of pass, N/A, and fixed should have no severity. David Wilson | Director of CyberSecurity Strategy=20 (703)726-2238 o | (571)274-9946 c david.wilson@telos.com | twitter.com/djwils285 -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 8:35 AM To: scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: [scap-dev] Finding Severity Assignments Not sure where/how to broach this subject, but I was working with one of our developers yesterday and we were discussing the assignment of severities to findings to generate scores. The question is whether severities should be assigned to XCCDF rule IDs, or to the tuple of (ruleID, result). I'm currently of the mind that we'll have to track severities at the tuple level due to the ambiguity and potentially changing nature of how we allocate severities to findings. For example, a given rule (in XCCDF) can have results of pass, fail, not checked, error, not applicable, or fixed. We can assign a severity of "3" to a group that includes [fail, error], a severity of 4 to [not checked], 1 to "fixed", and 0 to [pass, not applicable]. Do we need this level of flexibility, or can/should severities be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't? As an aside, I've decided to call the "quantity" of "risk" or "added vulnerability" per finding a "severity", and call the sum of one or more severities allocated to an asset due to "findings" a "score." Not sure if that fits within standard terminology. Feel free to correct me if I got it wrong. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil From j.ronayn@radium.ncsc.mil Thu May 17 10:37: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 CDCE021F870E for ; Thu, 17 May 2012 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLdu0IXOkXMY for ; Thu, 17 May 2012 10:37:17 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id A1B0C21F8701 for ; Thu, 17 May 2012 10:37:17 -0700 (PDT) X-TM-IMSS-Message-ID: <5d2b35d900121a53@nsa.gov> Received: from MSCS-GH1-UEA01.corp.nsa.gov ([10.215.224.47]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 5d2b35d900121a53 ; Thu, 17 May 2012 13:37:11 -0400 Received: from MSIS-GH1-UEA10.corp.nsa.gov ([10.215.229.132]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 May 2012 13:37:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 17 May 2012 13:37:15 -0400 Message-ID: In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78D22@DUMFDPEXMB01.disanet.disa-u.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scap-dev] Finding Severity Assignments Thread-Index: AQHNNCnmL8J58mIGlES69iemcblcjZbOE+CAgAAZ/qCAAAWFwA== References: <0C700A7ED1FE57488BB17782F397264B05F78B91@DUMFDPEXMB01.disanet.disa-u.mil><0C700A7ED1FE57488BB17782F397264B05F78C41@DUMFDPEXMB01.disanet.disa-u.mil><37B94C562431DD4698C918992117B1F91D36DE9A@Exchange.msisac.org.local> <0C700A7ED1FE57488BB17782F397264B05F78D22@DUMFDPEXMB01.disanet.disa-u.mil> From: "Ronayne, James K." To: "WOLFKIEL, JOSEPH L CIV DISA PEO-MA" , "Blake Frantz" , , X-OriginalArrivalTime: 17 May 2012 17:37:16.0149 (UTC) FILETIME=[B3776A50:01CD3453] Cc: "Clingaman, Rodney J CTR DISA PEO-MA" Subject: Re: [sacm] [scap-dev] Finding Severity Assignments 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, 17 May 2012 17:37:18 -0000 This is a custom scoring system. What you described seems completely valid (although I think you might want the result score to be a multiplier on the CVSS/CCSS value - not reported might be worth 1.1*value, fixed 0.2*value). I think the question is how the standards relate to custom scoring systems. You could define your scoring system as an extension to XCCDF. At various times we have also considered removing scoring from XCCDF altogether or at least making it possible to not include scores in results. In general I agree we would prefer our scoring data to be handled separate from our results data. Do we need a means to, in a standard way, communicate details of a scoring system? Will this become more important as continuous monitoring becomes more common? These details might include both values or modifiers for each item and a formula for combining items. We already have feeds for things like CVE-CVSS. We would still need feeds to describe how to modify and combine those scores for a given set of rules. The simplest form of this would be the scoring system descriptions that are already part of XCCDF. Do we expect a results consumer to also consume standard scoring data and present results? The alternative is to implement proprietary scoring schemes based on standards data where possible. On a somewhat related note - we will probably have to do something about scoring in XCCDF when we start using OCIL more. Today an OCIL result of NOT TESTED gets translated to an XCCDF result of NOT CHECKED. NOT CHECKED results are not included in any of the existing scoring system calculations. That made sense with OVAL but I don't think it works for OCIL. Jim -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 12:51 PM To: Blake Frantz; scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: Re: [scap-dev] Finding Severity Assignments In general, I don't see our scoring as being directly linked to XCCDF content. The concept is similar, but scoring will take place in a central location and may address other attributes, to include network zone, mission affiliation, threat environment, etc that will be calculated and scored at report generation time versus assessment runtime. We also have tentative requirements to generate results against multiple scoring systems for the same finding (i.e. local DAA versus US Cyber versus Fed Gov), so I generally resist using any severities that are hard-coded into SCAP content. We're currently using the DISA FSO-assigned "CAT" score as the basis for STIG severities, which may or may not have any correlation to what's in the FDCC/USGCB content. I should also note that we're scoring a lot of data that isn't the result of SCAP content (AV and HIPS .dat file dates, required software compliance) and have plans to score others (blacklisted software, port & protocol usage, HIPS policy application, Data Loss Prevention policy compliance, running services, WAP policy compliance, etc.). In this space, I want to use the same methodology across the board, whether the data originated from SCAP or not.=20 Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil -----Original Message----- From: Blake Frantz [mailto:bfrantz@cisecurity.org]=20 Sent: Thursday, May 17, 2012 12:20 PM To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: RE: Finding Severity Assignments It seems the Rule/@severity attribute may have some relationship to the Rule/@weight attribute. Is that true in your use case?=20 If we throw CCSS into the mix, the @weight attribute would be based on the actual state found on the box, not necessarily the outcome of the Rule's evaluation.=20 It's my understanding the SCAP 1.2 allows tools to override Rule/@weight at runtime with a dynamically selected CCSS rating. Perhaps a dynamically set @severity attribute makes some sense too.=20 Blake -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 5:38 AM To: scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: [scap-dev] Finding Severity Assignments Not sure where/how to broach this subject, but I was working with one of our developers yesterday and we were discussing the assignment of severities to findings to generate scores. The question is whether severities should be assigned to XCCDF rule IDs, or to the tuple of (ruleID, result). I'm currently of the mind that we'll have to track severities at the tuple level due to the ambiguity and potentially changing nature of how we allocate severities to findings. For example, a given rule (in XCCDF) can have results of pass, fail, not checked, error, not applicable, or fixed. We can assign a severity of "3" to a group that includes [fail, error], a severity of 4 to [not checked], 1 to "fixed", and 0 to [pass, not applicable]. Do we need this level of flexibility, or can/should severities be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't? As an aside, I've decided to call the "quantity" of "risk" or "added vulnerability" per finding a "severity", and call the sum of one or more severities allocated to an asset due to "findings" a "score." Not sure if that fits within standard terminology. Feel free to correct me if I got it wrong. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. From pkampana@cisco.com Thu May 17 15:31: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 37AF721F87F7 for ; Thu, 17 May 2012 15:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubmaep-WqIf3 for ; Thu, 17 May 2012 15:30:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E036B21F87E7 for ; Thu, 17 May 2012 15:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=88817; q=dns/txt; s=iport; t=1337293856; x=1338503456; h=from:to:references:in-reply-to:subject:date:message-id: mime-version; bh=wpxNu4F7e51ILcwkM6MUYeaKMplpHsmNDsoylqjUfmw=; b=gMHJE2/+CmQVn4B8aD8kKXO8JDfDLLcWPob5TTZF/wIyL0/BhkS3czkW bIyXn1xhez5j37efBhUNW5HFz7ZIWAHbDvmLXYLHS5A1rmKVR2mLr0qpC xekseXeO1vIQsEka7+Lk55Ex6v7nlAgm7KKRzHQq41ZgYcQ1NzC3CRuul s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwFAJR6tU+tJV2Y/2dsb2JhbAA6BwOCRaBghnYBiTCBB4IVAQEBBAECBQoBBwEPAxwFBhQLEwECAgkHCAIBAgEBASEBBgcWAwINCRUDBggBAQQBBwsJAgkHAgQBh2wLnBKgBASLAA8EghCDKAONaIVKgzmNJYFkgwWBOgk X-IronPort-AV: E=Sophos;i="4.75,612,1330905600"; d="scan'208,217";a="84257687" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 17 May 2012 22:30:52 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4HMUq7H027044; Thu, 17 May 2012 22:30:52 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 17:30:51 -0500 Received: from WIN-ICH1QO6NCS6 ([64.102.220.177]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 17:30:51 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Thu, 17 May 2012 18:29:51 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Thu, 17 May 2012 18:29:51 -0500 From: "Panos Kampanakis" To: "'Waltermire, David A.'" , "SCAP-DEV" , References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> In-Reply-To: Date: Thu, 17 May 2012 18:29:48 -0400 Organization: Cisco Systems Inc. Message-ID: <015d01cd347c$921ebf10$b65c3d30$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQAArCrAAQEd+jAAN3anYA== Content-Type: multipart/alternative; boundary="----=_NextPart_000_015E_01CD345B.0B0D1F10" Content-Language: en-us X-OriginalArrivalTime: 17 May 2012 22:30:51.0939 (UTC) FILETIME=[B74BA730:01CD347C] Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 17 May 2012 22:31:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_015E_01CD345B.0B0D1F10 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Good starting point Dave. =20 2 thoughts:=20 =20 - Integrity and Confidentiality can certainly be addressed in this spec. = But XML has its own mechanisms to provide them. Thus the content itself can provide Integrity and Confidentiality. I am not sure if the spec should = have Integrity and Confidentiality as required features. =20 - Also, should the data Exchange mechanism be part of this draft? For example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP, REST = as were suggested in SACM's alias before? =20 Rgs, Panos =20 =20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, May 16, 2012 3:39 PM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specification Development =20 I just posted a skeleton I/D on this topic. I have included an initial section that focuses on identifying the overall problem space relating = to content repositories. I'd appreciate any comments. =20 Here is the draft: http://www.ietf.org/id/draft-waltermire-content-repository-00.txt =20 Sincerely, Dave =20 From: Waltermire, David A.=20 Sent: Friday, May 11, 2012 1:13 PM To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV; sacm@ietf.org Subject: RE: Request for participants - Content Repository Specification Development =20 Kent, =20 I have already started work on a draft specification in this area. My = hope is that this work could be used as an initial draft within SACM at the appropriate time. Count me in. =20 I mostly agree with what you are describing below. The only area I = disagree with is in regards to federation. If we do not implement the = specification for an organizational repository in the right way, we may need to make = major changes to support federation. This is not good for anyone. In my mind these two concepts cannot be decoupled. We need to insure that any work towards supporting an organizational repository provides a foundation = for supporting a federated repository network. Imagine if DNS was designed = with a single organization mindset first without thinking about federation. = Top Level Domains (TLDs) and subdomains would not likely exist as concepts. = An individual DNS server would likely not support caching, time-to-live and delegating capabilities that are necessary for federation to happen. = All of these things would need to be retrofitted. To prevent this, we need to address the building blocks of federation in the basic design. =20 Sincerely, Dave =20 From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]=20 Sent: Friday, May 11, 2012 12:36 PM To: m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; = sacm@ietf.org Subject: Request for participants - Content Repository Specification Development =20 Mike I love it when you tee something up like that.. ;-) Thank you. ;) =20 Mike wrote:=20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful = for everyone. We need to talk more. =20 If you are talking about a holistic, complete federated approach to a content repository, I some what agree. If you are talking about an organizational repository, I totally disagree. But you knew I would. ;) =20 Here is how I see the problem. There is an immediate need for SCAP and other related content to be served up inside an organization. Today we = have situation where the standards allow us to provide sites the capability = to have a single SCAP implemented policy they call official for their environment. Yes this is a rather simplistic since there are things such = as targeting specific platforms, specific operational use needs, but for = now lets agree SCAP is a massive improvement over the proprietary situations = of the past. While we have created this standard content so that sites can implement their local site security once and then assure they are = measuring all appropriately targeted devices the same way, we have failed to = support the operational needs of the sites. We have a situation where no two vendors distribute content the same way. This causes massive problems = for the administration staff when they need to incorporate a new SCAP = enabled product into their architecture. They need to discover how the new = product supports distributing SCAP content to it's various components. If they = have one product then they do this one and they are done. If they have = multiple products they will have to figure out how to minimize the impact by incorporating the update process for the new product into the existing = SCAP security content processes. Now when the inevitable happens and the site staff needs to make a change to their security policy, they have to make = the modifications to the benchmark or checks or both and then distribute = those updates across their network. For each SCAP enabled product they have = in place, they have doubled, tripled or more the work needed to make those updates available.=20 =20 There is another content repository problem and that is the Federated Content Distribution. If you think global DNS you have a general frame = of reference. The guidance authors need to be able to publish content in = an authoritative manner so their content is updated in a timely fashion. = This is a much harder problem to solve if there is no local organizational infrastructure to support it. ;) =20 So here is what I am thinking. We should consider addressing these as = two separate but integrated efforts. I believe the Organizational Content Repository is the more critical piece that is actually easier to = address. The Federated Content Distribution should be a subsequent effort = integrating / augmenting the Organizational repository specification.=20 =20 Mike, to your point that we need someone to build one first. That has happened already. I have one as do other vendors but what we don't have = is the access specification. Ours are focused on our specific product = needs. Additionally there is a company that has developed a commercial SCAP = content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I = was very impressed. Again, to your point, it has been done. What is needed = to address the initial operational problem is to develop a specification = that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site. =20 =20 TO THAT END.. =20 I am requesting participation from those in the community that see the = need and want to put in the work to make this specification happen. I have talked to a couple of you but I do not want to assume your = participation. If you are interested please contact me so we can get this started.=20 =20 Thanks! =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Michael A To: David Waltermire , SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Dave, I have no problem with webinars, I do want to keep developer days = actionable and use it to make decisions, and vote and accomplish things good or = bad. I do not want this to be an informational briefing conference. Thanks for the links. =20 I still think that any specification for a repository is wishful = thinking until someone builds one and learns the lessons it will just be another whitepaper spec. I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful = for everyone. We need to talk more. =20 -Mike =20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 Regarding content management, we are building the prototype content repository for use in a production environment. As an open source = project, it will be free for use by anyone interested. My thinking is that this project can bridge the gap until commercial solutions are available to augment it. This is a similar path that was followed with DNS (bind) = and HTTP (apache). When it is ready for use, I am hoping to use it to host USGCB content. You would be welcome to use it for your needs. =20 It is good that OCIL is moving forward. This is an important piece of supporting risk management and aspects of continuous monitoring. I = would also like to see some discussion on OCIL at Developer Days. With the proposals we will likely have a sense of what needs to be discussed and = what we can achieve consensus on outside the meeting. =20 Remediation is a topic near and dear to my heart. I too would like to = see it move forward. =20 We just published the draft ASR specification for public comment. This specification supports enterprise aggregate reporting which greatly = reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR. = It can be used in continuous monitoring applications to support aggregate = data reporting needs (e.g. FISMA reporting, CyberScope). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are = still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred. As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF. = These are good and necessary discussions to have now, but we have a good deal = of work to do before we are ready to open up XCCDF. My suggestion is to = work on these related areas and then work up change proposals for XCCDF as needed. By that time we should be ready to work on a new revision of = XCCDF. =20 I am also looking forward to the discussions at the conference. It has = been too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]=20 Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 It's good to read your thoughts, and a realistic actionable approach is indeed needed. Since all the activity hasn't been on the lists a brief = 1=AE2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. =20 We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification = is today. I've been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is = a tough problem and will require funding with a tail, I'm not sure a specification will solve that problem. =20 We (DoD) have been putting a lot of effort into OCIL over the last year trying to make it useful in an enterprise environment and will be = posting our ideas to the list before developer days it should have already = started, we need to get consensus and a vote on how the community wishes to = proceed. =20 Remediation is stalled but I'm making every effort to get it kick = started from our perspective. I hope to assist in getting the draft ERI finished this year. We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can = do some automatic configuration fixes, part of a self healing network = concept. It is just a start but the best we can do at this point. =20 Enterprise reporting is an interesting subject, since XML adds size to = and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject. =20 I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to = wait. I didn't think that a move to internationalization should impede efforts = to move forward with use cases. =20 I look forward to talking with you at the conference. =20 v/r =20 Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov =20 =20 =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Kent, =20 I like what you are saying here. We are also in support of this type of approach. We would like to see some community discussion around what = are the key areas/priorities that the community would like to see discussed = at Dev Days. Your topics below look like a good start. The SACM list might = be a better venue than the OVAL list for this discussion. For each area we should focus the discussion around developing objectives for each = session. The sessions can be time boxed based on what would be a reasonable = amount of time to accomplish each objective. For example if continuous monitoring = is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that. We can also keep a few sessions = "on deck" if all the objectives are reached and we complete all the = scheduled sessions early. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 All, =20 I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. =20 I see this appears to follow a path we have discussed in the past as the = way not to hold a Dev Days event. We have been trying to get away from = 'Death by Powerpoint' and back to the type of event we held years ago when we = were highly productive. In the past we had a topic to be discussed and a = time box to work within. That allowed us to have very active brainstorming sessions in a high bandwidth environment. =20 At past Summer events we have got into a pattern of lots of powerpoint, = lots of status of the efforts and very little discussion about things that = need active discussions. We need to keep moving forward and making progress = as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. We = have a limited amount of time and all who are attending are investing a great = deal of time and money to be there. We should not be spending a great deal = of time reeducating everyone when we could be focused on advancing needed efforts. =20 The type of approach to a Dev Days event was discussed at the last = Summer Dev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in advance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas that need real work by the community 4. Efforts to be discussed should be based on needs of the security automation space to move existing efforts to completion. For example: =20 Continuous monitoring is a major direction the efforts are becoming = involved with. There are going to be things we need to do as a security = automation community to be able to accomplish what is listed in the CAESARS FE. = There are interfaces that need to be worked and established. That is one area that is not listed below. CM will have a major impact on all of us in = the next couple years and it is being ignored. We can't keep trying to = solve what has already been solved. We need to address the needed interface development now. This is an effort that could take nearly a whole day by itself. =20 Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +.) without the = site staff having to go to each of the individual products and figuring out = how to inject that new or updated policy into that products delivery = mechanisms. That is limiting sites from wanting to buy multiple focused SCAP = products since they are such a pain to manage from a content perspective. It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having = multiple SCAP products presents. We need to have at least an entire 1/2 a day on = the development of a Content Repository specification. =20 OCIL is a positive and a negative at the same time. It has real value = that is being underutilized and under implemented because of the limitations = of how it addresses uses in an enterprise environment. People don't need security automation to do things on/for a single host. They need = security automation to focus on the enterprise issues that reduce their costs and improve their efficiencies. OCIL is failing in the enterprise and we = all understand that. We need to address developing a definitive solution = for incorporating OCIL into the enterprise and that means into the existing specifications. Scheduling and tracking are key to it's success. We = need to make that happen. This too needs a focused brainstorming time box to discuss options. =20 I am really disappointed that Remediation is not on the list below. = Yes, last Summer Dev Days, the time spent on Remediation was wasted time but = that does not mean we should ignore it and not try to make some real = progress. As far as I am concerned we need to reboot the remediation effort. We cannot keep being the set of specifications / tools that act as the = little boy crying "Wolf" in the night. We need to be able to find and fix = issues if we are going to really make a difference in organizational security postures. But today we think it is too hard so we don't try ? I think = we need a couple hours to discuss the reboot of the effort even if that = means minimizing work already done. =20 A focused discussion on enterprise reporting is also critically needed. = For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of = the Federal Agencies. The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of thrashing = to put a kludgey 'solution' in place. Reality is all our customers need = roll up reporting and an infrastructure that supports it. A data call should = not be special to anyone other than the agencies responding. The tools = should be able to select the types of data needed and deliver that on a scheduled basis automatically. Enterprise Reporting pertains to commercial as = well as Federal customers. We need to focus some time on what that would = look like using the ARF and ASR as the foundational pieces. But there are missing pieces.. We need this discussed. =20 I would hope we can make this summer's SCAP Dev Days useful in advancing = the security automation efforts by addressing some of the more critical = issues our customers are facing now or will be facing in the very short term. Status presentations are not interesting to those active in the efforts. Let's try to do those before we get to Bedford so we can real make some progress while we are all in the same room. This is always a big event = for the 'consensus of the willing' that assemble and driven to see security automation make a difference. Let's see if we can have an event that, = when we all walk out the last day, we all feel that every minute was well = spent and moves us forward. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Frank; =20 We hope to have the registration site up next week. The event will be during the week of July 9 - starting Monday at 10:00 AM and ending on = Friday at 12:00. =20 Meanwhile, we are working on the agenda and are currently considering = this list of topics: =20 CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker _____ =20 From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 =20 This year's MITRE-hosted Security Automation Developer Days event will = be held during the week of July 9, 2012 at MITRE's facility in Bedford, MA. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 ------=_NextPart_000_015E_01CD345B.0B0D1F10 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Good starting point = Dave.

 

2 thoughts: =

 

- Integrity and = Confidentiality can certainly be addressed in this spec. But XML = has its own mechanisms to provide them. Thus the content itself can = provide Integrity and Confidentiality. I am not sure if the spec should = have Integrity and Confidentiality as required = features.

 

- Also, should the data = Exchange mechanism be part of this draft? For example HTTP/TLS messages = etc (as in MILE’s rfc6546) or JSON, SOAP, REST as were suggested = in SACM’s alias before?

 

Rgs,

Panos

 

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Waltermire, David A.
Sent: Wednesday, May 16, 2012 3:39 = PM
To: SCAP-DEV; sacm@ietf.org
Subject: Re: [sacm] = Request for participants - Content Repository Specification = Development

 

I just posted a skeleton I/D on this = topic.  I have included an initial section that focuses on = identifying the overall problem space relating to content = repositories.  I’d appreciate any = comments.

 

Here is the = draft:

http://www.ietf.org/id/draft-waltermire-content-repository-00.txt

 

Sincerely,

Dave

 

From:= = Waltermire, David A.
Sent: Friday, May 11, 2012 1:13 = PM
To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; = SCAP-DEV; sacm@ietf.org
Subject: RE: = Request for participants - Content Repository Specification = Development

 

Kent,

 

I have already started = work on a draft specification in this area.  My hope is that this = work could be used as an initial draft within SACM at the appropriate = time.  Count me in.

 

I mostly agree with what = you are describing below.  The only area I disagree with is in = regards to federation.  If we do not implement the specification = for an organizational repository in the right way, we may need to make = major changes to support federation.  This is not good for = anyone.  In my mind these two concepts cannot be decoupled.  = We need to insure that any work towards supporting an organizational = repository provides a foundation for supporting a federated repository = network.  Imagine if DNS was designed with a single organization = mindset first without thinking about federation.  Top Level Domains = (TLDs) and subdomains would not likely exist as concepts.  An = individual DNS server would likely not support caching, time-to-live and = delegating capabilities that are necessary for federation to happen. =  All of these things would need to be retrofitted.  To prevent = this, we need to address the building blocks of federation in the basic = design.

 

Sincerely,

Dave

 

From:= = Kent_Landfield@McAfee.com = [mailto:Kent_Landfield= @McAfee.com]
Sent: Friday, May 11, 2012 12:36 = PM
To: m.kinne@radium.ncsc.mil; = Waltermire, David A.; SCAP-DEV; sacm@ietf.org
Subject: = Request for participants - Content Repository Specification = Development

 

Mike I love it when you = tee something up like that…. ;-)  Thank you. = ;)

 

Mike = wrote: 

I still think that any = specification for a repository is wishful thinking until someone builds = one and learns the lessons it will just be another whitepaper spec. =  I believe the DoD needs to incorporate a metadata repository as = part of it and other customizations that may not be useful for = everyone.

We need to talk = more…

 

If you are talking about a = holistic, complete federated approach to a content repository, I some = what agree.  If you are talking about an organizational repository, = I totally disagree. But you knew I would. ;)

 

Here is how I see the = problem.  There is an immediate need for SCAP and other related = content to be served up inside an organization.  Today we have = situation where the standards allow us to provide sites the capability = to have a single SCAP implemented policy they call official for their = environment. Yes this is a rather simplistic since there are things such = as targeting specific platforms, specific operational use needs, but for = now lets agree SCAP is a massive improvement over the proprietary = situations of the past. While we have created this standard content so = that sites can implement their local site security once and then assure = they are measuring all appropriately targeted devices the same way, we = have failed to support the operational needs of the sites.  We have = a situation where no two vendors distribute content the same way. =  This causes massive problems for the administration staff when = they need to incorporate a new SCAP enabled product into their = architecture.  They need to discover how the new product supports = distributing SCAP content to it's various components.  If they have = one product then they do this one and they are done.  If they have = multiple products they will have to figure out how to minimize the = impact by incorporating the update process for the new product into the = existing SCAP security content processes. Now when the inevitable = happens and the site staff needs to make a change to their security = policy, they have to make the modifications to the benchmark or checks = or both and then distribute those updates across their network. =  For each SCAP enabled product they have in place, they have = doubled, tripled or more the work needed to make those updates = available. 

 

There is another content = repository problem and that is the Federated Content Distribution. =  If you think global DNS you have a general frame of reference. =  The guidance authors need to be able to publish content in an = authoritative manner so their content is updated in a timely fashion. =  This is a much harder problem to solve if there is no local = organizational infrastructure to support it. ;)

 

So here is what I am = thinking…  We should consider addressing these as two = separate but integrated efforts.  I believe the Organizational = Content Repository is the more critical piece that is actually easier to = address.  The Federated Content Distribution should be a subsequent = effort integrating / augmenting the Organizational repository = specification. 

 

Mike, to your point that = we need someone to build one first… That has happened already. =  I have one as do other vendors but what we don’t have is the = access specification.  Ours are focused on our specific product = needs.  Additionally there is a company that has developed a = commercial SCAP content repository that will be announced later this = month. I won't steal their thunder but I was recently given a sneak peek = at it and I must admit I was very impressed.  Again, to your point, = it has been done. What is needed to address the initial operational = problem is to develop a specification that provides a consistent means = for all SCAP products to retrieve the appropriate content as configured = and managed but the site.  

 

TO THAT = END….

 

I am requesting = participation from those in the community that see the need and want to = put in the work to make this specification happen.  I have talked = to a couple of you but I do not want to assume your participation. =  If you are interested please contact me so we can get this = started. 

 

Thanks!

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

=

 

From: = <Kinney>, Michael A <m.kinne@radium.ncsc.mil>To: David Waltermire <david.waltermire@nist.gov&g= t;, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: = Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA

 

Dave,

I have no problem with webinars, I do want to = keep developer days actionable and use it to make decisions, and vote = and accomplish things good or bad.  I do not want this to be an = informational briefing conference.

Thanks for the links.

 

I still think that any specification for a = repository is wishful thinking until someone builds one and learns the = lessons it will just be another whitepaper spec.  I believe the DoD = needs to incorporate a metadata repository as part of it and other = customizations that may not be useful for everyone.

We need to talk more…

 

-Mike 

 

= From:= Waltermire, David A. [mailto:david.waltermire@nist.go= v]
Sent: Tuesday, May 08, 2012 10:44 AM
To: = Kinney, Michael A; SCAP-DEV; sacm@ietf.org
Subject: RE: = [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at = MITRE in Bedford, MA

 

Mike,

 

What about having webinars in-place of the 30 = minute briefs?

 

Regarding content management, we are building = the prototype content repository for use in a production = environment.  As an open source project, it will be free for use by = anyone interested.  My thinking is that this project can bridge the = gap until commercial solutions are available to augment it.  This = is a similar path that was followed with DNS (bind) and HTTP = (apache).  When it is ready for use, I am hoping to use it to host = USGCB content.  You would be welcome to use it for your = needs.

 

It is good that OCIL is moving forward.  = This is an important piece of supporting risk management and aspects of = continuous monitoring.  I would also like to see some discussion on = OCIL at Developer Days.  With the proposals we will likely have a = sense of what needs to be discussed and what we can achieve consensus on = outside the meeting.

 

Remediation is a topic near and dear to my = heart.  I too would like to see it move forward.

 

We just published the draft ASR specification = for public comment.  This specification supports enterprise = aggregate reporting which greatly reduces the data volumes needed verses = detailed host-based reports. This specification has been designed as a = more robust replacement for LASR.  It can be used in continuous = monitoring applications to support aggregate data reporting needs (e.g. = FISMA reporting,  CyberScope).

 

Here are the links:

 

http://csrc.ni= st.gov/publications/PubsDrafts.html

= http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

 

The primary reason we have suggested waiting on = XCCDF is not the internationalization issue. Many vendors have commented = that they are still working on implementing the XCCDF 1.2.1 = specification. We will be in a better place in a few months once more = development around XCCDF has occurred.  As we consider changes to = the SCAP stack to address OCIL and other issues, we will identify areas = that need improvement in XCCDF.  These are good and necessary = discussions to have now, but we have a good deal of work to do before we = are ready to open up XCCDF.  My suggestion is to work on these = related areas and then work up change proposals for XCCDF as = needed.  By that time we should be ready to work on a new revision = of XCCDF.

 

I am also looking forward to the discussions at = the conference.  It has been too long.

 

Sincerely,

Dave

 

 

Kent,

 

It’s good to read your thoughts, and a = realistic actionable approach is indeed needed.  Since all the = activity hasn’t been on the lists a brief 1=AE2 hour recap may be = in order to bring everyone up to speed since there has been a lot of = activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

 

We could write a content repository = specification, but without someone willing to stand one up it will be as = valuable as the CCSS specification is today.  I’ve been = trying for two years to get my management to get a coordinated effort = together for the DoD to stand up a repository, it is a tough problem and = will require funding with a tail, I’m not sure a specification = will solve that problem.

 

We (DoD) have been putting a lot of effort into = OCIL over the last year trying to make it useful in an enterprise = environment and will be posting our ideas to the list before developer = days it should have already started, we need to get consensus and a vote = on how the community wishes to proceed.

 

Remediation is stalled but I’m making = every effort to get it kick started from our perspective. I hope to = assist in getting the draft ERI finished this year.  We are writing = some new STIG content and intend to used the draft CRE specification to = insert CRE into the content so we (DoD) can do some automatic = configuration fixes, part of a self healing network concept. It is just = a start but the best we can do at this point.

 

Enterprise reporting is an interesting subject, = since XML adds size to and content to roll up reporting, in any = enterprise of size the problem gets greater, I look forward to your = thoughts on that subject.

 

I am concerned that the internationalization = efforts are detracting from efforts to meet use cases, we have some = things we would like changed in XCCDF to support our OCIl use case and I = have been told that I need to wait. I didn’t think that a move to = internationalization should impede efforts to move forward with use = cases.

 

I look forward to talking with you at the = conference.

 

v/r

 

Mike Kinney

Project Director

Computer Network Defense Research and Technology (CND R&T) = Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: = 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A.
Sent: Monday, May = 07, 2012 7:09 PM
To: Multiple recipients of = list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation = Developer Days: Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

I like what you are saying here.  We are = also in support of this type of approach.  We would like to see = some community discussion around what are the key areas/priorities that = the community would like to see discussed at Dev Days.  Your topics = below look like a good start. The SACM list might be a better venue than = the OVAL list for this discussion.  For each area we should focus = the discussion around developing objectives for each session.  The = sessions can be time boxed based on what would be a reasonable amount of = time to accomplish each objective.  For example if continuous = monitoring is a priority and collectively it takes 3 days to work = through all the objectives, I see no problem with that.  We can = also keep a few sessions “on deck” if all the objectives are = reached and we complete all the scheduled sessions early.

 

Thoughts?

 

Sincerely,

 

David = Waltermire

SCAP = Architect

National Institute of = Standards and Technology

(301) 975-3390

david.waltermire@nist.gov

 

= From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.comSent: Monday, May 07, 2012 4:25 PM
To: = SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

All,

 

I would like to discuss = the format for the SCAP Developer Days that seems to be listed = below.

 

I see this appears to = follow a path we have discussed in the past as the way not to hold a Dev = Days event.  We have been trying to get away from 'Death by = Powerpoint' and back to the type of event we held years ago when we were = highly productive.  In the past we had a topic to be discussed and = a time box to work within.  That allowed us to have very active = brainstorming sessions in a high bandwidth = environment.

 

At past Summer events we = have got into a pattern of lots of powerpoint, lots of status of the = efforts and very little discussion about things that need active = discussions.  We need to keep moving forward and making progress as = an effort. We can get status from various places such as the lists, a = presentation being sent out in advance, a webinar if it is felt there = will be questions and answers from those that are new to the efforts. =  We have a limited amount of time and all who are attending are = investing a great deal of time and money to be there.  We should = not  be spending a great deal of time reeducating everyone when we = could be focused on advancing needed = efforts.

 

The type of approach to a = Dev Days event was discussed at the last Summer Dev Days.  I have = seen the following work quite well in other = efforts.

  1. Presentations are sent out to the attendees and = the lists a week in advance.
  2. Status for any effort is limited to 30 = minutes
  3. Focused brainstorming time should be established = for certain areas that need real work by the = community
  4. Efforts to be discussed should be based on needs = of the security automation space to move existing efforts to = completion.

For example:

 

Continuous monitoring is a = major direction the efforts are becoming involved with. There are going = to be things we need to do as a security automation community to be able = to accomplish what is listed in the CAESARS FE.  There are = interfaces that need to be worked and established.  That is one = area that is not listed below.  CM will have a major impact on all = of us in the next couple years and it is being ignored.  We can't = keep trying to solve what has already been solved.  We need to = address the needed interface development now. This is an effort that = could take nearly a whole day by = itself.

 

Operationally we have a = real need to be able to deliver SCAP content internally within an = organization. Today the SCAP vendors cannot share a single local site = security policy (XCCDF + OVAL + CPE +…) without the site staff = having to go to each of the individual products and figuring out how to = inject that new or updated policy into that products delivery = mechanisms.  That is limiting sites from wanting to buy multiple = focused SCAP products since they are such a pain to manage from a = content perspective.  It is easier to buy from one vendor that has = a single means for distributing content than it is to deal with the = management issues that having multiple SCAP products presents.  We = need to have at least an entire 1/2 a day on the development of a = Content Repository specification.

 

OCIL is a positive and a = negative at the same time. It has real value that is being underutilized = and under implemented because of the limitations of how it addresses = uses in an enterprise environment.  People don't need security = automation to do things on/for a single host.  They need security = automation to focus on the enterprise issues that reduce their costs and = improve their efficiencies.  OCIL is failing in the enterprise and = we all understand that.  We need to address developing a definitive = solution for incorporating OCIL into the enterprise and that means into = the existing specifications. Scheduling and tracking are key to it's = success.  We need to make that happen.  This too needs a = focused brainstorming time box to discuss = options.

 

I am really disappointed = that Remediation is not on the list below…  Yes, last Summer = Dev Days, the time spent on Remediation was wasted time but that does = not mean we should ignore it and not try to make some real progress. =  As far as I am concerned we need to reboot the remediation effort. =  We cannot keep being the set of specifications / tools that act as = the little boy crying "Wolf" in the night.  We need to be = able to find and fix issues if we are going to really make a difference = in organizational security postures.  But today we think it is too = hard so we don't try ?  I think we need a couple hours to discuss = the reboot of the effort even if that means minimizing work already = done.

 

A focused discussion on = enterprise reporting is also critically needed.  For the vendors = here, we have all gone through the Cyberscope goat rope, delivering = limited capabilities to specific data call requirements of the Federal = Agencies.  The initial effort was a mess, did little more than = prove it was possible and cause the vendor community a great deal of = thrashing to put a kludgey 'solution' in place.  Reality is all our = customers need roll up reporting and an infrastructure that supports it. =  A data call should not be special to anyone other than the = agencies responding. The tools should be able to select the types of = data needed and deliver that on a scheduled basis automatically.   =  Enterprise Reporting pertains to commercial as well as Federal = customers.  We need to focus some time on what that would look like = using the ARF and ASR as the foundational pieces.  But there are = missing pieces….  We need this = discussed.

 

I would hope we can make = this summer's SCAP Dev Days useful in advancing the security automation = efforts by addressing some of the more critical issues our customers are = facing now or will be facing in the very short term.  Status = presentations are not interesting to those active in the efforts. =  Let's try to do those before we get to Bedford so we can real make = some progress while we are all in the same room.  This is always a = big event for the 'consensus of the willing' that assemble and driven to = see security automation make a difference.  Let's see if we can = have an event that, when we all walk out the last day, we all feel that = every minute was well spent and moves us = forward.

 

Thanks.

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

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

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com

 

From: = <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply= -To: "OVAL Developer List (Closed Public Discussion)" = <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

Frank;

 

We hope to have the registration site up next = week.  The event will be during the week of July 9 – starting = Monday at 10:00 AM and ending on Friday at 12:00.

 

Meanwhile, we are working on the agenda and are = currently considering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise = OCIL

CybOX/MAEC

Federated = Content Repository Spec

Endpoint = Reporting for Continuous Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for = SCAP

IF-MAP

SCAP = Releases

SCAP and IETF

NETCONF and = SCAP

 

Steve

 

= From:= Frank Lindsay Acker [mailto:afrank@NOVA.EDU] =
Sent: Tuesday, May 01, 2012 9:32 AM
To: = oval-developer-list OVAL Developer List/Closed Public = Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

 

= Steve....

Has there been any additional information regarding = this event?

Thanks,
Frank Acker

= From:= Boczenowski, Steve [sboczeno@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, = MA

Save the Date: week of July 9, = 2012

 

This year’s = MITRE-hosted Security Automation Developer Days event will be held = during the week of July 9, 2012 at MITRE’s facility in Bedford, = MA.

 

Details to = follow.

 

Regards,

    Steve

 

= ______________________________________________

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     sboczeno@mitre.org

 

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG = with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have = difficulties, write to OVAL-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

------=_NextPart_000_015E_01CD345B.0B0D1F10-- From david.waltermire@nist.gov Thu May 17 15:45: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 3961121F8826 for ; Thu, 17 May 2012 15:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.438 X-Spam-Level: X-Spam-Status: No, score=-5.438 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR1MtG1Fyqyc for ; Thu, 17 May 2012 15:44:59 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0121F87A8 for ; Thu, 17 May 2012 15:44:58 -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.355.2; Thu, 17 May 2012 18:44:40 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 17 May 2012 18:43:37 -0400 From: "Waltermire, David A." To: Panos Kampanakis , SCAP-DEV , "sacm@ietf.org" Date: Thu, 17 May 2012 18:44:56 -0400 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQAArCrAAQEd+jAAN3anYAAA83ng Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> In-Reply-To: <015d01cd347c$921ebf10$b65c3d30$@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_D7A0423E5E193F40BE6E94126930C4930B995C2B9CMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 17 May 2012 22:45:14 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B995C2B9CMBCLUSTERxcha_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Good points. It makes sense to use the mechanisms provided by XML (e.g. XM= LDsig, XML Encryption) and capabilities provided by the underlying transpor= t (e.g. TLS) to address as much of this as possible. It may be desirable t= o provide mechanisms for authentication to restrict access to content. Thi= s may also need to be integrated into the underlying transport. I have been on the fence about having a single mandatory-to-implement commu= nications protocol that is part of the draft or to define a second draft th= at will address one possible transport approach (e.g. RFC6546). This questi= on doesn't need to get answered right away, but the answer will have impact= on how much interoperability is possible. I'm not sure what the right answ= er is or if there is one right now. For our content repository prototyping efforts, we are developing REST inte= rfaces with use of JSON to express query parameters. I'd be glad to share o= ur implementation and lessons learned on this when we get to a suitable poi= nt. My hope is that our work will help inform some of the discussion aroun= d transport or at least provide a few data points. Sincerely, Dave From: Panos Kampanakis [mailto:pkampana@cisco.com] Sent: Thursday, May 17, 2012 6:30 PM To: Waltermire, David A.; SCAP-DEV; sacm@ietf.org Subject: RE: [sacm] Request for participants - Content Repository Specifica= tion Development Good starting point Dave. 2 thoughts: - Integrity and Confidentiality can certainly be addressed in this spec. Bu= t XML has its own mechanisms to provide them. Thus the content itself can p= rovide Integrity and Confidentiality. I am not sure if the spec should have= Integrity and Confidentiality as required features. - Also, should the data Exchange mechanism be part of this draft? For examp= le HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP, REST as were= suggested in SACM's alias before? Rgs, Panos From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermir= e, David A. Sent: Wednesday, May 16, 2012 3:39 PM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development I just posted a skeleton I/D on this topic. I have included an initial sec= tion that focuses on identifying the overall problem space relating to cont= ent repositories. I'd appreciate any comments. Here is the draft: http://www.ietf.org/id/draft-waltermire-content-repository-00.txt Sincerely, Dave From: Waltermire, David A. Sent: Friday, May 11, 2012 1:13 PM To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV; sacm@ietf.org Subject: RE: Request for participants - Content Repository Specification De= velopment Kent, I have already started work on a draft specification in this area. My hope= is that this work could be used as an initial draft within SACM at the app= ropriate time. Count me in. I mostly agree with what you are describing below. The only area I disagre= e with is in regards to federation. If we do not implement the specificati= on for an organizational repository in the right way, we may need to make m= ajor changes to support federation. This is not good for anyone. In my mi= nd these two concepts cannot be decoupled. We need to insure that any work= towards supporting an organizational repository provides a foundation for = supporting a federated repository network. Imagine if DNS was designed wit= h a single organization mindset first without thinking about federation. T= op Level Domains (TLDs) and subdomains would not likely exist as concepts. = An individual DNS server would likely not support caching, time-to-live an= d delegating capabilities that are necessary for federation to happen. All= of these things would need to be retrofitted. To prevent this, we need to= address the building blocks of federation in the basic design. Sincerely, Dave From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Friday, May 11, 2012 12:36 PM To: m.kinne@radium.ncsc.mil; Waltermire, Da= vid A.; SCAP-DEV; sacm@ietf.org Subject: Request for participants - Content Repository Specification Develo= pment Mike I love it when you tee something up like that.... ;-) Thank you. ;) Mike wrote: I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more... If you are talking about a holistic, complete federated approach to a conte= nt repository, I some what agree. If you are talking about an organization= al repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and oth= er related content to be served up inside an organization. Today we have s= ituation where the standards allow us to provide sites the capability to ha= ve a single SCAP implemented policy they call official for their environmen= t. Yes this is a rather simplistic since there are things such as targeting= specific platforms, specific operational use needs, but for now lets agree= SCAP is a massive improvement over the proprietary situations of the past.= While we have created this standard content so that sites can implement th= eir local site security once and then assure they are measuring all appropr= iately targeted devices the same way, we have failed to support the operati= onal needs of the sites. We have a situation where no two vendors distribu= te content the same way. This causes massive problems for the administrati= on staff when they need to incorporate a new SCAP enabled product into thei= r architecture. They need to discover how the new product supports distrib= uting SCAP content to it's various components. If they have one product th= en they do this one and they are done. If they have multiple products they= will have to figure out how to minimize the impact by incorporating the up= date process for the new product into the existing SCAP security content pr= ocesses. Now when the inevitable happens and the site staff needs to make a= change to their security policy, they have to make the modifications to th= e benchmark or checks or both and then distribute those updates across thei= r network. For each SCAP enabled product they have in place, they have dou= bled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Conte= nt Distribution. If you think global DNS you have a general frame of refer= ence. The guidance authors need to be able to publish content in an author= itative manner so their content is updated in a timely fashion. This is a = much harder problem to solve if there is no local organizational infrastruc= ture to support it. ;) So here is what I am thinking... We should consider addressing these as tw= o separate but integrated efforts. I believe the Organizational Content Re= pository is the more critical piece that is actually easier to address. Th= e Federated Content Distribution should be a subsequent effort integrating = / augmenting the Organizational repository specification. Mike, to your point that we need someone to build one first... That has hap= pened already. I have one as do other vendors but what we don't have is th= e access specification. Ours are focused on our specific product needs. A= dditionally there is a company that has developed a commercial SCAP content= repository that will be announced later this month. I won't steal their th= under but I was recently given a sneak peek at it and I must admit I was ve= ry impressed. Again, to your point, it has been done. What is needed to ad= dress the initial operational problem is to develop a specification that pr= ovides a consistent means for all SCAP products to retrieve the appropriate= content as configured and managed but the site. TO THAT END.... I am requesting participation from those in the community that see the need= and want to put in the work to make this specification happen. I have tal= ked to a couple of you but I do not want to assume your participation. If = you are interested please contact me so we can get this started. Thanks! Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Michael A > To: David Waltermire >, SCAP-DEV >, "sacm@ietf= .org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionabl= e and use it to make decisions, and vote and accomplish things good or bad.= I do not want this to be an informational briefing conference. Thanks for the links. I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more... -Mike From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Mike, What about having webinars in-place of the 30 minute briefs? Regarding content management, we are building the prototype content reposit= ory for use in a production environment. As an open source project, it wil= l be free for use by anyone interested. My thinking is that this project c= an bridge the gap until commercial solutions are available to augment it. = This is a similar path that was followed with DNS (bind) and HTTP (apache).= When it is ready for use, I am hoping to use it to host USGCB content. Y= ou would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supp= orting risk management and aspects of continuous monitoring. I would also = like to see some discussion on OCIL at Developer Days. With the proposals = we will likely have a sense of what needs to be discussed and what we can a= chieve consensus on outside the meeting. Remediation is a topic near and dear to my heart. I too would like to see = it move forward. We just published the draft ASR specification for public comment. This spe= cification supports enterprise aggregate reporting which greatly reduces th= e data volumes needed verses detailed host-based reports. This specificatio= n has been designed as a more robust replacement for LASR. It can be used = in continuous monitoring applications to support aggregate data reporting n= eeds (e.g. FISMA reporting, CyberScope). Here are the links: http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 The primary reason we have suggested waiting on XCCDF is not the internatio= nalization issue. Many vendors have commented that they are still working o= n implementing the XCCDF 1.2.1 specification. We will be in a better place = in a few months once more development around XCCDF has occurred. As we con= sider changes to the SCAP stack to address OCIL and other issues, we will i= dentify areas that need improvement in XCCDF. These are good and necessary= discussions to have now, but we have a good deal of work to do before we a= re ready to open up XCCDF. My suggestion is to work on these related areas= and then work up change proposals for XCCDF as needed. By that time we sh= ould be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has bee= n too long. Sincerely, Dave From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, It's good to read your thoughts, and a realistic actionable approach is ind= eed needed. Since all the activity hasn't been on the lists a brief 1=AE2 = hour recap may be in order to bring everyone up to speed since there has be= en a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone will= ing to stand one up it will be as valuable as the CCSS specification is tod= ay. I've been trying for two years to get my management to get a coordinat= ed effort together for the DoD to stand up a repository, it is a tough prob= lem and will require funding with a tail, I'm not sure a specification will= solve that problem. We (DoD) have been putting a lot of effort into OCIL over the last year try= ing to make it useful in an enterprise environment and will be posting our = ideas to the list before developer days it should have already started, we = need to get consensus and a vote on how the community wishes to proceed. Remediation is stalled but I'm making every effort to get it kick started f= rom our perspective. I hope to assist in getting the draft ERI finished thi= s year. We are writing some new STIG content and intend to used the draft = CRE specification to insert CRE into the content so we (DoD) can do some au= tomatic configuration fixes, part of a self healing network concept. It is = just a start but the best we can do at this point. Enterprise reporting is an interesting subject, since XML adds size to and = content to roll up reporting, in any enterprise of size the problem gets gr= eater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from ef= forts to meet use cases, we have some things we would like changed in XCCDF= to support our OCIl use case and I have been told that I need to wait. I d= idn't think that a move to internationalization should impede efforts to mo= ve forward with use cases. I look forward to talking with you at the conference. v/r Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Waltermire, David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of ap= proach. We would like to see some community discussion around what are the= key areas/priorities that the community would like to see discussed at Dev= Days. Your topics below look like a good start. The SACM list might be a = better venue than the OVAL list for this discussion. For each area we shou= ld focus the discussion around developing objectives for each session. The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective. For example if continuous monitoring is = a priority and collectively it takes 3 days to work through all the objecti= ves, I see no problem with that. We can also keep a few sessions "on deck"= if all the objectives are reached and we complete all the scheduled sessio= ns early. Thoughts? Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov From:scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.com<= mailto:Kent_Landfield@mcafee.com> Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation being sent out in advance, a webinar if it is felt there will be = questions and answers from those that are new to the efforts. We have a li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in ad= vance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas tha= t need real work by the community 4. Efforts to be discussed should be based on needs of the security autom= ation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d with. There are going to be things we need to do as a security automation= community to be able to accomplish what is listed in the CAESARS FE. Ther= e are interfaces that need to be worked and established. That is one area = that is not listed below. CM will have a major impact on all of us in the = next couple years and it is being ignored. We can't keep trying to solve w= hat has already been solved. We need to address the needed interface devel= opment now. This is an effort that could take nearly a whole day by itself. Operationally we have a real need to be able to deliver SCAP content intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +...) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e they are such a pain to manage from a content perspective. It is easier = to buy from one vendor that has a single means for distributing content tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt of a Content Repository specification. OCIL is a positive and a negative at the same time. It has real value that = is being underutilized and under implemented because of the limitations of = how it addresses uses in an enterprise environment. People don't need secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. Scheduling and tracking are key to it's success. We need to make that= happen. This too needs a focused brainstorming time box to discuss option= s. I am really disappointed that Remediation is not on the list below... Yes,= last Summer Dev Days, the time spent on Remediation was wasted time but th= at does not mean we should ignore it and not try to make some real progress= . As far as I am concerned we need to reboot the remediation effort. We c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. But today we think it is too hard so we don't try ? I think we need = a couple hours to discuss the reboot of the effort even if that means minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al Agencies. The initial effort was a mess, did little more than prove it = was possible and cause the vendor community a great deal of thrashing to pu= t a kludgey 'solution' in place. Reality is all our customers need roll up= reporting and an infrastructure that supports it. A data call should not = be special to anyone other than the agencies responding. The tools should b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces.... We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess while we are all in the same room. This is always a big event for the = 'consensus of the willing' that assemble and driven to see security automat= ion make a difference. Let's see if we can have an event that, when we all= walk out the last day, we all feel that every minute was well spent and mo= ves us forward. Thanks. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng the week of July 9 - starting Monday at 10:00 AM and ending on Friday at= 12:00. Meanwhile, we are working on the agenda and are currently considering this = list of topics: CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP Steve From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 This year's MITRE-hosted Security Automation Developer Days event will be h= eld during the week of July 9, 2012 at MITRE's facility in Bedford, MA. Details to follow. Regards, Steve ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG. --_000_D7A0423E5E193F40BE6E94126930C4930B995C2B9CMBCLUSTERxcha_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Good points.=A0 It makes sense to use the mechanisms provided= by XML (e.g. XMLDsig, XML Encryption) and capabilities provided by the und= erlying transport (e.g. TLS) to address as much of this as possible.=A0 It = may be desirable to provide mechanisms for authentication to restrict acces= s to content.=A0 This may also need to be integrated into the underlying tr= ansport.

 

I have been on the fence about having a single mandatory-to-imple= ment communications protocol that is part of the draft or to define a secon= d draft that will address one possible transport approach (e.g. RFC6546). T= his question doesn’t need to get answered right away, but the answer = will have impact on how much interoperability is possible. I’m not su= re what the right answer is or if there is one right now.=

 

For our content = repository prototyping efforts, we are developing REST interfaces with use = of JSON to express query parameters. I’d be glad to share our impleme= ntation and lessons learned on this when we get to a suitable point.=A0 My = hope is that our work will help inform some of the discussion around transp= ort or at least provide a few data points.

 

Sincerely,

Dave

 = ;

From: Panos Kampanakis [= mailto:pkampana@cisco.com]
Sent: Thursday, May 17, 2012 6:30 PM<= br>To: Waltermire, David A.; SCAP-DEV; sacm@ietf.org
Subject:<= /b> RE: [sacm] Request for participants - Content Repository Specification = Development

&nbs= p;

Good startin= g point Dave.

 

2 thoughts:

 

<= span style=3D'color:#1F497D'>- Integrity and Confidentiality can certa= inly be addressed in this spec. But XML has its own mechanisms to provide t= hem. Thus the content itself can provide Integrity and Confidentiality. I a= m not sure if the spec should have Integrity and Confidentiality as require= d features.

 

- Also, should the data Exchange mechanism be part of this dra= ft? For example HTTP/TLS messages etc (as in MILE’s rfc6546) or JSON,= SOAP, REST as were suggested in SACM’s alias before?

 <= /span>

Rgs,

Panos

&nbs= p;

=  

<= o:p> 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On= Behalf Of Waltermire, David A.
Sent: Wednesday, May 16, 2012= 3:39 PM
To: SCAP-DEV; sacm@ietf= .org
Subject: Re: [sacm] Request for participants - Content R= epository Specification Development

 

I just posted a skeleton I/D on this topic.  I have includ= ed an initial section that focuses on identifying the overall problem space= relating to content repositories.  I’d appreciate any comments.=

 

Here is the draft:

http://www.ietf.org/id/draft-waltermire-content-repos= itory-00.txt

 

Sincerely,

Dave

 

From: Waltermire, David A.
Sent: Friday= , May 11, 2012 1:13 PM
To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV; = sacm@ietf.org
Subject: RE: R= equest for participants - Content Repository Specification Development=

 

Kent,

<= p class=3DMsoNormal> <= /p>

I have already starte= d work on a draft specification in this area.  My hope is that this wo= rk could be used as an initial draft within SACM at the appropriate time.&n= bsp; Count me in.

 

I mostly agree with what you are describing below. = The only area I disagree with is in regards to federation.  If we do = not implement the specification for an organizational repository in the rig= ht way, we may need to make major changes to support federation.  This= is not good for anyone.  In my mind these two concepts cannot be deco= upled.  We need to insure that any work towards supporting an organiza= tional repository provides a foundation for supporting a federated reposito= ry network.  Imagine if DNS was designed with a single organization mi= ndset first without thinking about federation.  Top Level Domains (TLD= s) and subdomains would not likely exist as concepts.  An individual D= NS server would likely not support caching, time-to-live and delegating cap= abilities that are necessary for federation to happen.  All of these t= hings would need to be retrofitted.  To prevent this, we need to addre= ss the building blocks of federation in the basic design.=

 

Sincerely,<= o:p>

Dav= e

 

From:= Kent_Landfield@McAfee.com [mailto:Kent_Landfield@M= cAfee.com]
Sent: Friday, May 11, 2012 12:36 PM
To:= m.kinne@radium.ncsc.mil; Wa= ltermire, David A.; SCAP-DEV; sacm@ietf.or= g
Subject: Request for participants - Content Repository Spec= ification Development

 

Mike I love it when you tee something up like that…. ;-) &= nbsp;Thank you. ;)

 

Mike wrote: 

I still think that any specification for a repository is wis= hful thinking until someone builds one and learns the lessons it will just = be another whitepaper spec.  I believe the DoD needs to incorporate a = metadata repository as part of it and other customizations that may not be = useful for everyone.

We need to talk more&#= 8230;

 

If you are talking about a holistic, = complete federated approach to a content repository, I some what agree. &nb= sp;If you are talking about an organizational repository, I totally disagre= e. But you knew I would. ;)

 

Here is how I see the problem. &nb= sp;There is an immediate need for SCAP and other related content to be serv= ed up inside an organization.  Today we have situation where the stand= ards allow us to provide sites the capability to have a single SCAP impleme= nted policy they call official for their environment. Yes this is a rather = simplistic since there are things such as targeting specific platforms, spe= cific operational use needs, but for now lets agree SCAP is a massive impro= vement over the proprietary situations of the past. While we have created t= his standard content so that sites can implement their local site security = once and then assure they are measuring all appropriately targeted devices = the same way, we have failed to support the operational needs of the sites.=  We have a situation where no two vendors distribute content the same= way.  This causes massive problems for the administration staff when = they need to incorporate a new SCAP enabled product into their architecture= .  They need to discover how the new product supports distributing SCA= P content to it's various components.  If they have one product then t= hey do this one and they are done.  If they have multiple products the= y will have to figure out how to minimize the impact by incorporating the u= pdate process for the new product into the existing SCAP security content p= rocesses. Now when the inevitable happens and the site staff needs to make = a change to their security policy, they have to make the modifications to t= he benchmark or checks or both and then distribute those updates across the= ir network.  For each SCAP enabled product they have in place, they ha= ve doubled, tripled or more the work needed to make those updates available= . 

 

There is another content repository problem and that is the Federated = Content Distribution.  If you think global DNS you have a general fram= e of reference.  The guidance authors need to be able to publish conte= nt in an authoritative manner so their content is updated in a timely fashi= on.  This is a much harder problem to solve if there is no local organ= izational infrastructure to support it. ;)

 

So here is what I am thinking̷= 0;  We should consider addressing these as two separate but integrated= efforts.  I believe the Organizational Content Repository is the more= critical piece that is actually easier to address.  The Federated Con= tent Distribution should be a subsequent effort integrating / augmenting th= e Organizational repository specification. 

 

Mike, to your point that we n= eed someone to build one first… That has happened already.  I ha= ve one as do other vendors but what we don’t have is the access speci= fication.  Ours are focused on our specific product needs.  Addit= ionally there is a company that has developed a commercial SCAP content rep= ository that will be announced later this month. I won't steal their thunde= r but I was recently given a sneak peek at it and I must admit I was very i= mpressed.  Again, to your point, it has been done. What is needed to a= ddress the initial operational problem is to develop a specification that p= rovides a consistent means for all SCAP products to retrieve the appropriat= e content as configured and managed but the site.  <= /p>

 

TO THAT END….

&= nbsp;

I am= requesting participation from those in the community that see the need and= want to put in the work to make this specification happen.  I have ta= lked to a couple of you but I do not want to assume your participation. &nb= sp;If you are interested please contact me so we can get this started. = ;

 

T= hanks!

 

= Kent Landfield
Di= rector Content Strategy, Architecture and Standards

<= span style=3D'font-family:"Arial","sans-serif"'>McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

<= /div>

 = ;

From: <Kinney>, Mich= ael A <m.kinne@radium.ncsc.mi= l>
To: David Waltermire <david.waltermire@nist.gov>, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST]= Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

 

=

Dave,

I have no problem with webinars, I do want to keep = developer days actionable and use it to make decisions, and vote and accomp= lish things good or bad.  I do not want this to be an informational br= iefing conference.

=

Thanks for the links.

=  

I stil= l think that any specification for a repository is wishful thinking until s= omeone builds one and learns the lessons it will just be another whitepaper= spec.  I believe the DoD needs to incorporate a metadata repository a= s part of it and other customizations that may not be useful for everyone.<= /span>

We need to talk more…

 

-Mike 

 <= /o:p>

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'> Waltermire, David A. [mail= to:david.waltermire@nist.gov]
Sent: Tuesday, May 08, 2012 10= :44 AM
To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org
Subject: RE: [OVAL-DEVELOPER-LIST] Secu= rity Automation Developer Days: Summer 2012 at MITRE in Bedford, MA<= span style=3D'color:black'>

 

Mike,

 

What about having webinars in-pl= ace of the 30 minute briefs?<= /span>

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

Regarding content management, we are building the = prototype content repository for use in a production environment.  As = an open source project, it will be free for use by anyone interested. = My thinking is that this project can bridge the gap until commercial solut= ions are available to augment it.  This is a similar path that was fol= lowed with DNS (bind) and HTTP (apache).  When it is ready for use, I = am hoping to use it to host USGCB content.  You would be welcome to us= e it for your needs.

 

It is good that OCIL is moving forward.  This is an= important piece of supporting risk management and aspects of continuous mo= nitoring.  I would also like to see some discussion on OCIL at Develop= er Days.  With the proposals we will likely have a sense of what needs= to be discussed and what we can achieve consensus on outside the meeting.<= /span>

 

Reme= diation is a topic near and dear to my heart.  I too would like to see= it move forward.

<= p class=3DMsoNormal> 

We just published the draft ASR specification for public com= ment.  This specification supports enterprise aggregate reporting whic= h greatly reduces the data volumes needed verses detailed host-based report= s. This specification has been designed as a more robust replacement for LA= SR.  It can be used in continuous monitoring applications to support a= ggregate data reporting needs (e.g. FISMA reporting,  CyberScope).

<= span style=3D'color:#1F497D'> =

Here ar= e the links:

 

http= ://csrc.nist.gov/publications/PubsDrafts.html

http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848=

 <= o:p>

The= primary reason we have suggested waiting on XCCDF is not the international= ization issue. Many vendors have commented that they are still working on i= mplementing the XCCDF 1.2.1 specification. We will be in a better place in = a few months once more development around XCCDF has occurred.  As we c= onsider changes to the SCAP stack to address OCIL and other issues, we will= identify areas that need improvement in XCCDF.  These are good and ne= cessary discussions to have now, but we have a good deal of work to do befo= re we are ready to open up XCCDF.  My suggestion is to work on these r= elated areas and then work up change proposals for XCCDF as needed.  B= y that time we should be ready to work on a new revision of XCCDF.

 

I am also lo= oking forward to the discussions at the conference.  It has been too l= ong.

 

Sincerely,

Dave

 

From: Kinne= y, Michael A [mailto:m.kinne@rad= ium.ncsc.mil]
Sent: Tuesday, May 08, 2012 7:09 AM
To:<= /b> SCAP-DEV
Cc: Waltermire, David A.
Subject: RE: [OVA= L-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE = in Bedford, MA

 <= /span>

Kent,

 

It’s g= ood to read your thoughts, and a realistic actionable approach is indeed ne= eded.  Since all the activity hasn’t been on the lists a brief 1= =AE2 hour recap may be in order to bring everyone up to speed since there h= as been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

<= span style=3D'color:#1F497D'> =

We coul= d write a content repository specification, but without someone willing to = stand one up it will be as valuable as the CCSS specification is today. &nb= sp;I’ve been trying for two years to get my management to get a coord= inated effort together for the DoD to stand up a repository, it is a tough = problem and will require funding with a tail, I’m not sure a specific= ation will solve that problem.

 

We (DoD) have been putting a lot of effort into = OCIL over the last year trying to make it useful in an enterprise environme= nt and will be posting our ideas to the list before developer days it shoul= d have already started, we need to get consensus and a vote on how the comm= unity wishes to proceed.

 

Remediation is stalled but I’m making every effo= rt to get it kick started from our perspective. I hope to assist in getting= the draft ERI finished this year.  We are writing some new STIG conte= nt and intend to used the draft CRE specification to insert CRE into the co= ntent so we (DoD) can do some automatic configuration fixes, part of a self= healing network concept. It is just a start but the best we can do at this= point.

 

Enterprise reporting is an interesting subject, since XML adds size to = and content to roll up reporting, in any enterprise of size the problem get= s greater, I look forward to your thoughts on that subject.

 

I am concerned th= at the internationalization efforts are detracting from efforts to meet use= cases, we have some things we would like changed in XCCDF to support our O= CIl use case and I have been told that I need to wait. I didn’t think= that a move to internationalization should impede efforts to move forward = with use cases.

 

I look forward to talking with you at the conference.

 =

v/r=

 

Mike Kinney

Project Director=

Computer Network Defense Research and Technol= ogy (CND R&T) Office

9800 Savage Road Ste 6767
Ft Meade, MD 2= 0755-6767
Phone: 4= 10-854-4422
NSTS: 968-8886
Fax 410-854-4681

makinn2@nsa.gov

 

 

 

 

Kent,=

 <= o:p>

I l= ike what you are saying here.  We are also in support of this type of = approach.  We would like to see some community discussion around what = are the key areas/priorities that the community would like to see discussed= at Dev Days.  Your topics below look like a good start. The SACM list= might be a better venue than the OVAL list for this discussion.  For = each area we should focus the discussion around developing objectives for e= ach session.  The sessions can be time boxed based on what would be a = reasonable amount of time to accomplish each objective.  For example i= f continuous monitoring is a priority and collectively it takes 3 days to w= ork through all the objectives, I see no problem with that.  We can al= so keep a few sessions “on deck” if all the objectives are reac= hed and we complete all the scheduled sessions early.

 

<= p class=3DMsoNormal>Thoughts?

 

Sincerely,

 

David Waltermire

SCAP Architect=

National Inst= itute of Standards and Technology

(301) 975= -3390

david.waltermire@nist.gov

 <= o:p>

From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov] On= Behalf Of Kent_Landfield@= mcafee.com
Sent: Monday, May 07, 2012 4:25 PM
To: S= CAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation De= veloper Days: Summer 2012 at MITRE in Bedford, MA

 

All,

 

I would li= ke to discuss the format for the SCAP Developer Days that seems to be liste= d below.

 

I see this appears to follow a path we have d= iscussed in the past as the way not to hold a Dev Days event.  We have= been trying to get away from 'Death by Powerpoint' and back to the type of= event we held years ago when we were highly productive.  In the past = we had a topic to be discussed and a time box to work within.  That al= lowed us to have very active brainstorming sessions in a high bandwidth env= ironment.

 

At past Summer events we have got into a patt= ern of lots of powerpoint, lots of status of the efforts and very little di= scussion about things that need active discussions.  We need to keep m= oving forward and making progress as an effort. We can get status from vari= ous places such as the lists, a presentation being sent out in advance, a w= ebinar if it is felt there will be questions and answers from those that ar= e new to the efforts.  We have a limited amount of time and all who ar= e attending are investing a great deal of time and money to be there.  = ;We should not  be spending a great deal of time reeducating everyone = when we could be focused on advancing needed efforts.

=

 

Th= e type of approach to a Dev Days event was discussed at the last Summer Dev= Days.  I have seen the following work quite well in other efforts.

  1. Presentations are sent out to the attendees and the lists = a week in advance.
  2. Status for any effort is limited to 30 minutes
  3. Focused brainstorming time should be est= ablished for certain areas that need real work by the community<= /li>
  4. Efforts to be discussed sho= uld be based on needs of the security automation space to move existing eff= orts to completion.

For example:

 

Continuous monitoring is= a major direction the efforts are becoming involved with. There are going = to be things we need to do as a security automation community to be able to= accomplish what is listed in the CAESARS FE.  There are interfaces th= at need to be worked and established.  That is one area that is not li= sted below.  CM will have a major impact on all of us in the next coup= le years and it is being ignored.  We can't keep trying to solve what = has already been solved.  We need to address the needed interface deve= lopment now. This is an effort that could take nearly a whole day by itself= .

 

Operationally we have a real need to be able to delive= r SCAP content internally within an organization. Today the SCAP vendors ca= nnot share a single local site security policy (XCCDF + OVAL + CPE +…= ) without the site staff having to go to each of the individual products an= d figuring out how to inject that new or updated policy into that products = delivery mechanisms.  That is limiting sites from wanting to buy multi= ple focused SCAP products since they are such a pain to manage from a conte= nt perspective.  It is easier to buy from one vendor that has a single= means for distributing content than it is to deal with the management issu= es that having multiple SCAP products presents.  We need to have at le= ast an entire 1/2 a day on the development of a Content Repository specific= ation.

 

OCIL is a positive and a negative at the same tim= e. It has real value that is being underutilized and under implemented beca= use of the limitations of how it addresses uses in an enterprise environmen= t.  People don't need security automation to do things on/for a single= host.  They need security automation to focus on the enterprise issue= s that reduce their costs and improve their efficiencies.  OCIL is fai= ling in the enterprise and we all understand that.  We need to address= developing a definitive solution for incorporating OCIL into the enterpris= e and that means into the existing specifications. Scheduling and tracking = are key to it's success.  We need to make that happen.  This too = needs a focused brainstorming time box to discuss options.

 

I am really disappointed that Remediation is not on the list below…= ;  Yes, last Summer Dev Days, the time spent on Remediation was wasted= time but that does not mean we should ignore it and not try to make some r= eal progress.  As far as I am concerned we need to reboot the remediat= ion effort.  We cannot keep being the set of specifications / tools th= at act as the little boy crying "Wolf" in the night.  We nee= d to be able to find and fix issues if we are going to really make a differ= ence in organizational security postures.  But today we think it is to= o hard so we don't try ?  I think we need a couple hours to discuss th= e reboot of the effort even if that means minimizing work already done.

 

A focused discussion on enterprise reporting is also criti= cally needed.  For the vendors here, we have all gone through the Cybe= rscope goat rope, delivering limited capabilities to specific data call req= uirements of the Federal Agencies.  The initial effort was a mess, did= little more than prove it was possible and cause the vendor community a gr= eat deal of thrashing to put a kludgey 'solution' in place.  Reality i= s all our customers need roll up reporting and an infrastructure that suppo= rts it.  A data call should not be special to anyone other than the ag= encies responding. The tools should be able to select the types of data nee= ded and deliver that on a scheduled basis automatically.    Enter= prise Reporting pertains to commercial as well as Federal customers.  = We need to focus some time on what that would look like using the ARF and A= SR as the foundational pieces.  But there are missing pieces…. &= nbsp;We need this discussed.

 

<= p class=3DMsoNormal>I would hope we can make th= is summer's SCAP Dev Days useful in advancing the security automation effor= ts by addressing some of the more critical issues our customers are facing = now or will be facing in the very short term.  Status presentations ar= e not interesting to those active in the efforts.  Let's try to do tho= se before we get to Bedford so we can real make some progress while we are = all in the same room.  This is always a big event for the 'consensus o= f the willing' that assemble and driven to see security automation make a d= ifference.  Let's see if we can have an event that, when we all walk o= ut the last day, we all feel that every minute was well spent and moves us = forward.

 

Thanks.

 

Kent Landfield
Director Content Strategy, Architec= ture and Standards

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

Direct:= +1.972.963.7096 
Mobile: +1.= 817.637.8026
Web: www.mcafee.com

 

From: = <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply-To: "= OVAL Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG= >
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Devel= oper Days: Summer 2012 at MITRE in Bedford, MA

<= div>

 <= o:p>

Frank= ;

 =

We= hope to have the registration site up next week.  The event will be d= uring the week of July 9 – starting Monday at 10:00 AM and ending on = Friday at 12:00.

 

Meanwhile, we are working on the agenda and are currently co= nsidering this list of topics:

 

CCE

CPE/SWID

CEE

XCCDF<= /span>

OVAL

<= p class=3DMsoNormal style=3D'margin-left:.5in'>ASR

Enterprise= OCIL

CybOX/MAEC=

Federated Conte= nt Repository Spec

=

Endpoint Reporting for Continuous Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases=

SCAP and IETF

NETCONF and SCAP=

 <= /span>

Steve

 = ;

<= p class=3DMsoNormal style=3D'margin-left:2.0in'>From:= Frank Lindsay Acker [mailto:afrank@NOVA= .EDU]
Sent: Tuesday, May 01, 2012 9:32 AM
To: oval= -developer-list OVAL Developer List/Closed Public Discussion
Subject:= Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2= 012 at MITRE in Bedford, MA

 

Steve....

Has there been any additio= nal information regarding this event?

Thanks,
Frank Acker<= span style=3D'color:black'>

From: Boczenowski, Steve [sboczeno@M= ITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: <= a href=3D"mailto:OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG">OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Security Automa= tion Developer Days: Summer 2012 at MITRE in Bedford, MA

Save the Date: week= of July 9, 2012

 

This ye= ar’s MITRE-hosted Security Automation Developer Days event will be he= ld during the week of July 9, 2012 at MITRE’s facility in Bedford, MA= .

 

Details to follow.

 

Regards,

    Steve

 

____________________________= __________________

=

Stephen P.= Boczenowski

      The = MIT= RE Corporation

 = ;     Office: (781) 271-7682

      Cell: (978) 302-3849=

     sboczeno@mitre.org

 

To uns= ubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BO= DY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS= .MITRE.ORG.

To = unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the= BODY of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LI= STS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with S= IGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficul= ties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

= --_000_D7A0423E5E193F40BE6E94126930C4930B995C2B9CMBCLUSTERxcha_-- From david.waltermire@nist.gov Thu May 17 15:47: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 28EA621F85AE for ; Thu, 17 May 2012 15:47:42 -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=-1.956, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+qbWjwWLSQg for ; Thu, 17 May 2012 15:47:41 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1143321F8589 for ; Thu, 17 May 2012 15:47:41 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 17 May 2012 18:47:21 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 17 May 2012 18:46:19 -0400 From: "Waltermire, David A." To: "WOLFKIEL, JOSEPH L CIV DISA PEO-MA" , "Ronayne, James K." , Blake Frantz , SCAP-DEV , "sacm@ietf.org" Date: Thu, 17 May 2012 18:47:37 -0400 Thread-Topic: [scap-dev] Finding Severity Assignments Thread-Index: AQHNNCnmL8J58mIGlES69iemcblcjZbOE+CAgAAZ/qCAAAWFwIAAW6sQgAAGOhA= Message-ID: References: <0C700A7ED1FE57488BB17782F397264B05F78B91@DUMFDPEXMB01.disanet.disa-u.mil><0C700A7ED1FE57488BB17782F397264B05F78C41@DUMFDPEXMB01.disanet.disa-u.mil><37B94C562431DD4698C918992117B1F91D36DE9A@Exchange.msisac.org.local> <0C700A7ED1FE57488BB17782F397264B05F78D22@DUMFDPEXMB01.disanet.disa-u.mil> <0C700A7ED1FE57488BB17782F397264B05F78E11@DUMFDPEXMB01.disanet.disa-u.mil> In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78E11@DUMFDPEXMB01.disanet.disa-u.mil> 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 Cc: "Clingaman, Rodney J CTR DISA PEO-MA" Subject: Re: [sacm] [scap-dev] Finding Severity Assignments 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, 17 May 2012 22:47:42 -0000 Joe, We will make sure we capture this in the use cases document. If we don't adequately address it in a future revision, please let us know. ;-) Sincerely, Dave -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 6:38 PM To: Ronayne, James K.; Blake Frantz; SCAP-DEV; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: Re: [scap-dev] Finding Severity Assignments Good discussion. Not sure if everyone remembers, but I did propose "we" come up with a standardized understanding of what it would mean to distribute severities and scalars in a common format (see attached) over a year ago. At the time, I couldn't drum up much interest. I'm still not sure if the "community" is far enough along in the process to address the issue, but I really view severity maintenance as another "content" problem that would fold into an overall content repository discussion. I'd love to start discussing this since I view the severity assignment process as a very resource-intensive process that could be done by a small number of community experts, then licensed for distribution in a business model... This discussion is about defining the business logic for using severities once they're assigned. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil -----Original Message----- From: Ronayne, James K. [mailto:j.ronayn@radium.ncsc.mil] Sent: Thursday, May 17, 2012 1:37 PM To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; Blake Frantz; scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: RE: [scap-dev] Finding Severity Assignments This is a custom scoring system. What you described seems completely valid (although I think you might want the result score to be a multiplier on the CVSS/CCSS value - not reported might be worth 1.1*value, fixed 0.2*value). I think the question is how the standards relate to custom scoring systems. You could define your scoring system as an extension to XCCDF. At various times we have also considered removing scoring from XCCDF altogether or at least making it possible to not include scores in results. In general I agree we would prefer our scoring data to be handled separate from our results data. Do we need a means to, in a standard way, communicate details of a scoring system? Will this become more important as continuous monitoring becomes more common? These details might include both values or modifiers for each item and a formula for combining items. We already have feeds for things like CVE-CVSS. We would still need feeds to describe how to modify and combine those scores for a given set of rules. The simplest form of this would be the scoring system descriptions that are already part of XCCDF. Do we expect a results consumer to also consume standard scoring data and present results? The alternative is to implement proprietary scoring schemes based on standards data where possible. On a somewhat related note - we will probably have to do something about scoring in XCCDF when we start using OCIL more. Today an OCIL result of NOT TESTED gets translated to an XCCDF result of NOT CHECKED. NOT CHECKED results are not included in any of the existing scoring system calculations. That made sense with OVAL but I don't think it works for OCIL. Jim -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 12:51 PM To: Blake Frantz; scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: Re: [scap-dev] Finding Severity Assignments In general, I don't see our scoring as being directly linked to XCCDF content. The concept is similar, but scoring will take place in a central location and may address other attributes, to include network zone, mission affiliation, threat environment, etc that will be calculated and scored at report generation time versus assessment runtime. We also have tentative requirements to generate results against multiple scoring systems for the same finding (i.e. local DAA versus US Cyber versus Fed Gov), so I generally resist using any severities that are hard-coded into SCAP content. We're currently using the DISA FSO-assigned "CAT" score as the basis for STIG severities, which may or may not have any correlation to what's in the FDCC/USGCB content. I should also note that we're scoring a lot of data that isn't the result of SCAP content (AV and HIPS .dat file dates, required software compliance) and have plans to score others (blacklisted software, port & protocol usage, HIPS policy application, Data Loss Prevention policy compliance, running services, WAP policy compliance, etc.). In this space, I want to use the same methodology across the board, whether the data originated from SCAP or not. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil -----Original Message----- From: Blake Frantz [mailto:bfrantz@cisecurity.org] Sent: Thursday, May 17, 2012 12:20 PM To: WOLFKIEL, JOSEPH L CIV DISA PEO-MA; scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: RE: Finding Severity Assignments It seems the Rule/@severity attribute may have some relationship to the Rule/@weight attribute. Is that true in your use case? If we throw CCSS into the mix, the @weight attribute would be based on the actual state found on the box, not necessarily the outcome of the Rule's evaluation. It's my understanding the SCAP 1.2 allows tools to override Rule/@weight at runtime with a dynamically selected CCSS rating. Perhaps a dynamically set @severity attribute makes some sense too. Blake -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Thursday, May 17, 2012 5:38 AM To: scap-dev@nist.gov; sacm@ietf.org Cc: Clingaman, Rodney J CTR DISA PEO-MA Subject: [scap-dev] Finding Severity Assignments Not sure where/how to broach this subject, but I was working with one of our developers yesterday and we were discussing the assignment of severities to findings to generate scores. The question is whether severities should be assigned to XCCDF rule IDs, or to the tuple of (ruleID, result). I'm currently of the mind that we'll have to track severities at the tuple level due to the ambiguity and potentially changing nature of how we allocate severities to findings. For example, a given rule (in XCCDF) can have results of pass, fail, not checked, error, not applicable, or fixed. We can assign a severity of "3" to a group that includes [fail, error], a severity of 4 to [not checked], 1 to "fixed", and 0 to [pass, not applicable]. Do we need this level of flexibility, or can/should severities be assigned at the rule ID level and only two possible outcomes be possible where if you fall in one group you get the severity added to your score and if you fall in the other, you don't? As an aside, I've decided to call the "quantity" of "risk" or "added vulnerability" per finding a "severity", and call the sum of one or more severities allocated to an asset due to "findings" a "score." Not sure if that fits within standard terminology. Feel free to correct me if I got it wrong. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. From david.waltermire@nist.gov Thu May 17 18:57: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 4315021F86AA for ; Thu, 17 May 2012 18:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKledX4P236m for ; Thu, 17 May 2012 18:57:42 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8850721F86A6 for ; Thu, 17 May 2012 18:57:42 -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.355.2; Thu, 17 May 2012 21:56:57 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 17 May 2012 21:55:54 -0400 From: "Waltermire, David A." To: Kurt Seifried Date: Thu, 17 May 2012 21:57:14 -0400 Thread-Topic: [scap-dev] [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac00kt0R9fRLq2ABS4ai39EV+lBxfgABfUtw Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> In-Reply-To: <4FB5A18E.4090709@redhat.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 Cc: "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 01:57:43 -0000 Kurt, My assumption is that each organization would stand up a content repository based on this specification for their own authoritative content, content they produce. They would sign the content using their own private key or cert. I haven't worked out an approach for public key distribution yet. It would be nice if we could use DNS or some other standardized key distribution mechanism. I am looking for ideas. It may also make sense to allow for counter signing of content to allow 3rd parties to sign content. Again, I have not worked out how best to do this. Any ideas? Related to restricting access to content, it is my hope that the bulk of content in the security automation community is made freely available. Regardless, it probably makes sense to support some kind of access control. This could be driven by commercialization of content or to restrict access to some content to authorized users within an organization. Client/Server certificates might be a mechanism to support this, but we may need to look at other options as well. I hope this answers your questions. Sincerely, Dave -----Original Message----- From: Kurt Seifried [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development On 05/17/2012 04:44 PM, Waltermire, David A. wrote: > Good points. It makes sense to use the mechanisms provided by XML > (e.g. XMLDsig, XML Encryption) and capabilities provided by the > underlying transport (e.g. TLS) to address as much of this as > possible. It may be desirable to provide mechanisms for > authentication to restrict access to content. This may also need to > be integrated into the underlying transport. I have some questions: 1) if using XMLDsig who would be the signing authority? How secure would signing be (e.g. using a hardware card/appliance/etc?). Where would the key be published/would it be signed/etc? 2) You mention restricting access to content, why would the content need to be restricted? Are there IP issues I am unaware of? Thanks > Sincerely, > > Dave - -- Kurt Seifried Red Hat Security Response Team (SRT) From david.waltermire@nist.gov Thu May 17 19:31: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 BB5C121F86CB for ; Thu, 17 May 2012 19:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoJ+jElyDWNm for ; Thu, 17 May 2012 19:31:36 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D721F8762 for ; Thu, 17 May 2012 19:31: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.355.2; Thu, 17 May 2012 22:31:17 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 17 May 2012 22:30:14 -0400 From: "Waltermire, David A." To: Kurt Seifried Date: Thu, 17 May 2012 22:31:34 -0400 Thread-Topic: [scap-dev] [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac00nD4VkNusi9EWSby7a002kTZlkQAAETZA Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> In-Reply-To: <4FB5B148.40403@redhat.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 Cc: "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 02:31:37 -0000 Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: Kurt Seifried [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 10:18 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note: all opinions/comments are my own, not official Red Hat policy and so on. On 05/17/2012 07:19 PM, Waltermire, David A. wrote: > Kurt, > > My assumption is that each organization would stand up a content > repository based on this specification for their own authoritative > content, content they produce. They would sign the content using > their own private key. I haven't worked out an approach for public key > distribution yet. It would be if we could use DNS or some other > standardized key distribution mechanism. I am open to ideas. Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). [DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. I'd like to hear other thoughts related to X.509.] > It may also make sense to allow for counter signing of content to > allow 3rd parties to sign content. Again, I have not worked out how > best to do this. Any ideas? Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. [DAW: agreed.] > Related to restricting access to content, it is my hope that content > is made freely available. For some kinds of content, it probably > makes sense to support some kind of access control. This could be > driven by commercialization of content or to restrict access to some > content to authorized users within an organization. > Client/Server certificates might be a mechanism to support this. I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: 1) be incompatible (and thus either removed, or an active problem) for many vendors/customers (I doubt any existing system for selling content will end up being super compatible with what you guys build) 2) be unnecessary in most (if not almost all) cases 3) add significantly to the overhead of building this and not add any real value to the actual problem space of securing machines For some idea of the scope of this type of problem check out http://www.candlepinproject.org/ which provides subscription and entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. [DAW: Points well taken. I am interested in other thoughts on how best to address this. What I was recommending was looking more towards service authentication and less towards DRM. Maybe we don't address this in the first pass. Thoughts?] > I hope this answers your questions. > > Sincerely, Dave > > > -----Original Message----- From: Kurt Seifried > [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM > To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for > participants - Content Repository Specification Development > > On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >> Good points. It makes sense to use the mechanisms provided by XML >> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >> underlying transport (e.g. TLS) to address as much of this as >> possible. It may be desirable to provide mechanisms for >> authentication to restrict access to content. This may also need to >> be integrated into the underlying transport. > I have some questions, asking off list, not sure if they are > appropriate, if they are feel free to reply on the list. > > 1) if using XMLDsig who would be the signing authority? How secure > would signing be (e.g. using a hardware card/appliance/etc?). > Where would the key be published/would it be signed/etc? 2) You > mention restricting access to content, why would the content need to > be restricted? Are there IP issues I am unaware of? > > Thanks > >> Sincerely, Dave > - - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv XCldnHSPS6O7qeRTgMtL =QJsL -----END PGP SIGNATURE----- From kseifried@redhat.com Thu May 17 19:17: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 70B1021F86DF for ; Thu, 17 May 2012 19:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWJyxS8fjHrq for ; Thu, 17 May 2012 19:17:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9D21F86BA for ; Thu, 17 May 2012 19:17:47 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4I2Hkdm000335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 May 2012 22:17:46 -0400 Received: from seif-rht-f16.edm.seifried.org (ovpn-112-71.phx2.redhat.com [10.3.112.71]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4I2HjOZ016624; Thu, 17 May 2012 22:17:46 -0400 Message-ID: <4FB5B148.40403@redhat.com> Date: Thu, 17 May 2012 20:17:44 -0600 From: Kurt Seifried User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Waltermire, David A." References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=5E267993 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Mailman-Approved-At: Thu, 17 May 2012 19:31:55 -0700 Cc: "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 02:19:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note: all opinions/comments are my own, not official Red Hat policy and so on. On 05/17/2012 07:19 PM, Waltermire, David A. wrote: > Kurt, > > My assumption is that each organization would stand up a content > repository based on this specification for their own authoritative > content, content they produce. They would sign the content using > their own private key. I haven't worked out an approach for public > key distribution yet. It would be if we could use DNS or some > other standardized key distribution mechanism. I am open to > ideas. Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). > It may also make sense to allow for counter signing of content to > allow 3rd parties to sign content. Again, I have not worked out > how best to do this. Any ideas? Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. > Related to restricting access to content, it is my hope that > content is made freely available. For some kinds of content, it > probably makes sense to support some kind of access control. This > could be driven by commercialization of content or to restrict > access to some content to authorized users within an organization. > Client/Server certificates might be a mechanism to support this. I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: 1) be incompatible (and thus either removed, or an active problem) for many vendors/customers (I doubt any existing system for selling content will end up being super compatible with what you guys build) 2) be unnecessary in most (if not almost all) cases 3) add significantly to the overhead of building this and not add any real value to the actual problem space of securing machines For some idea of the scope of this type of problem check out http://www.candlepinproject.org/ which provides subscription and entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. > I hope this answers your questions. > > Sincerely, Dave > > > -----Original Message----- From: Kurt Seifried > [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM > To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request > for participants - Content Repository Specification Development > > On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >> Good points. It makes sense to use the mechanisms provided by >> XML (e.g. XMLDsig, XML Encryption) and capabilities provided by >> the underlying transport (e.g. TLS) to address as much of this >> as possible. It may be desirable to provide mechanisms for >> authentication to restrict access to content. This may also need >> to be integrated into the underlying transport. > I have some questions, asking off list, not sure if they are > appropriate, if they are feel free to reply on the list. > > 1) if using XMLDsig who would be the signing authority? How secure > would signing be (e.g. using a hardware card/appliance/etc?). > Where would the key be published/would it be signed/etc? 2) You > mention restricting access to content, why would the content need > to be restricted? Are there IP issues I am unaware of? > > Thanks > >> Sincerely, Dave > - - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv XCldnHSPS6O7qeRTgMtL =QJsL -----END PGP SIGNATURE----- From bchandra@secpod.com Thu May 17 22:50:05 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 36DF521F85A0 for ; Thu, 17 May 2012 22:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYOsDdUbdX5F for ; Thu, 17 May 2012 22:50:03 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id B73A021F859F for ; Thu, 17 May 2012 22:50:03 -0700 (PDT) Received: from [182.72.99.242] (port=1218 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SVG4f-0006bo-F1; Fri, 18 May 2012 11:20:02 +0530 From: "Chandrashekhar B" To: "'Waltermire, David A.'" , "'Kurt Seifried'" References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> In-Reply-To: Date: Fri, 18 May 2012 11:19:54 +0530 Organization: SecPod Technologies Message-ID: <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIK+AsmsxvscjAWr3S8jTQP4mAzmQJt5r4nAwtNyr4BXYM9OgIWTEFFAmtN2qECWp1sBAI9kxYaAh+jbxYB5OpClJWzzp+Q Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: SCAP-DEV , sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.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: Fri, 18 May 2012 05:50:05 -0000 My comments marked [CHA] Chandra. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Friday, May 18, 2012 8:02 AM To: Kurt Seifried Cc: sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: Kurt Seifried [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 10:18 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note: all opinions/comments are my own, not official Red Hat policy and so on. On 05/17/2012 07:19 PM, Waltermire, David A. wrote: > Kurt, > > My assumption is that each organization would stand up a content > repository based on this specification for their own authoritative > content, content they produce. They would sign the content using > their own private key. I haven't worked out an approach for public key > distribution yet. It would be if we could use DNS or some other > standardized key distribution mechanism. I am open to ideas. Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). [DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. [CHA: Yes, distributed network of repository, with may be a central registry. Even for a central registry, I feel we aren't there yet. Central repository or a registry would mean getting into operational aspects, who'll own, manage, control etc., So, limiting it to organizational repositories and content providers repository is good in my view.] As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. I'd like to hear other thoughts related to X.509.] [CHA: I am not sure if I understand the DNS resolution approach here completely, will anyway pose a question. If one content repository were to host a content authored by someone else and the namespace wasn't modified, may be for IP reasons. DNS namespace qualification would not work if I want to pick the content from this repository instead of the original author. Not sure if I am making sense :) ] > It may also make sense to allow for counter signing of content to > allow 3rd parties to sign content. Again, I have not worked out how > best to do this. Any ideas? Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. [DAW: agreed.] > Related to restricting access to content, it is my hope that content > is made freely available. For some kinds of content, it probably > makes sense to support some kind of access control. This could be > driven by commercialization of content or to restrict access to some > content to authorized users within an organization. > Client/Server certificates might be a mechanism to support this. I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: 1) be incompatible (and thus either removed, or an active problem) for many vendors/customers (I doubt any existing system for selling content will end up being super compatible with what you guys build) 2) be unnecessary in most (if not almost all) cases 3) add significantly to the overhead of building this and not add any real value to the actual problem space of securing machines For some idea of the scope of this type of problem check out http://www.candlepinproject.org/ which provides subscription and entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. [DAW: Points well taken. I am interested in other thoughts on how best to address this. What I was recommending was looking more towards service authentication and less towards DRM. Maybe we don't address this in the first pass. Thoughts?] [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. In our repository, we have implemented a policy driven access control and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. So, service authentication is required to be standardized. For access control, may be an error condition if one is not allowed to fetch the content?] > I hope this answers your questions. > > Sincerely, Dave > > > -----Original Message----- From: Kurt Seifried > [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM > To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for > participants - Content Repository Specification Development > > On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >> Good points. It makes sense to use the mechanisms provided by XML >> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >> underlying transport (e.g. TLS) to address as much of this as >> possible. It may be desirable to provide mechanisms for >> authentication to restrict access to content. This may also need to >> be integrated into the underlying transport. > I have some questions, asking off list, not sure if they are > appropriate, if they are feel free to reply on the list. > > 1) if using XMLDsig who would be the signing authority? How secure > would signing be (e.g. using a hardware card/appliance/etc?). > Where would the key be published/would it be signed/etc? 2) You > mention restricting access to content, why would the content need to > be restricted? Are there IP issues I am unaware of? > > Thanks > >> Sincerely, Dave > - - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv XCldnHSPS6O7qeRTgMtL =QJsL -----END PGP SIGNATURE----- _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Fri May 18 05:42: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 E788121F86CF for ; Fri, 18 May 2012 05:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIH8M8Pve5qm for ; Fri, 18 May 2012 05:42:13 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 10CD121F867A for ; Fri, 18 May 2012 05:42:13 -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.355.2; Fri, 18 May 2012 08:41:53 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 18 May 2012 08:42:11 -0400 From: "Waltermire, David A." To: "bchandra@secpod.com" , 'Kurt Seifried' Date: Fri, 18 May 2012 08:42:09 -0400 Thread-Topic: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Thread-Index: AQIK+AsmsxvscjAWr3S8jTQP4mAzmQJt5r4nAwtNyr4BXYM9OgIWTEFFAmtN2qECWp1sBAI9kxYaAh+jbxYB5OpClJWzzp+QgAB4dyA= Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> In-Reply-To: <00aa01cd34ba$0ecdc460$2c694d20$@secpod.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 Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 12:42:15 -0000 My comments marked with [DAW2]. Sincerely, Dave -----Original Message----- From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Friday, May 18, 2012 1:50 AM To: Waltermire, David A.; 'Kurt Seifried' Cc: sacm@ietf.org; SCAP-DEV Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development My comments marked [CHA] Chandra. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Friday, May 18, 2012 8:02 AM To: Kurt Seifried Cc: sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: Kurt Seifried [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 10:18 PM To: Waltermire, David A. Cc: sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note: all opinions/comments are my own, not official Red Hat policy and so on. On 05/17/2012 07:19 PM, Waltermire, David A. wrote: > Kurt, > > My assumption is that each organization would stand up a content > repository based on this specification for their own authoritative > content, content they produce. They would sign the content using > their own private key. I haven't worked out an approach for public key > distribution yet. It would be if we could use DNS or some other > standardized key distribution mechanism. I am open to ideas. Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). [DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. [CHA: Yes, distributed network of repository, with may be a central registry. Even for a central registry, I feel we aren't there yet. Central repository or a registry would mean getting into operational aspects, who'll own, manage, control etc., So, limiting it to organizational repositories and content providers repository is good in my view.] [DAW2: This is why I am advocating for a federated system. With the right approach, we can avoid having to stand up a single central registry and all the operational and logistical aspects involved. Using the DNS SRV approach below, DNS essentially becomes the registry. Using DNS, every organization that produces content is able to point to the authoritative content repositories that they use to host their content. They can create as many namespaces as needed, by using sub-domains within their own domain(s). A SRV record would be associated with each sub-domain in this case.] As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. I'd like to hear other thoughts related to X.509.] [CHA: I am not sure if I understand the DNS resolution approach here completely, will anyway pose a question. If one content repository were to host a content authored by someone else and the namespace wasn't modified, may be for IP reasons. DNS namespace qualification would not work if I want to pick the content from this repository instead of the original author. Not sure if I am making sense :) ] [DAW2: I am modeling this approach after DNS. There are authoritative content servers that originate content. The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server. This is an analog to domains hosted by an authoritative DNS server. Here is a basic communication flow: 1) Client: sends request for content by ID to local, organizational content repository. 2) Organizational repository: retrieve the requested content a) If the namespace is a local namespace, return the content. b) If the namespace is a foreign namespace, check if the content is in the local cache. c) Lookup the DNS SRV record associated with the ID's namespace. d) Dispatch a request to the foreign authoritative content repository based on the SRV record to retrieve the content e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server. 3) Organizational repository: respond to the client with the content This approach allows content for a given namespace to be managed by a single authoritative content repository. If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository. Access to local cache can (and probably should) be limited to IPs within an organization or thru the use of access controls to prevent leakage of cached content.] > It may also make sense to allow for counter signing of content to > allow 3rd parties to sign content. Again, I have not worked out how > best to do this. Any ideas? Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. [DAW: agreed.] > Related to restricting access to content, it is my hope that content > is made freely available. For some kinds of content, it probably > makes sense to support some kind of access control. This could be > driven by commercialization of content or to restrict access to some > content to authorized users within an organization. > Client/Server certificates might be a mechanism to support this. I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: 1) be incompatible (and thus either removed, or an active problem) for many vendors/customers (I doubt any existing system for selling content will end up being super compatible with what you guys build) 2) be unnecessary in most (if not almost all) cases 3) add significantly to the overhead of building this and not add any real value to the actual problem space of securing machines For some idea of the scope of this type of problem check out http://www.candlepinproject.org/ which provides subscription and entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. [DAW: Points well taken. I am interested in other thoughts on how best to address this. What I was recommending was looking more towards service authentication and less towards DRM. Maybe we don't address this in the first pass. Thoughts?] [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. In our repository, we have implemented a policy driven access control and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. So, service authentication is required to be standardized. For access control, may be an error condition if one is not allowed to fetch the content?] [DAW2: agreed. I see this as a minimal standardization approach.] > I hope this answers your questions. > > Sincerely, Dave > > > -----Original Message----- From: Kurt Seifried > [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM > To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for > participants - Content Repository Specification Development > > On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >> Good points. It makes sense to use the mechanisms provided by XML >> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >> underlying transport (e.g. TLS) to address as much of this as >> possible. It may be desirable to provide mechanisms for >> authentication to restrict access to content. This may also need to >> be integrated into the underlying transport. > I have some questions, asking off list, not sure if they are > appropriate, if they are feel free to reply on the list. > > 1) if using XMLDsig who would be the signing authority? How secure > would signing be (e.g. using a hardware card/appliance/etc?). > Where would the key be published/would it be signed/etc? 2) You > mention restricting access to content, why would the content need to > be restricted? Are there IP issues I am unaware of? > > Thanks > >> Sincerely, Dave > - - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv XCldnHSPS6O7qeRTgMtL =QJsL -----END PGP SIGNATURE----- _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Fri May 18 07:24: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 5E5E721F86AA for ; Fri, 18 May 2012 07:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2c-ToAc-XLK for ; Fri, 18 May 2012 07:24:54 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3964821F869F for ; Fri, 18 May 2012 07:24:53 -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.355.2; Fri, 18 May 2012 10:24:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 18 May 2012 10:24:52 -0400 From: "Waltermire, David A." To: "WOLFKIEL, JOSEPH L CIV DISA PEO-MA" , Panos Kampanakis , SCAP-DEV , "sacm@ietf.org" Date: Fri, 18 May 2012 10:24:46 -0400 Thread-Topic: [scap-dev] [sacm] Request for participants - Content RepositorySpecification Development Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQAArCrAAQEd+jAAN3anYAAgjpeAAABof5A= Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development 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, 18 May 2012 14:24:56 -0000 In a REST scenerio, a HTTP GET request would be used for querying. The pro= blem is, and correct me if I am wrong, that HTTP GET semantics require that= a resource be retrieved based on the request URI. This works for simple i= d lookups, but does not work well if you want to form a query around comple= x boolean criteria where grouping is needed. For this we may need to use J= SON to encode the query parameters as a request parameter. I would expect the response to be XML. Sincerely, David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov > -----Original Message----- > From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA > [mailto:joseph.wolfkiel@disa.mil] > Sent: Friday, May 18, 2012 9:42 AM > To: Panos Kampanakis; Waltermire, David A.; SCAP-DEV; sacm@ietf.org > Subject: RE: [scap-dev] [sacm] Request for participants - Content > RepositorySpecification Development > > If we're trying for interoperability, it seems like we'll need to > specify the transport and security. I'd hate to end up with something > where every consumer must be able to consume any combination of JSON, > XML, CSV over REST or SOAP because we didn't pick a standard > configuration. > > I like using REST if possible because the DoD in the Web Services STIG > has made SOAP-based web services difficult and expensive. I like XML > because we already have to do XML parsing for OVAL and XCCDF, so I > don't really see the allure of having to parse JSON for the service > then having to parse XML for the content. > > Joseph L. Wolfkiel > Engineering Group Lead > DISA PEO MA/IA52 > (301) 225-8820 > Joseph.Wolfkiel@DISA.mil > > > -----Original Message----- > From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On > Behalf Of Panos Kampanakis > Sent: Thursday, May 17, 2012 6:30 PM > To: 'Waltermire, David A.'; SCAP-DEV; sacm@ietf.org > Subject: Re: [scap-dev] [sacm] Request for participants - Content > RepositorySpecification Development > > Good starting point Dave. > > > > 2 thoughts: > > > > - Integrity and Confidentiality can certainly be addressed in this > spec. But XML has its own mechanisms to provide them. Thus the content > itself can provide Integrity and Confidentiality. I am not sure if the > spec should have Integrity and Confidentiality as required features. > > > > - Also, should the data Exchange mechanism be part of this draft? For > example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP, > REST as were suggested in SACM's alias before? > > > > Rgs, > > Panos > > > > > > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Wednesday, May 16, 2012 3:39 PM > To: SCAP-DEV; sacm@ietf.org > Subject: Re: [sacm] Request for participants - Content Repository > Specification Development > > > > I just posted a skeleton I/D on this topic. I have included an initial > section that focuses on identifying the overall problem space relating > to content repositories. I'd appreciate any comments. > > > > Here is the draft: > > http://www.ietf.org/id/draft-waltermire-content-repository-00.txt > > > > Sincerely, > > Dave > > > > From: Waltermire, David A. > Sent: Friday, May 11, 2012 1:13 PM > To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV; > sacm@ietf.org > Subject: RE: Request for participants - Content Repository > Specification Development > > > > Kent, > > > > I have already started work on a draft specification in this area. My > hope is that this work could be used as an initial draft within SACM at > the appropriate time. Count me in. > > > > I mostly agree with what you are describing below. The only area I > disagree with is in regards to federation. If we do not implement the > specification for an organizational repository in the right way, we may > need to make major changes to support federation. This is not good for > anyone. In my mind these two concepts cannot be decoupled. We need to > insure that any work towards supporting an organizational repository > provides a foundation for supporting a federated repository network. > Imagine if DNS was designed with a single organization mindset first > without thinking about federation. Top Level Domains (TLDs) and > subdomains would not likely exist as concepts. An individual DNS > server would likely not support caching, time-to-live and delegating > capabilities that are necessary for federation to happen. All of these > things would need to be retrofitted. To prevent this, we need to > address the building blocks of federation in the basic design. > > > > Sincerely, > > Dave > > > > From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] > Sent: Friday, May 11, 2012 12:36 PM > To: m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; > sacm@ietf.org > Subject: Request for participants - Content Repository Specification > Development > > > > Mike I love it when you tee something up like that.. ;-) Thank you. ;) > > > > Mike wrote: > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will just > be another whitepaper spec. I believe the DoD needs to incorporate a > metadata repository as part of it and other customizations that may not > be useful for everyone. > > We need to talk more. > > > > If you are talking about a holistic, complete federated approach to a > content repository, I some what agree. If you are talking about an > organizational repository, I totally disagree. But you knew I would. ;) > > > > Here is how I see the problem. There is an immediate need for SCAP and > other related content to be served up inside an organization. Today we > have situation where the standards allow us to provide sites the > capability to have a single SCAP implemented policy they call official > for their environment. Yes this is a rather simplistic since there are > things such as targeting specific platforms, specific operational use > needs, but for now lets agree SCAP is a massive improvement over the > proprietary situations of the past. While we have created this standard > content so that sites can implement their local site security once and > then assure they are measuring all appropriately targeted devices the > same way, we have failed to support the operational needs of the sites. > We have a situation where no two vendors distribute content the same > way. This causes massive problems for the administration staff when > they need to incorporate a new SCAP enabled product into their > architecture. They need to discover how the new product supports > distributing SCAP content to it's various components. If they have one > product then they do this one and they are done. If they have multiple > products they will have to figure out how to minimize the impact by > incorporating the update process for the new product into the existing > SCAP security content processes. Now when the inevitable happens and > the site staff needs to make a change to their security policy, they > have to make the modifications to the benchmark or checks or both and > then distribute those updates across their network. For each SCAP > enabled product they have in place, they have doubled, tripled or more > the work needed to make those updates available. > > > > There is another content repository problem and that is the Federated > Content Distribution. If you think global DNS you have a general frame > of reference. The guidance authors need to be able to publish content > in an authoritative manner so their content is updated in a timely > fashion. This is a much harder problem to solve if there is no local > organizational infrastructure to support it. ;) > > > > So here is what I am thinking. We should consider addressing these as > two separate but integrated efforts. I believe the Organizational > Content Repository is the more critical piece that is actually easier > to address. The Federated Content Distribution should be a subsequent > effort integrating / augmenting the Organizational repository > specification. > > > > Mike, to your point that we need someone to build one first. That has > happened already. I have one as do other vendors but what we don't > have is the access specification. Ours are focused on our specific > product needs. Additionally there is a company that has developed a > commercial SCAP content repository that will be announced later this > month. I won't steal their thunder but I was recently given a sneak > peek at it and I must admit I was very impressed. Again, to your > point, it has been done. What is needed to address the initial > operational problem is to develop a specification that provides a > consistent means for all SCAP products to retrieve the appropriate > content as configured and managed but the site. > > > > TO THAT END.. > > > > I am requesting participation from those in the community that see the > need and want to put in the work to make this specification happen. I > have talked to a couple of you but I do not want to assume your > participation. If you are interested please contact me so we can get > this started. > > > > Thanks! > > > > Kent Landfield > Director Content Strategy, Architecture and Standards > > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > > > > From: , Michael A > To: David Waltermire , SCAP-DEV DEV@nist.gov>, "sacm@ietf.org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > > > Dave, > > I have no problem with webinars, I do want to keep developer days > actionable and use it to make decisions, and vote and accomplish things > good or bad. I do not want this to be an informational briefing > conference. > > Thanks for the links. > > > > I still think that any specification for a repository is wishful > thinking until someone builds one and learns the lessons it will just > be another whitepaper spec. I believe the DoD needs to incorporate a > metadata repository as part of it and other customizations that may not > be useful for everyone. > > We need to talk more. > > > > -Mike > > > > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Tuesday, May 08, 2012 10:44 AM > To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org > Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > > > Mike, > > > > What about having webinars in-place of the 30 minute briefs? > > > > Regarding content management, we are building the prototype > content repository for use in a production environment. As an open > source project, it will be free for use by anyone interested. My > thinking is that this project can bridge the gap until commercial > solutions are available to augment it. This is a similar path that was > followed with DNS (bind) and HTTP (apache). When it is ready for use, > I am hoping to use it to host USGCB content. You would be welcome to > use it for your needs. > > > > It is good that OCIL is moving forward. This is an important > piece of supporting risk management and aspects of continuous > monitoring. I would also like to see some discussion on OCIL at > Developer Days. With the proposals we will likely have a sense of what > needs to be discussed and what we can achieve consensus on outside the > meeting. > > > > Remediation is a topic near and dear to my heart. I too would > like to see it move forward. > > > > We just published the draft ASR specification for public comment. > This specification supports enterprise aggregate reporting which > greatly reduces the data volumes needed verses detailed host-based > reports. This specification has been designed as a more robust > replacement for LASR. It can be used in continuous monitoring > applications to support aggregate data reporting needs (e.g. FISMA > reporting, CyberScope). > > > > Here are the links: > > > > http://csrc.nist.gov/publications/PubsDrafts.html > > http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 > > > > The primary reason we have suggested waiting on XCCDF is not the > internationalization issue. Many vendors have commented that they are > still working on implementing the XCCDF 1.2.1 specification. We will be > in a better place in a few months once more development around XCCDF > has occurred. As we consider changes to the SCAP stack to address OCIL > and other issues, we will identify areas that need improvement in > XCCDF. These are good and necessary discussions to have now, but we > have a good deal of work to do before we are ready to open up XCCDF. > My suggestion is to work on these related areas and then work up change > proposals for XCCDF as needed. By that time we should be ready to work > on a new revision of XCCDF. > > > > I am also looking forward to the discussions at the conference. > It has been too long. > > > > Sincerely, > > Dave > > > > From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] > Sent: Tuesday, May 08, 2012 7:09 AM > To: SCAP-DEV > Cc: Waltermire, David A. > Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > > > Kent, > > > > It's good to read your thoughts, and a realistic actionable > approach is indeed needed. Since all the activity hasn't been on the > lists a brief 1=AE2 hour recap may be in order to bring everyone up to > speed since there has been a lot of activity on CPE/SWID, OCIl, > MAEC/CybOX CEE and others. > > > > We could write a content repository specification, but without > someone willing to stand one up it will be as valuable as the CCSS > specification is today. I've been trying for two years to get my > management to get a coordinated effort together for the DoD to stand up > a repository, it is a tough problem and will require funding with a > tail, I'm not sure a specification will solve that problem. > > > > We (DoD) have been putting a lot of effort into OCIL over the > last year trying to make it useful in an enterprise environment and > will be posting our ideas to the list before developer days it should > have already started, we need to get consensus and a vote on how the > community wishes to proceed. > > > > Remediation is stalled but I'm making every effort to get it kick > started from our perspective. I hope to assist in getting the draft ERI > finished this year. We are writing some new STIG content and intend to > used the draft CRE specification to insert CRE into the content so we > (DoD) can do some automatic configuration fixes, part of a self healing > network concept. It is just a start but the best we can do at this > point. > > > > Enterprise reporting is an interesting subject, since XML adds > size to and content to roll up reporting, in any enterprise of size the > problem gets greater, I look forward to your thoughts on that subject. > > > > I am concerned that the internationalization efforts are > detracting from efforts to meet use cases, we have some things we would > like changed in XCCDF to support our OCIl use case and I have been told > that I need to wait. I didn't think that a move to internationalization > should impede efforts to move forward with use cases. > > > > I look forward to talking with you at the conference. > > > > v/r > > > > Mike Kinney > > Project Director > > Computer Network Defense Research and Technology (CND R&T) Office > > 9800 Savage Road Ste 6767 > Ft Meade, MD 20755-6767 > Phone: 410-854-4422 > NSTS: 968-8886 > Fax 410-854-4681 > > makinn2@nsa.gov > > > > > > > > From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of > Waltermire, David A. > Sent: Monday, May 07, 2012 7:09 PM > To: Multiple recipients of list > Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > > > Kent, > > > > I like what you are saying here. We are also in support of this > type of approach. We would like to see some community discussion > around what are the key areas/priorities that the community would like > to see discussed at Dev Days. Your topics below look like a good > start. The SACM list might be a better venue than the OVAL list for > this discussion. For each area we should focus the discussion around > developing objectives for each session. The sessions can be time boxed > based on what would be a reasonable amount of time to accomplish each > objective. For example if continuous monitoring is a priority and > collectively it takes 3 days to work through all the objectives, I see > no problem with that. We can also keep a few sessions "on deck" if all > the objectives are reached and we complete all the scheduled sessions > early. > > > > Thoughts? > > > > Sincerely, > > > > David Waltermire > > SCAP Architect > > National Institute of Standards and Technology > > (301) 975-3390 > > david.waltermire@nist.gov > > > > From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of > Kent_Landfield@mcafee.com > Sent: Monday, May 07, 2012 4:25 PM > To: SCAP-DEV > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > > > All, > > > > I would like to discuss the format for the SCAP Developer Days > that seems to be listed below. > > > > I see this appears to follow a path we have discussed in the past > as the way not to hold a Dev Days event. We have been trying to get > away from 'Death by Powerpoint' and back to the type of event we held > years ago when we were highly productive. In the past we had a topic > to be discussed and a time box to work within. That allowed us to have > very active brainstorming sessions in a high bandwidth environment. > > > > At past Summer events we have got into a pattern of lots of > powerpoint, lots of status of the efforts and very little discussion > about things that need active discussions. We need to keep moving > forward and making progress as an effort. We can get status from > various places such as the lists, a presentation being sent out in > advance, a webinar if it is felt there will be questions and answers > from those that are new to the efforts. We have a limited amount of > time and all who are attending are investing a great deal of time and > money to be there. We should not be spending a great deal of time > reeducating everyone when we could be focused on advancing needed > efforts. > > > > The type of approach to a Dev Days event was discussed at the > last Summer Dev Days. I have seen the following work quite well in > other efforts. > > 1. Presentations are sent out to the attendees and the lists a > week in advance. > 2. Status for any effort is limited to 30 minutes > 3. Focused brainstorming time should be established for > certain areas that need real work by the community > 4. Efforts to be discussed should be based on needs of the > security automation space to move existing efforts to completion. > > For example: > > > > Continuous monitoring is a major direction the efforts are > becoming involved with. There are going to be things we need to do as a > security automation community to be able to accomplish what is listed > in the CAESARS FE. There are interfaces that need to be worked and > established. That is one area that is not listed below. CM will have > a major impact on all of us in the next couple years and it is being > ignored. We can't keep trying to solve what has already been solved. > We need to address the needed interface development now. This is an > effort that could take nearly a whole day by itself. > > > > Operationally we have a real need to be able to deliver SCAP > content internally within an organization. Today the SCAP vendors > cannot share a single local site security policy (XCCDF + OVAL + CPE > +.) without the site staff having to go to each of the individual > products and figuring out how to inject that new or updated policy into > that products delivery mechanisms. That is limiting sites from wanting > to buy multiple focused SCAP products since they are such a pain to > manage from a content perspective. It is easier to buy from one vendor > that has a single means for distributing content than it is to deal > with the management issues that having multiple SCAP products presents. > We need to have at least an entire 1/2 a day on the development of a > Content Repository specification. > > > > OCIL is a positive and a negative at the same time. It has real > value that is being underutilized and under implemented because of the > limitations of how it addresses uses in an enterprise environment. > People don't need security automation to do things on/for a single > host. They need security automation to focus on the enterprise issues > that reduce their costs and improve their efficiencies. OCIL is > failing in the enterprise and we all understand that. We need to > address developing a definitive solution for incorporating OCIL into > the enterprise and that means into the existing specifications. > Scheduling and tracking are key to it's success. We need to make that > happen. This too needs a focused brainstorming time box to discuss > options. > > > > I am really disappointed that Remediation is not on the list > below. Yes, last Summer Dev Days, the time spent on Remediation was > wasted time but that does not mean we should ignore it and not try to > make some real progress. As far as I am concerned we need to reboot > the remediation effort. We cannot keep being the set of specifications > / tools that act as the little boy crying "Wolf" in the night. We need > to be able to find and fix issues if we are going to really make a > difference in organizational security postures. But today we think it > is too hard so we don't try ? I think we need a couple hours to > discuss the reboot of the effort even if that means minimizing work > already done. > > > > A focused discussion on enterprise reporting is also critically > needed. For the vendors here, we have all gone through the Cyberscope > goat rope, delivering limited capabilities to specific data call > requirements of the Federal Agencies. The initial effort was a mess, > did little more than prove it was possible and cause the vendor > community a great deal of thrashing to put a kludgey 'solution' in > place. Reality is all our customers need roll up reporting and an > infrastructure that supports it. A data call should not be special to > anyone other than the agencies responding. The tools should be able to > select the types of data needed and deliver that on a scheduled basis > automatically. Enterprise Reporting pertains to commercial as well > as Federal customers. We need to focus some time on what that would > look like using the ARF and ASR as the foundational pieces. But there > are missing pieces.. We need this discussed. > > > > I would hope we can make this summer's SCAP Dev Days useful in > advancing the security automation efforts by addressing some of the > more critical issues our customers are facing now or will be facing in > the very short term. Status presentations are not interesting to those > active in the efforts. Let's try to do those before we get to Bedford > so we can real make some progress while we are all in the same room. > This is always a big event for the 'consensus of the willing' that > assemble and driven to see security automation make a difference. > Let's see if we can have an event that, when we all walk out the last > day, we all feel that every minute was well spent and moves us forward. > > > > Thanks. > > > > Kent Landfield > Director Content Strategy, Architecture and Standards > > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > > > > From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" DEVELOPER-LIST@LISTS.MITRE.ORG> > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" LIST@LISTS.MITRE.ORG> > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > Days: Summer 2012 at MITRE in Bedford, MA > > > > Frank; > > > > We hope to have the registration site up next week. The > event will be during the week of July 9 - starting Monday at 10:00 AM > and ending on Friday at 12:00. > > > > Meanwhile, we are working on the agenda and are currently > considering this list of topics: > > > > CCE > > CPE/SWID > > CEE > > XCCDF > > OVAL > > ASR > > Enterprise OCIL > > CybOX/MAEC > > Federated Content Repository Spec > > Endpoint Reporting for Continuous Monitoring and Compliance > (ERCC) > > MILE > > TAXII > > IF-M for SCAP > > IF-MAP > > SCAP Releases > > SCAP and IETF > > NETCONF and SCAP > > > > Steve > > > > From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] > Sent: Tuesday, May 01, 2012 9:32 AM > To: oval-developer-list OVAL Developer List/Closed Public > Discussion > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > > > Steve.... > > Has there been any additional information regarding this > event? > > Thanks, > Frank Acker > > > ________________________________ > > > From: Boczenowski, Steve [sboczeno@MITRE.ORG] > Sent: Tuesday, March 20, 2012 16:38 > To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > Subject: [OVAL-DEVELOPER-LIST] Security Automation > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Save the Date: week of July 9, 2012 > > > > This year's MITRE-hosted Security Automation Developer Days > event will be held during the week of July 9, 2012 at MITRE's facility > in Bedford, MA. > > > > Details to follow. > > > > Regards, > > Steve > > > > ______________________________________________ > > Stephen P. Boczenowski > > The MITRE Corporation > > Office: (781) 271-7682 > > Cell: (978) 302-3849 > > sboczeno@mitre.org > > > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY > of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST- > request@LISTS.MITRE.ORG. > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY > of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST- > request@LISTS.MITRE.ORG. > > To unsubscribe, send an email message to > LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY > of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST- > request@LISTS.MITRE.ORG. From gunnar.engelbach@threatguard.com Fri May 18 08:16:33 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 922F921F875D for ; Fri, 18 May 2012 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, MISSING_HEADERS=1.292, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEYupN18dLyq for ; Fri, 18 May 2012 08:16:31 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC8B21F8757 for ; Fri, 18 May 2012 08:16:31 -0700 (PDT) Received: (qmail 12608 invoked from network); 18 May 2012 09:19:51 -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); 18 May 2012 09:19:51 -0700 Message-ID: <4FB667D5.2040906@ThreatGuard.com> Date: Fri, 18 May 2012 11:16:37 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development 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, 18 May 2012 15:16:33 -0000 There are limitations in encoding requests using an HTTP GET, such as a maximum URI length, but most webservers support 8KB URLs, so the drawback to using a GET is the ability to send a structured request or to embed binary data. Most of the time I think you'll find that a query can be parameterized into a URL, which makes it a nice lightweight request format, but if not REST also allows for the use of a POST where the content structure is arbitrary and the typical limit is more like 2GB. A consideration for using JSON is that JSON data is actually code objects that are evaluated on the receiving end by executing them, so they are a potential attack vector. Using JSON means either having complete trust in the sender of the JSON objects or having complete trust in your ability to detect attack code on the receiving end. --gun On 5/18/2012 10:24 AM, Waltermire, David A. wrote: > In a REST scenerio, a HTTP GET request would be used for querying. The problem is, and correct me if I am wrong, that HTTP GET semantics require that a resource be retrieved based on the request URI. This works for simple id lookups, but does not work well if you want to form a query around complex boolean criteria where grouping is needed. For this we may need to use JSON to encode the query parameters as a request parameter. > > I would expect the response to be XML. > > Sincerely, > > David Waltermire > SCAP Architect > National Institute of Standards and Technology > (301) 975-3390 > david.waltermire@nist.gov > > >> -----Original Message----- >> From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA >> [mailto:joseph.wolfkiel@disa.mil] >> Sent: Friday, May 18, 2012 9:42 AM >> To: Panos Kampanakis; Waltermire, David A.; SCAP-DEV; sacm@ietf.org >> Subject: RE: [scap-dev] [sacm] Request for participants - Content >> RepositorySpecification Development >> >> If we're trying for interoperability, it seems like we'll need to >> specify the transport and security. I'd hate to end up with something >> where every consumer must be able to consume any combination of JSON, >> XML, CSV over REST or SOAP because we didn't pick a standard >> configuration. >> >> I like using REST if possible because the DoD in the Web Services STIG >> has made SOAP-based web services difficult and expensive. I like XML >> because we already have to do XML parsing for OVAL and XCCDF, so I >> don't really see the allure of having to parse JSON for the service >> then having to parse XML for the content. >> >> Joseph L. Wolfkiel >> Engineering Group Lead >> DISA PEO MA/IA52 >> (301) 225-8820 >> Joseph.Wolfkiel@DISA.mil >> >> >> -----Original Message----- >> From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On >> Behalf Of Panos Kampanakis >> Sent: Thursday, May 17, 2012 6:30 PM >> To: 'Waltermire, David A.'; SCAP-DEV; sacm@ietf.org >> Subject: Re: [scap-dev] [sacm] Request for participants - Content >> RepositorySpecification Development >> >> Good starting point Dave. >> >> >> >> 2 thoughts: >> >> >> >> - Integrity and Confidentiality can certainly be addressed in this >> spec. But XML has its own mechanisms to provide them. Thus the content >> itself can provide Integrity and Confidentiality. I am not sure if the >> spec should have Integrity and Confidentiality as required features. >> >> >> >> - Also, should the data Exchange mechanism be part of this draft? For >> example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP, >> REST as were suggested in SACM's alias before? >> >> >> >> Rgs, >> >> Panos >> >> >> >> >> >> >> >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Waltermire, David A. >> Sent: Wednesday, May 16, 2012 3:39 PM >> To: SCAP-DEV; sacm@ietf.org >> Subject: Re: [sacm] Request for participants - Content Repository >> Specification Development >> >> >> >> I just posted a skeleton I/D on this topic. I have included an initial >> section that focuses on identifying the overall problem space relating >> to content repositories. I'd appreciate any comments. >> >> >> >> Here is the draft: >> >> http://www.ietf.org/id/draft-waltermire-content-repository-00.txt >> >> >> >> Sincerely, >> >> Dave >> >> >> >> From: Waltermire, David A. >> Sent: Friday, May 11, 2012 1:13 PM >> To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV; >> sacm@ietf.org >> Subject: RE: Request for participants - Content Repository >> Specification Development >> >> >> >> Kent, >> >> >> >> I have already started work on a draft specification in this area. My >> hope is that this work could be used as an initial draft within SACM at >> the appropriate time. Count me in. >> >> >> >> I mostly agree with what you are describing below. The only area I >> disagree with is in regards to federation. If we do not implement the >> specification for an organizational repository in the right way, we may >> need to make major changes to support federation. This is not good for >> anyone. In my mind these two concepts cannot be decoupled. We need to >> insure that any work towards supporting an organizational repository >> provides a foundation for supporting a federated repository network. >> Imagine if DNS was designed with a single organization mindset first >> without thinking about federation. Top Level Domains (TLDs) and >> subdomains would not likely exist as concepts. An individual DNS >> server would likely not support caching, time-to-live and delegating >> capabilities that are necessary for federation to happen. All of these >> things would need to be retrofitted. To prevent this, we need to >> address the building blocks of federation in the basic design. >> >> >> >> Sincerely, >> >> Dave >> >> >> >> From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] >> Sent: Friday, May 11, 2012 12:36 PM >> To: m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; >> sacm@ietf.org >> Subject: Request for participants - Content Repository Specification >> Development >> >> >> >> Mike I love it when you tee something up like that.. ;-) Thank you. ;) >> >> >> >> Mike wrote: >> >> I still think that any specification for a repository is wishful >> thinking until someone builds one and learns the lessons it will just >> be another whitepaper spec. I believe the DoD needs to incorporate a >> metadata repository as part of it and other customizations that may not >> be useful for everyone. >> >> We need to talk more. >> >> >> >> If you are talking about a holistic, complete federated approach to a >> content repository, I some what agree. If you are talking about an >> organizational repository, I totally disagree. But you knew I would. ;) >> >> >> >> Here is how I see the problem. There is an immediate need for SCAP and >> other related content to be served up inside an organization. Today we >> have situation where the standards allow us to provide sites the >> capability to have a single SCAP implemented policy they call official >> for their environment. Yes this is a rather simplistic since there are >> things such as targeting specific platforms, specific operational use >> needs, but for now lets agree SCAP is a massive improvement over the >> proprietary situations of the past. While we have created this standard >> content so that sites can implement their local site security once and >> then assure they are measuring all appropriately targeted devices the >> same way, we have failed to support the operational needs of the sites. >> We have a situation where no two vendors distribute content the same >> way. This causes massive problems for the administration staff when >> they need to incorporate a new SCAP enabled product into their >> architecture. They need to discover how the new product supports >> distributing SCAP content to it's various components. If they have one >> product then they do this one and they are done. If they have multiple >> products they will have to figure out how to minimize the impact by >> incorporating the update process for the new product into the existing >> SCAP security content processes. Now when the inevitable happens and >> the site staff needs to make a change to their security policy, they >> have to make the modifications to the benchmark or checks or both and >> then distribute those updates across their network. For each SCAP >> enabled product they have in place, they have doubled, tripled or more >> the work needed to make those updates available. >> >> >> >> There is another content repository problem and that is the Federated >> Content Distribution. If you think global DNS you have a general frame >> of reference. The guidance authors need to be able to publish content >> in an authoritative manner so their content is updated in a timely >> fashion. This is a much harder problem to solve if there is no local >> organizational infrastructure to support it. ;) >> >> >> >> So here is what I am thinking. We should consider addressing these as >> two separate but integrated efforts. I believe the Organizational >> Content Repository is the more critical piece that is actually easier >> to address. The Federated Content Distribution should be a subsequent >> effort integrating / augmenting the Organizational repository >> specification. >> >> >> >> Mike, to your point that we need someone to build one first. That has >> happened already. I have one as do other vendors but what we don't >> have is the access specification. Ours are focused on our specific >> product needs. Additionally there is a company that has developed a >> commercial SCAP content repository that will be announced later this >> month. I won't steal their thunder but I was recently given a sneak >> peek at it and I must admit I was very impressed. Again, to your >> point, it has been done. What is needed to address the initial >> operational problem is to develop a specification that provides a >> consistent means for all SCAP products to retrieve the appropriate >> content as configured and managed but the site. >> >> >> >> TO THAT END.. >> >> >> >> I am requesting participation from those in the community that see the >> need and want to put in the work to make this specification happen. I >> have talked to a couple of you but I do not want to assume your >> participation. If you are interested please contact me so we can get >> this started. >> >> >> >> Thanks! >> >> >> >> Kent Landfield >> Director Content Strategy, Architecture and Standards >> >> McAfee | An Intel Company >> 5000 Headquarters Dr. >> Plano, Texas 75024 >> >> Direct: +1.972.963.7096 >> Mobile: +1.817.637.8026 >> Web: www.mcafee.com >> >> >> >> From:, Michael A >> To: David Waltermire, SCAP-DEV> DEV@nist.gov>, "sacm@ietf.org" >> Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer >> Days: Summer 2012 at MITRE in Bedford, MA >> >> >> >> Dave, >> >> I have no problem with webinars, I do want to keep developer days >> actionable and use it to make decisions, and vote and accomplish things >> good or bad. I do not want this to be an informational briefing >> conference. >> >> Thanks for the links. >> >> >> >> I still think that any specification for a repository is wishful >> thinking until someone builds one and learns the lessons it will just >> be another whitepaper spec. I believe the DoD needs to incorporate a >> metadata repository as part of it and other customizations that may not >> be useful for everyone. >> >> We need to talk more. >> >> >> >> -Mike >> >> >> >> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] >> Sent: Tuesday, May 08, 2012 10:44 AM >> To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org >> Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer >> Days: Summer 2012 at MITRE in Bedford, MA >> >> >> >> Mike, >> >> >> >> What about having webinars in-place of the 30 minute briefs? >> >> >> >> Regarding content management, we are building the prototype >> content repository for use in a production environment. As an open >> source project, it will be free for use by anyone interested. My >> thinking is that this project can bridge the gap until commercial >> solutions are available to augment it. This is a similar path that was >> followed with DNS (bind) and HTTP (apache). When it is ready for use, >> I am hoping to use it to host USGCB content. You would be welcome to >> use it for your needs. >> >> >> >> It is good that OCIL is moving forward. This is an important >> piece of supporting risk management and aspects of continuous >> monitoring. I would also like to see some discussion on OCIL at >> Developer Days. With the proposals we will likely have a sense of what >> needs to be discussed and what we can achieve consensus on outside the >> meeting. >> >> >> >> Remediation is a topic near and dear to my heart. I too would >> like to see it move forward. >> >> >> >> We just published the draft ASR specification for public comment. >> This specification supports enterprise aggregate reporting which >> greatly reduces the data volumes needed verses detailed host-based >> reports. This specification has been designed as a more robust >> replacement for LASR. It can be used in continuous monitoring >> applications to support aggregate data reporting needs (e.g. FISMA >> reporting, CyberScope). >> >> >> >> Here are the links: >> >> >> >> http://csrc.nist.gov/publications/PubsDrafts.html >> >> http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 >> >> >> >> The primary reason we have suggested waiting on XCCDF is not the >> internationalization issue. Many vendors have commented that they are >> still working on implementing the XCCDF 1.2.1 specification. We will be >> in a better place in a few months once more development around XCCDF >> has occurred. As we consider changes to the SCAP stack to address OCIL >> and other issues, we will identify areas that need improvement in >> XCCDF. These are good and necessary discussions to have now, but we >> have a good deal of work to do before we are ready to open up XCCDF. >> My suggestion is to work on these related areas and then work up change >> proposals for XCCDF as needed. By that time we should be ready to work >> on a new revision of XCCDF. >> >> >> >> I am also looking forward to the discussions at the conference. >> It has been too long. >> >> >> >> Sincerely, >> >> Dave >> >> >> >> From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] >> Sent: Tuesday, May 08, 2012 7:09 AM >> To: SCAP-DEV >> Cc: Waltermire, David A. >> Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer >> Days: Summer 2012 at MITRE in Bedford, MA >> >> >> >> Kent, >> >> >> >> It's good to read your thoughts, and a realistic actionable >> approach is indeed needed. Since all the activity hasn't been on the >> lists a brief 1®2 hour recap may be in order to bring everyone up to >> speed since there has been a lot of activity on CPE/SWID, OCIl, >> MAEC/CybOX CEE and others. >> >> >> >> We could write a content repository specification, but without >> someone willing to stand one up it will be as valuable as the CCSS >> specification is today. I've been trying for two years to get my >> management to get a coordinated effort together for the DoD to stand up >> a repository, it is a tough problem and will require funding with a >> tail, I'm not sure a specification will solve that problem. >> >> >> >> We (DoD) have been putting a lot of effort into OCIL over the >> last year trying to make it useful in an enterprise environment and >> will be posting our ideas to the list before developer days it should >> have already started, we need to get consensus and a vote on how the >> community wishes to proceed. >> >> >> >> Remediation is stalled but I'm making every effort to get it kick >> started from our perspective. I hope to assist in getting the draft ERI >> finished this year. We are writing some new STIG content and intend to >> used the draft CRE specification to insert CRE into the content so we >> (DoD) can do some automatic configuration fixes, part of a self healing >> network concept. It is just a start but the best we can do at this >> point. >> >> >> >> Enterprise reporting is an interesting subject, since XML adds >> size to and content to roll up reporting, in any enterprise of size the >> problem gets greater, I look forward to your thoughts on that subject. >> >> >> >> I am concerned that the internationalization efforts are >> detracting from efforts to meet use cases, we have some things we would >> like changed in XCCDF to support our OCIl use case and I have been told >> that I need to wait. I didn't think that a move to internationalization >> should impede efforts to move forward with use cases. >> >> >> >> I look forward to talking with you at the conference. >> >> >> >> v/r >> >> >> >> Mike Kinney >> >> Project Director >> >> Computer Network Defense Research and Technology (CND R&T) Office >> >> 9800 Savage Road Ste 6767 >> Ft Meade, MD 20755-6767 >> Phone: 410-854-4422 >> NSTS: 968-8886 >> Fax 410-854-4681 >> >> makinn2@nsa.gov >> >> >> >> >> >> >> >> From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of >> Waltermire, David A. >> Sent: Monday, May 07, 2012 7:09 PM >> To: Multiple recipients of list >> Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer >> Days: Summer 2012 at MITRE in Bedford, MA >> >> >> >> Kent, >> >> >> >> I like what you are saying here. We are also in support of this >> type of approach. We would like to see some community discussion >> around what are the key areas/priorities that the community would like >> to see discussed at Dev Days. Your topics below look like a good >> start. The SACM list might be a better venue than the OVAL list for >> this discussion. For each area we should focus the discussion around >> developing objectives for each session. The sessions can be time boxed >> based on what would be a reasonable amount of time to accomplish each >> objective. For example if continuous monitoring is a priority and >> collectively it takes 3 days to work through all the objectives, I see >> no problem with that. We can also keep a few sessions "on deck" if all >> the objectives are reached and we complete all the scheduled sessions >> early. >> >> >> >> Thoughts? >> >> >> >> Sincerely, >> >> >> >> David Waltermire >> >> SCAP Architect >> >> National Institute of Standards and Technology >> >> (301) 975-3390 >> >> david.waltermire@nist.gov >> >> >> >> From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of >> Kent_Landfield@mcafee.com >> Sent: Monday, May 07, 2012 4:25 PM >> To: SCAP-DEV >> Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer >> Days: Summer 2012 at MITRE in Bedford, MA >> >> >> >> All, >> >> >> >> I would like to discuss the format for the SCAP Developer Days >> that seems to be listed below. >> >> >> >> I see this appears to follow a path we have discussed in the past >> as the way not to hold a Dev Days event. We have been trying to get >> away from 'Death by Powerpoint' and back to the type of event we held >> years ago when we were highly productive. In the past we had a topic >> to be discussed and a time box to work within. That allowed us to have >> very active brainstorming sessions in a high bandwidth environment. >> >> >> >> At past Summer events we have got into a pattern of lots of >> powerpoint, lots of status of the efforts and very little discussion >> about things that need active discussions. We need to keep moving >> forward and making progress as an effort. We can get status from >> various places such as the lists, a presentation being sent out in >> advance, a webinar if it is felt there will be questions and answers >> from those that are new to the efforts. We have a limited amount of >> time and all who are attending are investing a great deal of time and >> money to be there. We should not be spending a great deal of time >> reeducating everyone when we could be focused on advancing needed >> efforts. >> >> >> >> The type of approach to a Dev Days event was discussed at the >> last Summer Dev Days. I have seen the following work quite well in >> other efforts. >> >> 1. Presentations are sent out to the attendees and the lists a >> week in advance. >> 2. Status for any effort is limited to 30 minutes >> 3. Focused brainstorming time should be established for >> certain areas that need real work by the community >> 4. Efforts to be discussed should be based on needs of the >> security automation space to move existing efforts to completion. >> >> For example: >> >> >> >> Continuous monitoring is a major direction the efforts are >> becoming involved with. There are going to be things we need to do as a >> security automation community to be able to accomplish what is listed >> in the CAESARS FE. There are interfaces that need to be worked and >> established. That is one area that is not listed below. CM will have >> a major impact on all of us in the next couple years and it is being >> ignored. We can't keep trying to solve what has already been solved. >> We need to address the needed interface development now. This is an >> effort that could take nearly a whole day by itself. >> >> >> >> Operationally we have a real need to be able to deliver SCAP >> content internally within an organization. Today the SCAP vendors >> cannot share a single local site security policy (XCCDF + OVAL + CPE >> +.) without the site staff having to go to each of the individual >> products and figuring out how to inject that new or updated policy into >> that products delivery mechanisms. That is limiting sites from wanting >> to buy multiple focused SCAP products since they are such a pain to >> manage from a content perspective. It is easier to buy from one vendor >> that has a single means for distributing content than it is to deal >> with the management issues that having multiple SCAP products presents. >> We need to have at least an entire 1/2 a day on the development of a >> Content Repository specification. >> >> >> >> OCIL is a positive and a negative at the same time. It has real >> value that is being underutilized and under implemented because of the >> limitations of how it addresses uses in an enterprise environment. >> People don't need security automation to do things on/for a single >> host. They need security automation to focus on the enterprise issues >> that reduce their costs and improve their efficiencies. OCIL is >> failing in the enterprise and we all understand that. We need to >> address developing a definitive solution for incorporating OCIL into >> the enterprise and that means into the existing specifications. >> Scheduling and tracking are key to it's success. We need to make that >> happen. This too needs a focused brainstorming time box to discuss >> options. >> >> >> >> I am really disappointed that Remediation is not on the list >> below. Yes, last Summer Dev Days, the time spent on Remediation was >> wasted time but that does not mean we should ignore it and not try to >> make some real progress. As far as I am concerned we need to reboot >> the remediation effort. We cannot keep being the set of specifications >> / tools that act as the little boy crying "Wolf" in the night. We need >> to be able to find and fix issues if we are going to really make a >> difference in organizational security postures. But today we think it >> is too hard so we don't try ? I think we need a couple hours to >> discuss the reboot of the effort even if that means minimizing work >> already done. >> >> >> >> A focused discussion on enterprise reporting is also critically >> needed. For the vendors here, we have all gone through the Cyberscope >> goat rope, delivering limited capabilities to specific data call >> requirements of the Federal Agencies. The initial effort was a mess, >> did little more than prove it was possible and cause the vendor >> community a great deal of thrashing to put a kludgey 'solution' in >> place. Reality is all our customers need roll up reporting and an >> infrastructure that supports it. A data call should not be special to >> anyone other than the agencies responding. The tools should be able to >> select the types of data needed and deliver that on a scheduled basis >> automatically. Enterprise Reporting pertains to commercial as well >> as Federal customers. We need to focus some time on what that would >> look like using the ARF and ASR as the foundational pieces. But there >> are missing pieces.. We need this discussed. >> >> >> >> I would hope we can make this summer's SCAP Dev Days useful in >> advancing the security automation efforts by addressing some of the >> more critical issues our customers are facing now or will be facing in >> the very short term. Status presentations are not interesting to those >> active in the efforts. Let's try to do those before we get to Bedford >> so we can real make some progress while we are all in the same room. >> This is always a big event for the 'consensus of the willing' that >> assemble and driven to see security automation make a difference. >> Let's see if we can have an event that, when we all walk out the last >> day, we all feel that every minute was well spent and moves us forward. >> >> >> >> Thanks. >> >> >> >> Kent Landfield >> Director Content Strategy, Architecture and Standards >> >> McAfee | An Intel Company >> 5000 Headquarters Dr. >> Plano, Texas 75024 >> >> Direct: +1.972.963.7096 >> Mobile: +1.817.637.8026 >> Web: www.mcafee.com >> >> >> >> From:, Steve >> Reply-To: "OVAL Developer List (Closed Public Discussion)"> DEVELOPER-LIST@LISTS.MITRE.ORG> >> To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG"> LIST@LISTS.MITRE.ORG> >> Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer >> Days: Summer 2012 at MITRE in Bedford, MA >> >> >> >> Frank; >> >> >> >> We hope to have the registration site up next week. The >> event will be during the week of July 9 - starting Monday at 10:00 AM >> and ending on Friday at 12:00. >> >> >> >> Meanwhile, we are working on the agenda and are currently >> considering this list of topics: >> >> >> >> CCE >> >> CPE/SWID >> >> CEE >> >> XCCDF >> >> OVAL >> >> ASR >> >> Enterprise OCIL >> >> CybOX/MAEC >> >> Federated Content Repository Spec >> >> Endpoint Reporting for Continuous Monitoring and Compliance >> (ERCC) >> >> MILE >> >> TAXII >> >> IF-M for SCAP >> >> IF-MAP >> >> SCAP Releases >> >> SCAP and IETF >> >> NETCONF and SCAP >> >> >> >> Steve >> >> >> >> From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU] >> Sent: Tuesday, May 01, 2012 9:32 AM >> To: oval-developer-list OVAL Developer List/Closed Public >> Discussion >> Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation >> Developer Days: Summer 2012 at MITRE in Bedford, MA >> >> >> >> Steve.... >> >> Has there been any additional information regarding this >> event? >> >> Thanks, >> Frank Acker >> >> >> ________________________________ >> >> >> From: Boczenowski, Steve [sboczeno@MITRE.ORG] >> Sent: Tuesday, March 20, 2012 16:38 >> To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG >> Subject: [OVAL-DEVELOPER-LIST] Security Automation >> Developer Days: Summer 2012 at MITRE in Bedford, MA >> >> Save the Date: week of July 9, 2012 >> >> >> >> This year's MITRE-hosted Security Automation Developer Days >> event will be held during the week of July 9, 2012 at MITRE's facility >> in Bedford, MA. >> >> >> >> Details to follow. >> >> >> >> Regards, >> >> Steve >> >> >> >> ______________________________________________ >> >> Stephen P. Boczenowski >> >> The MITRE Corporation >> >> Office: (781) 271-7682 >> >> Cell: (978) 302-3849 >> >> sboczeno@mitre.org >> >> >> >> To unsubscribe, send an email message to >> LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY >> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST- >> request@LISTS.MITRE.ORG. >> >> To unsubscribe, send an email message to >> LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY >> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST- >> request@LISTS.MITRE.ORG. >> >> To unsubscribe, send an email message to >> LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY >> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST- >> request@LISTS.MITRE.ORG. > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Fri May 18 09:46:49 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 9A73B21F8742 for ; Fri, 18 May 2012 09:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=1.320, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwgHlQr5cbVi for ; Fri, 18 May 2012 09:46:48 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id AE32621F8720 for ; Fri, 18 May 2012 09:46:48 -0700 (PDT) Received: (qmail 14131 invoked from network); 18 May 2012 10:50:08 -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); 18 May 2012 10:50:08 -0700 Message-ID: <4FB67D00.7020803@ThreatGuard.com> Date: Fri, 18 May 2012 12:46:56 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kurt Seifried References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> <4FB667D5.2040906@ThreatGuard.com> <4FB67BB1.6000106@redhat.com> In-Reply-To: <4FB67BB1.6000106@redhat.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development 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, 18 May 2012 16:46:49 -0000 On 5/18/2012 12:41 PM, Kurt Seifried wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/18/2012 09:16 AM, Gunnar Engelbach wrote: >> >> There are limitations in encoding requests using an HTTP GET, such >> as a maximum URI length, but most webservers support 8KB URLs, so >> the drawback to using a GET is the ability to send a structured >> request or to embed binary data. Most of the time I think you'll >> find that a query can be parameterized into a URL, which makes it a >> nice lightweight request format, but if not REST also allows for >> the use of a POST where the content structure is arbitrary and the >> typical limit is more like 2GB. >> >> >> A consideration for using JSON is that JSON data is actually code >> objects that are evaluated on the receiving end by executing them, >> so they are a potential attack vector. Using JSON means either >> having complete trust in the sender of the JSON objects or having >> complete trust in your ability to detect attack code on the >> receiving end. >> >> >> --gun > > This is not true. Perhaps you are thinking of JavaScript and using the > eval() method to parse the JSON data? Which you shouldn't be doing. > Pretty much all other JSON decoders don't do anything as remotely > crazy as running the input straight through eval(). Thanks. That shows you how limited my exposure to JSON has been thus far. > > JSON simply allows you to encode numbers, strings, booleans, arrays, > objects (key:value pairs) and null. Nothing magic. Unless you do > something crazy like shove the untrusted input straight through eval() > or blindly use the input without some minimal filtering (e.g. escaping > it for SQL queries) you should be fine. > > > - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtnuxAAoJEBYNRVNeJnmTATMP/RNrGLnnHx41e/Z2e7uQVTcM > p0bfBg8U7KQhE9c6cgwt9A+0CZ5RsihYSfEYgf3ryXZ8R9iZPbUO+fgEWZbS/G7b > wXJI9PMtwdOQPjH6+yq9ET/3usDKTLHZ4c0wJrpdeGb4HaKJG89fmZuOMimMfzxr > s7f6+sQLND5r5mQ+Y6mqvC//YCcm9BSkq8G5l/Ra5sADadCuPro2NI5pZI5Et/cz > lQCewnk2EhTZQr8ne12dUxFs22tyNafyYkkCLUIi4bPVuovqoe2qCpK3CL99mMsR > bfmCsiCDUXq87SuEIu/0si43eIgeMcnvI1bgPTWyuXuRIf4S/wz3zgWJhD4oiUvb > cGL4Fb6HvpegRa5mHVUhd7pnlo/RzoCO5K1XHnUHg+0qQwFqUx75mcxUijJxErOQ > eMP/7qBFfs6kdCNB+Uut2vtfGhbzoQ1qjTkTDVt1bBjP6KAX1nUzCZZfV1WpoN4d > B6fPTw83PyPotvKI8as9ZIk5TO3BPuEvuggQjR28h8pwX2D3KWQtLdi6QEavFD0P > 499h3u1nwnSVm922U/BpNMvwYnHDY/Q6KCsUzIoCRmMo8CXoGTyjWhEMocjZVmlX > pmR80rmxyzEiK9aLTZb9IO8XhM9oPyALF57m8tYbupN+NlSiyCAvIbcciK/GE9qz > hDNlxW1RQB51+Jv5M/2P > =lDW+ > -----END PGP SIGNATURE----- From gunnar.engelbach@threatguard.com Fri May 18 10:03: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 49C8521F84E7 for ; Fri, 18 May 2012 10:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVI0Qh1d62bs for ; Fri, 18 May 2012 10:03:42 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF121F84D8 for ; Fri, 18 May 2012 10:03:42 -0700 (PDT) Received: (qmail 14446 invoked from network); 18 May 2012 11:07:03 -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); 18 May 2012 11:07:03 -0700 Message-ID: <4FB680F6.9090607@ThreatGuard.com> Date: Fri, 18 May 2012 13:03:50 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 17:03:44 -0000 Dave, It sounds like you are trying to solve two separate problems here. The first is the ability to retrieve content from a repository, the second is the ability to locate repositories. I'm not seeing enough of an overlap between these two sets to need to address them in the same standard. As far as modeling discovery on DNS, I'm not sold, but that could just be a lack of understanding on my part -- and I still haven't had time to read your draft spec. But it sounds like a chicken-and-egg problem. In order to locate a repository you first have to know something about the repository -- the publisher's namespace URI from your example. In my experience discovery is more likely to be based on search criteria: affected platform, guidance source, supported languages, content formats, regulation applicability (SOX, HIPAA, etc), and so on. That's more like a searchable registry -- I don't see where DNS-style name resolution comes into it. --gun On 5/18/2012 8:42 AM, Waltermire, David A. wrote: > My comments marked with [DAW2]. > > Sincerely, > Dave > > > -----Original Message----- > From: Chandrashekhar B [mailto:bchandra@secpod.com] > Sent: Friday, May 18, 2012 1:50 AM > To: Waltermire, David A.; 'Kurt Seifried' > Cc: sacm@ietf.org; SCAP-DEV > Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development > > My comments marked [CHA] > > Chandra. > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. > Sent: Friday, May 18, 2012 8:02 AM > To: Kurt Seifried > Cc: sacm@ietf.org > Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development > > Comments inline marked [DAW]. > > Sincerely, > Dave > > > -----Original Message----- > From: Kurt Seifried [mailto:kseifried@redhat.com] > Sent: Thursday, May 17, 2012 10:18 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Note: all opinions/comments are my own, not official Red Hat policy and so on. > > On 05/17/2012 07:19 PM, Waltermire, David A. wrote: >> Kurt, >> >> My assumption is that each organization would stand up a content >> repository based on this specification for their own authoritative >> content, content they produce. They would sign the content using >> their own private key. I haven't worked out an approach for public key >> distribution yet. It would be if we could use DNS or some other >> standardized key distribution mechanism. I am open to ideas. > > Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). > > [DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. > > [CHA: Yes, distributed network of repository, with may be a central registry. Even for a central registry, I feel we aren't there yet. Central repository or a registry would mean getting into operational aspects, who'll own, manage, control etc., So, limiting it to organizational repositories and content providers repository is good in my view.] > > [DAW2: This is why I am advocating for a federated system. With the right approach, we can avoid having to stand up a single central registry and all the operational and logistical aspects involved. Using the DNS SRV approach below, DNS essentially becomes the registry. Using DNS, every organization that produces content is able to point to the authoritative content repositories that they use to host their content. They can create as many namespaces as needed, by using sub-domains within their own domain(s). A SRV record would be associated with each sub-domain in this case.] > > As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. > > I'd like to hear other thoughts related to X.509.] > > [CHA: I am not sure if I understand the DNS resolution approach here completely, will anyway pose a question. If one content repository were to host a content authored by someone else and the namespace wasn't modified, may be for IP reasons. DNS namespace qualification would not work if I want to pick the content from this repository instead of the original author. Not sure if I am making sense :) ] > > [DAW2: I am modeling this approach after DNS. There are authoritative content servers that originate content. The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server. This is an analog to domains hosted by an authoritative DNS server. Here is a basic communication flow: > > 1) Client: sends request for content by ID to local, organizational content repository. > 2) Organizational repository: retrieve the requested content > a) If the namespace is a local namespace, return the content. > b) If the namespace is a foreign namespace, check if the content is in the local cache. > c) Lookup the DNS SRV record associated with the ID's namespace. > d) Dispatch a request to the foreign authoritative content repository based on the SRV record to retrieve the content > e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server. > 3) Organizational repository: respond to the client with the content > > This approach allows content for a given namespace to be managed by a single authoritative content repository. If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository. > > Access to local cache can (and probably should) be limited to IPs within an organization or thru the use of access controls to prevent leakage of cached content.] > >> It may also make sense to allow for counter signing of content to >> allow 3rd parties to sign content. Again, I have not worked out how >> best to do this. Any ideas? > > Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. > > [DAW: agreed.] > >> Related to restricting access to content, it is my hope that content >> is made freely available. For some kinds of content, it probably >> makes sense to support some kind of access control. This could be >> driven by commercialization of content or to restrict access to some >> content to authorized users within an organization. >> Client/Server certificates might be a mechanism to support this. > > I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: > > 1) be incompatible (and thus either removed, or an active problem) for many vendors/customers (I doubt any existing system for selling content will end up being super compatible with what you guys build) > 2) be unnecessary in most (if not almost all) cases > 3) add significantly to the overhead of building this and not add any real value to the actual problem space of securing machines > > For some idea of the scope of this type of problem check out > http://www.candlepinproject.org/ which provides subscription and > entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. > > TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. > > [DAW: Points well taken. I am interested in other thoughts on how best to address this. What I was recommending was looking more towards service authentication and less towards DRM. Maybe we don't address this in the first pass. Thoughts?] > > [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. > > In our repository, we have implemented a policy driven access control and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. > > So, service authentication is required to be standardized. For access control, may be an error condition if one is not allowed to fetch the content?] > > [DAW2: agreed. I see this as a minimal standardization approach.] > >> I hope this answers your questions. >> >> Sincerely, Dave >> >> >> -----Original Message----- From: Kurt Seifried >> [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM >> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for >> participants - Content Repository Specification Development >> >> On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >>> Good points. It makes sense to use the mechanisms provided by XML >>> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >>> underlying transport (e.g. TLS) to address as much of this as >>> possible. It may be desirable to provide mechanisms for >>> authentication to restrict access to content. This may also need to >>> be integrated into the underlying transport. >> I have some questions, asking off list, not sure if they are >> appropriate, if they are feel free to reply on the list. >> >> 1) if using XMLDsig who would be the signing authority? How secure >> would signing be (e.g. using a hardware card/appliance/etc?). >> Where would the key be published/would it be signed/etc? 2) You >> mention restricting access to content, why would the content need to >> be restricted? Are there IP issues I am unaware of? >> >> Thanks >> >>> Sincerely, Dave >> > - - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ > uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR > GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK > MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf > LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew > xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus > u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r > GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH > TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK > +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi > oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv > XCldnHSPS6O7qeRTgMtL > =QJsL > -----END PGP SIGNATURE----- > _______________________________________________ > 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 pkampana@cisco.com Fri May 18 10:32: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 E9C2521F85DD for ; Fri, 18 May 2012 10:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87DhYmivjeaZ for ; Fri, 18 May 2012 10:32:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 27C9D21F859E for ; Fri, 18 May 2012 10:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=2420; q=dns/txt; s=iport; t=1337362359; x=1338571959; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Kgbs/nlBcVT9YXO1Z4Qdn/8U2nxnEt+v2RMijzA+Xbo=; b=SiopspS+38lAoPXD7sOhyqviW/yBpWDOC2PsvsasdJptFnE+N4eZUywc d6laMsgJ0rz3V7I+dk9FZNBiVkszfoFicngQNfvvH1/Tlhc6JjP5EoUo3 s/5jHZUwGNLsoIZrXdVYy1XBrOgBvBj2dl9m/Q13O5sDgKzbg3ZbtmCFP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAO6Gtk+tJV2Z/2dsb2JhbABFozyQSYEHghUBAQEDAQgKARUCED8MAQMCCQ4BAgQBAQEnBxktCQgBAQQTCxAHh2cFnFKgB4p/hUYDjT6Vc4FkgwU X-IronPort-AV: E=Sophos;i="4.75,618,1330905600"; d="scan'208";a="84506346" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 18 May 2012 17:32:38 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4IHWctu006424; Fri, 18 May 2012 17:32:38 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 May 2012 12:32:38 -0500 Received: from WIN-ICH1QO6NCS6 ([64.102.220.177]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 May 2012 12:32:38 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Fri, 18 May 2012 13:31:36 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Fri, 18 May 2012 13:31:36 -0500 From: "Panos Kampanakis" To: "'Kurt Seifried'" References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB6780A.1030407@redhat.com> In-Reply-To: <4FB6780A.1030407@redhat.com> Date: Fri, 18 May 2012 13:31:34 -0400 Organization: Cisco Systems Inc. Message-ID: <009101cd351c$1271b290$375517b0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac01EuRTeVNgY88gTOKn8BcMvlGZRwACK/nQ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 18 May 2012 17:32:38.0519 (UTC) FILETIME=[38663070:01CD351C] Cc: 'SCAP-DEV' , "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 17:32:40 -0000 Are you saying that the scope of the draft should only be to - define the challenges to be addressed - introduce the Metadata Model - address the Federation or repository discovery problem Panos -----Original Message----- From: Kurt Seifried [mailto:kseifried@redhat.com] Sent: Friday, May 18, 2012 12:26 PM To: Panos Kampanakis Cc: 'Waltermire, David A.'; SCAP-DEV; sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development * PGP Signed by an unknown key On 05/17/2012 04:29 PM, Panos Kampanakis wrote: > Good starting point Dave. > > > > 2 thoughts: > > > > - Integrity and Confidentiality can certainly be addressed in this > spec. But XML has its own mechanisms to provide them. Thus the content > itself can provide Integrity and Confidentiality. I am not sure if the > spec should have Integrity and Confidentiality as required features. > > > > - Also, should the data Exchange mechanism be part of this draft? > For example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, > SOAP, REST as were suggested in SACM's alias before? What if I want to deliver it over IPSec? or using a push mechanism? or offline via encrypted USB key (not all hosts have connectivity)? Or I want to use a content delivery network (such as Akamai, or my own based on something like pulp) because I have 10,000 hosts? What if I have hosts that are not allowed to talk SSL (because I need to monitor the network for nefarious activity)? Defining the data delivery method for what is essentially a file specification strikes me as... bizarre. Again shouldn't this be left up to the end implementation? If you provide a REST/SOAP service (effectively something that talks HTTP) it's not like we don't have ways to secure it that are appropriate for pretty much any use case you can think of. Again, defining this in the spec means more over head, and incompatibility with anyone not doing it exactly that way. Leaving it up to the end implementation makes way more sense as different people have different AIC/etc requirements, and again in this problem space we have many well understood solutions. > > > Rgs, > > Panos -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 * Unknown Key * 0x5E267993(L) From gunnar.engelbach@threatguard.com Fri May 18 10:50:29 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 F031E21F8712 for ; Fri, 18 May 2012 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.581 X-Spam-Level: * X-Spam-Status: No, score=1.581 tagged_above=-999 required=5 tests=[MISSING_HEADERS=1.581] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wgxuztkRGjY for ; Fri, 18 May 2012 10:50:28 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0D44521F8711 for ; Fri, 18 May 2012 10:50:25 -0700 (PDT) Received: (qmail 15290 invoked from network); 18 May 2012 11:53:45 -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); 18 May 2012 11:53:45 -0700 Message-ID: <4FB68BE8.2080606@ThreatGuard.com> Date: Fri, 18 May 2012 13:50:32 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> <4FB667D5.2040906@ThreatGuard.com> <4FB67BB1.6000106@redhat.com> In-Reply-To: <4FB67BB1.6000106@redhat.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development 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, 18 May 2012 17:50:29 -0000 On 5/18/2012 12:41 PM, Kurt Seifried wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/18/2012 09:16 AM, Gunnar Engelbach wrote: >> >> There are limitations in encoding requests using an HTTP GET, such >> as a maximum URI length, but most webservers support 8KB URLs, so >> the drawback to using a GET is the ability to send a structured >> request or to embed binary data. Most of the time I think you'll >> find that a query can be parameterized into a URL, which makes it a >> nice lightweight request format, but if not REST also allows for >> the use of a POST where the content structure is arbitrary and the >> typical limit is more like 2GB. >> >> >> A consideration for using JSON is that JSON data is actually code >> objects that are evaluated on the receiving end by executing them, >> so they are a potential attack vector. Using JSON means either >> having complete trust in the sender of the JSON objects or having >> complete trust in your ability to detect attack code on the >> receiving end. >> >> >> --gun > > This is not true. Perhaps you are thinking of JavaScript and using the > eval() method to parse the JSON data? Which you shouldn't be doing. > Pretty much all other JSON decoders don't do anything as remotely > crazy as running the input straight through eval(). > > JSON simply allows you to encode numbers, strings, booleans, arrays, > objects (key:value pairs) and null. Nothing magic. Unless you do > something crazy like shove the untrusted input straight through eval() > or blindly use the input without some minimal filtering (e.g. escaping > it for SQL queries) you should be fine. So used that way, as a text document that groups name/value pairs, what would be the reason for using JSON over XML? > > > - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtnuxAAoJEBYNRVNeJnmTATMP/RNrGLnnHx41e/Z2e7uQVTcM > p0bfBg8U7KQhE9c6cgwt9A+0CZ5RsihYSfEYgf3ryXZ8R9iZPbUO+fgEWZbS/G7b > wXJI9PMtwdOQPjH6+yq9ET/3usDKTLHZ4c0wJrpdeGb4HaKJG89fmZuOMimMfzxr > s7f6+sQLND5r5mQ+Y6mqvC//YCcm9BSkq8G5l/Ra5sADadCuPro2NI5pZI5Et/cz > lQCewnk2EhTZQr8ne12dUxFs22tyNafyYkkCLUIi4bPVuovqoe2qCpK3CL99mMsR > bfmCsiCDUXq87SuEIu/0si43eIgeMcnvI1bgPTWyuXuRIf4S/wz3zgWJhD4oiUvb > cGL4Fb6HvpegRa5mHVUhd7pnlo/RzoCO5K1XHnUHg+0qQwFqUx75mcxUijJxErOQ > eMP/7qBFfs6kdCNB+Uut2vtfGhbzoQ1qjTkTDVt1bBjP6KAX1nUzCZZfV1WpoN4d > B6fPTw83PyPotvKI8as9ZIk5TO3BPuEvuggQjR28h8pwX2D3KWQtLdi6QEavFD0P > 499h3u1nwnSVm922U/BpNMvwYnHDY/Q6KCsUzIoCRmMo8CXoGTyjWhEMocjZVmlX > pmR80rmxyzEiK9aLTZb9IO8XhM9oPyALF57m8tYbupN+NlSiyCAvIbcciK/GE9qz > hDNlxW1RQB51+Jv5M/2P > =lDW+ > -----END PGP SIGNATURE----- From pkampana@cisco.com Fri May 18 10:57: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 3036A21F8474 for ; Fri, 18 May 2012 10:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVjacOWtAWMP for ; Fri, 18 May 2012 10:57:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 855BE21F8453 for ; Fri, 18 May 2012 10:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=2405; q=dns/txt; s=iport; t=1337363822; x=1338573422; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=g7D0z0QAmP/HvHk0f3lcavQB5ccjHXvNK8wdsHnzU6k=; b=h8M7X3tYbcEQvGc0EK/7P49JX+nYHSkWrwO5Q0hiTG+ELNwWMaWNdgCp zraPm789aZ7UFk8CE1PzbWAVa7RcyqFxDb9gG9+d2Sl64U6FAu58mnA4w Ut0YyRGYK1V5YJ+GiblDdB5MOjUeZg0mIBqLoznUM3x4vrwo+20lcr/4q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGOMtk+tJV2Z/2dsb2JhbABFozyQSYEHghUBAQEECAoBFQIQPwwBAwIJDgECBAEBARgPBxktCQgBAQQTCxAHh2ycVaAFin+CKoMcA40+lXOBZIMF X-IronPort-AV: E=Sophos;i="4.75,618,1330905600"; d="scan'208";a="84553434" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 18 May 2012 17:57:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4IHv19O029062; Fri, 18 May 2012 17:57:01 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 May 2012 12:57:01 -0500 Received: from WIN-ICH1QO6NCS6 ([64.102.220.177]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 May 2012 12:57:01 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Fri, 18 May 2012 13:56:00 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Fri, 18 May 2012 13:56:00 -0500 From: "Panos Kampanakis" To: "'Kurt Seifried'" References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB6780A.1030407@redhat.com> <009101cd351c$1271b290$375517b0$@com> <4FB68CD0.4030803@redhat.com> In-Reply-To: <4FB68CD0.4030803@redhat.com> Date: Fri, 18 May 2012 13:55:58 -0400 Organization: Cisco Systems Inc. Message-ID: <009201cd351f$7b108170$71318450$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac01H01BEOIGt0gyRIOabGMz+dAQ5QAAAP7Q Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 18 May 2012 17:57:01.0715 (UTC) FILETIME=[A0882E30:01CD351F] Cc: 'SCAP-DEV' , "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 17:57:03 -0000 I see now. And agree. -----Original Message----- From: Kurt Seifried [mailto:kseifried@redhat.com] Sent: Friday, May 18, 2012 1:54 PM To: Panos Kampanakis Cc: 'Waltermire, David A.'; 'SCAP-DEV'; sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development * PGP Signed by an unknown key On 05/18/2012 11:31 AM, Panos Kampanakis wrote: > Are you saying that the scope of the draft should only be to > > - define the challenges to be addressed - introduce the Metadata Model > - address the Federation or repository discovery problem > > Panos No. I am saying that defining something "We will use SOAP/REST with XML/JSON (pick some combination thereof, or something else, whatever)" make sense. Defining "you MUST deliver this over SSL encrypted HTTP" makes no sense because for one thing I know there are sites that can't use SSL, or use something like IPSec instead, or need an offline manner that works well, or need a push method, and so on. As I understand this problem it's basically a file delivery/information delivery issue. So file format, etc. Defining how the file is delivered, how authentication is done, etc, seems outside the scope of this (and there are lots of great existing solutions). I suspect these issues should be left up to implementation/vendors/etc to address the specific use cases. E.g. if you guys choose to put authentication in the spec will you support: username/password (what auth backend do you support/use? something internal?) OTP? Kerberos? NTLM? LDAP? X.509 client certs? Combinations of the above (e.g. an X.509 cert + OTP is required)? For discovery, what about LDAP? DNS? UPnP? Bonjour? How do you prevent a bad guy from spoofing/etc? How do you authenticate the server to the client (to ensure clients connect to a legit server)? My fear is that any specification in these lower level layers will cause incompatibilities and overhead in the devel/spec/building process that don't actually create any real benefit. All of these issues have a wide variety of solutions appropriate for various use cases, I think it should be left to the end vendor/user to decide appropriately. -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 * Unknown Key * 0x5E267993(L) From kseifried@redhat.com Fri May 18 09:25:53 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 37BC521F869F for ; Fri, 18 May 2012 09:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmeeBUqnJ7-i for ; Fri, 18 May 2012 09:25:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6421F8686 for ; Fri, 18 May 2012 09:25:52 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IGPp4n032299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 12:25:51 -0400 Received: from seif-rht-f16.edm.seifried.org (ovpn-112-30.phx2.redhat.com [10.3.112.30]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4IGPnEX014843; Fri, 18 May 2012 12:25:49 -0400 Message-ID: <4FB6780A.1030407@redhat.com> Date: Fri, 18 May 2012 10:25:46 -0600 From: Kurt Seifried User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Panos Kampanakis References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> In-Reply-To: <015d01cd347c$921ebf10$b65c3d30$@com> X-Enigmail-Version: 1.4.1 OpenPGP: id=5E267993 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Mailman-Approved-At: Fri, 18 May 2012 11:17:06 -0700 Cc: SCAP-DEV , "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 16:25:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/17/2012 04:29 PM, Panos Kampanakis wrote: > Good starting point Dave. > > > > 2 thoughts: > > > > - Integrity and Confidentiality can certainly be addressed in this > spec. But XML has its own mechanisms to provide them. Thus the > content itself can provide Integrity and Confidentiality. I am not > sure if the spec should have Integrity and Confidentiality as > required features. > > > > - Also, should the data Exchange mechanism be part of this draft? > For example HTTP/TLS messages etc (as in MILE’s rfc6546) or JSON, > SOAP, REST as were suggested in SACM’s alias before? What if I want to deliver it over IPSec? or using a push mechanism? or offline via encrypted USB key (not all hosts have connectivity)? Or I want to use a content delivery network (such as Akamai, or my own based on something like pulp) because I have 10,000 hosts? What if I have hosts that are not allowed to talk SSL (because I need to monitor the network for nefarious activity)? Defining the data delivery method for what is essentially a file specification strikes me as... bizarre. Again shouldn't this be left up to the end implementation? If you provide a REST/SOAP service (effectively something that talks HTTP) it's not like we don't have ways to secure it that are appropriate for pretty much any use case you can think of. Again, defining this in the spec means more over head, and incompatibility with anyone not doing it exactly that way. Leaving it up to the end implementation makes way more sense as different people have different AIC/etc requirements, and again in this problem space we have many well understood solutions. > > > Rgs, > > Panos - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtngKAAoJEBYNRVNeJnmTp9sP/3AqHsyjqi6RWsBhBhVzcnlP groJjdeywc6OJ+ETDizriYQ9t3qODl9pp3xN/zbJlXMT3Wr2Yvqp6Wp4K4CiB15X iYNRwo/IS7R4j76mBUmJi484VgUavPGsHiVLBJ7y4hOkI9oIfyt5s8+Xacb7senR +mHrD8st83eK8LVb+IGRRmmGOitRzoKJu08nV1Eq4uJxdiqsnK3RYBqgYiBYbveB YtCYL45/EzkLaZVhrlSP84Rv2jN6McI9Tqrg2Td5deSmsaibTv/ODtwAI+CYAICx nqcn2+r8XFxElV+AWS6/41ZtGdjHYGHPULtXqeT2W5SKJXKHSr9FPWojyM6n5rot sDRFSOkCsNaidzc2UeWtahgZrcigr7WCxrHN/FmiCCJin2L2g+xgEpC+uibGCmIT pPxibJMtGxra9GaU90YW+eZInotz7knBAdGEWvmsKEjGUtDa4ThmmfKqzciWt4Hc zUM9e0GXb3ZulxmZfM7hrAMXG6TWvJeWth1KhYFHC2H7LMZgKH+qG2WYPmXHG285 Skqq/uoEM7p03RAZIa2O5fn3WfpRN/dSBCPs1iDBUJZ0bCobNOk9UkCgQ9ICyPBN tFmT8c7AnEPFTolEc7cysEJzZZIRt0QGBMvunswRSLPLGw4Z8mqVQXTFb2QvxE/R obBI4V5On2OUSsraJPvn =Crjl -----END PGP SIGNATURE----- From kseifried@redhat.com Fri May 18 09:41: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 82EBC21F8742 for ; Fri, 18 May 2012 09:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFCdLoI0DHJ2 for ; Fri, 18 May 2012 09:41:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5314921F86F7 for ; Fri, 18 May 2012 09:41:25 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IGfOw1031189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 12:41:24 -0400 Received: from seif-rht-f16.edm.seifried.org (ovpn-112-30.phx2.redhat.com [10.3.112.30]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4IGfMeU017645; Fri, 18 May 2012 12:41:23 -0400 Message-ID: <4FB67BB1.6000106@redhat.com> Date: Fri, 18 May 2012 10:41:21 -0600 From: Kurt Seifried User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gunnar Engelbach References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> <4FB667D5.2040906@ThreatGuard.com> In-Reply-To: <4FB667D5.2040906@ThreatGuard.com> X-Enigmail-Version: 1.4.1 OpenPGP: id=5E267993 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Mailman-Approved-At: Fri, 18 May 2012 11:17:06 -0700 Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development 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, 18 May 2012 16:41:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/18/2012 09:16 AM, Gunnar Engelbach wrote: > > There are limitations in encoding requests using an HTTP GET, such > as a maximum URI length, but most webservers support 8KB URLs, so > the drawback to using a GET is the ability to send a structured > request or to embed binary data. Most of the time I think you'll > find that a query can be parameterized into a URL, which makes it a > nice lightweight request format, but if not REST also allows for > the use of a POST where the content structure is arbitrary and the > typical limit is more like 2GB. > > > A consideration for using JSON is that JSON data is actually code > objects that are evaluated on the receiving end by executing them, > so they are a potential attack vector. Using JSON means either > having complete trust in the sender of the JSON objects or having > complete trust in your ability to detect attack code on the > receiving end. > > > --gun This is not true. Perhaps you are thinking of JavaScript and using the eval() method to parse the JSON data? Which you shouldn't be doing. Pretty much all other JSON decoders don't do anything as remotely crazy as running the input straight through eval(). JSON simply allows you to encode numbers, strings, booleans, arrays, objects (key:value pairs) and null. Nothing magic. Unless you do something crazy like shove the untrusted input straight through eval() or blindly use the input without some minimal filtering (e.g. escaping it for SQL queries) you should be fine. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtnuxAAoJEBYNRVNeJnmTATMP/RNrGLnnHx41e/Z2e7uQVTcM p0bfBg8U7KQhE9c6cgwt9A+0CZ5RsihYSfEYgf3ryXZ8R9iZPbUO+fgEWZbS/G7b wXJI9PMtwdOQPjH6+yq9ET/3usDKTLHZ4c0wJrpdeGb4HaKJG89fmZuOMimMfzxr s7f6+sQLND5r5mQ+Y6mqvC//YCcm9BSkq8G5l/Ra5sADadCuPro2NI5pZI5Et/cz lQCewnk2EhTZQr8ne12dUxFs22tyNafyYkkCLUIi4bPVuovqoe2qCpK3CL99mMsR bfmCsiCDUXq87SuEIu/0si43eIgeMcnvI1bgPTWyuXuRIf4S/wz3zgWJhD4oiUvb cGL4Fb6HvpegRa5mHVUhd7pnlo/RzoCO5K1XHnUHg+0qQwFqUx75mcxUijJxErOQ eMP/7qBFfs6kdCNB+Uut2vtfGhbzoQ1qjTkTDVt1bBjP6KAX1nUzCZZfV1WpoN4d B6fPTw83PyPotvKI8as9ZIk5TO3BPuEvuggQjR28h8pwX2D3KWQtLdi6QEavFD0P 499h3u1nwnSVm922U/BpNMvwYnHDY/Q6KCsUzIoCRmMo8CXoGTyjWhEMocjZVmlX pmR80rmxyzEiK9aLTZb9IO8XhM9oPyALF57m8tYbupN+NlSiyCAvIbcciK/GE9qz hDNlxW1RQB51+Jv5M/2P =lDW+ -----END PGP SIGNATURE----- From kseifried@redhat.com Fri May 18 10:54: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 01F2221F86F7 for ; Fri, 18 May 2012 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108 X-Spam-Level: X-Spam-Status: No, score=-108 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFl5M8qCCIso for ; Fri, 18 May 2012 10:54:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8069A21F86C1 for ; Fri, 18 May 2012 10:54:28 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IHsQEQ006598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 13:54:26 -0400 Received: from seif-rht-f16.edm.seifried.org (ovpn-112-30.phx2.redhat.com [10.3.112.30]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4IHsOg9026642; Fri, 18 May 2012 13:54:25 -0400 Message-ID: <4FB68CD0.4030803@redhat.com> Date: Fri, 18 May 2012 11:54:24 -0600 From: Kurt Seifried User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Panos Kampanakis References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB6780A.1030407@redhat.com> <009101cd351c$1271b290$375517b0$@com> In-Reply-To: <009101cd351c$1271b290$375517b0$@com> X-Enigmail-Version: 1.4.1 OpenPGP: id=5E267993 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Mailman-Approved-At: Fri, 18 May 2012 11:17:06 -0700 Cc: 'SCAP-DEV' , "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 17:54:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/18/2012 11:31 AM, Panos Kampanakis wrote: > Are you saying that the scope of the draft should only be to > > - define the challenges to be addressed - introduce the Metadata > Model - address the Federation or repository discovery problem > > Panos No. I am saying that defining something "We will use SOAP/REST with XML/JSON (pick some combination thereof, or something else, whatever)" make sense. Defining "you MUST deliver this over SSL encrypted HTTP" makes no sense because for one thing I know there are sites that can't use SSL, or use something like IPSec instead, or need an offline manner that works well, or need a push method, and so on. As I understand this problem it's basically a file delivery/information delivery issue. So file format, etc. Defining how the file is delivered, how authentication is done, etc, seems outside the scope of this (and there are lots of great existing solutions). I suspect these issues should be left up to implementation/vendors/etc to address the specific use cases. E.g. if you guys choose to put authentication in the spec will you support: username/password (what auth backend do you support/use? something internal?) OTP? Kerberos? NTLM? LDAP? X.509 client certs? Combinations of the above (e.g. an X.509 cert + OTP is required)? For discovery, what about LDAP? DNS? UPnP? Bonjour? How do you prevent a bad guy from spoofing/etc? How do you authenticate the server to the client (to ensure clients connect to a legit server)? My fear is that any specification in these lower level layers will cause incompatibilities and overhead in the devel/spec/building process that don't actually create any real benefit. All of these issues have a wide variety of solutions appropriate for various use cases, I think it should be left to the end vendor/user to decide appropriately. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtozQAAoJEBYNRVNeJnmT8wkP/29xzsZm/LepuX0mpdHZGfLz 9RiEzcQAsLIdjYjizrP38FFocz40n3klTdBvFL8rjt9JkjDyGxQXtWthMJFpGwJr mWP8wJsTZb2Ocy37V+RD80aGfmvx3PgGbZ4xUc75+co53uliA5L65J4gTf9lR0Wr KD6qY2YPzNq+NFCNZSVNr1+mz100ETvtCDXIEKv716jZL0ivgzMriC1ne/EsRFxl ijtyAobBo7knmUhxomL9/PRtOYNWpc0ntwcV/Kd4whbdtd91K/Yw2VTHvKJr9ZKz 6t5QSrMqasxyZ8Ketj9NCovefh5nIVP+MXKfTFPigav/Aa1+pV7wYcOWn52f97+8 0ACvJgxsI3DWFE+GhQEtqkjm9c2rtdYRgWPavW/+UZHcTq1iLKSNEgr2r7F+C1HO b1QPymx5fhYtmAiM/tS5do4betYO5wFrsdXzw8vIB3xBfo6G1tPfwlAb9TgBvMFp UN0ZQTIYtbR7XPatSS13/nIw9KauCd5WYPwheP9wJeZkS22RJ0Buqacr+F6ZDHom AkwmyQO4rxzzFvkahFOaqRHZ5YFwoeUjrpT0wTuwwv+xuYFu7yN4gyZgH7im+ML3 E7Zo459vvQTQ1caNnPuauBqvqPD7IbCFew31M/bfGfQ/Hjg2wOqxqzGUL6/Fo22M YoRrr9GInLjDnyeJKpRw =qbme -----END PGP SIGNATURE----- From pati.mcgaffigan@defenseweb.com Fri May 18 10:11: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 C0C5A21F863B for ; Fri, 18 May 2012 10:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzDLZM3ga-nP for ; Fri, 18 May 2012 10:11:37 -0700 (PDT) Received: from smtp1.defenseweb.net (smtp1.defenseweb.net [216.240.186.15]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7721F8623 for ; Fri, 18 May 2012 10:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp1.defenseweb.net (Postfix) with ESMTP id 492BC2180D; Fri, 18 May 2012 10:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at defenseweb.com Received: from smtp1.defenseweb.net ([127.0.0.1]) by localhost (smtp1.defenseweb.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpwaNTZN5d7i; Fri, 18 May 2012 10:11:25 -0700 (PDT) Received: from mail2.sd.defenseweb.net (rrcs-76-79-211-2.west.biz.rr.com [76.79.211.2]) by smtp1.defenseweb.net (Postfix) with ESMTP id 136BE2075E; Fri, 18 May 2012 10:11:15 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3519.3B7417AA" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 18 May 2012 10:11:15 -0700 Message-ID: <53E1C7530C106845AC2322AA3CB5293C2E9E4B@mail2.sd.defenseweb.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [scap-dev] [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac01E2m/uc7kjz6dRUaCrg9lm8LG5gABdFLA From: "Pati McGaffigan" To: "Kurt Seifried" , "Panos Kampanakis" X-Mailman-Approved-At: Fri, 18 May 2012 11:17:14 -0700 Cc: SCAP-DEV , "David A.'" , sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 18 May 2012 17:12:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3519.3B7417AA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHJlbW92ZSBmcm9tIGRpc3RyaWJ1dGlvbg0KDQpQYXRpIE1jR2FmZmlnYW4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEt1cnQgU2VpZnJpZWQgW2tzZWlmcmllZEBy ZWRoYXQuY29tXQ0KU2VudDogRnJpZGF5LCBNYXkgMTgsIDIwMTIgMDk6MjkgQU0gUGFjaWZpYyBT dGFuZGFyZCBUaW1lDQpUbzogUGFub3MgS2FtcGFuYWtpcw0KQ2M6IFNDQVAtREVWOyAnV2FsdGVy bWlyZSwgRGF2aWQgQS4nOyBzYWNtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NjYXAtZGV2XSBb c2FjbV0gUmVxdWVzdCBmb3IgcGFydGljaXBhbnRzIC0gQ29udGVudCBSZXBvc2l0b3J5IFNwZWNp ZmljYXRpb24gRGV2ZWxvcG1lbnQNCg0KDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdF LS0tLS0NCkhhc2g6IFNIQTENCg0KT24gMDUvMTcvMjAxMiAwNDoyOSBQTSwgUGFub3MgS2FtcGFu YWtpcyB3cm90ZToNCj4gR29vZCBzdGFydGluZyBwb2ludCBEYXZlLg0KPg0KPg0KPg0KPiAyIHRo b3VnaHRzOg0KPg0KPg0KPg0KPiAtIEludGVncml0eSBhbmQgQ29uZmlkZW50aWFsaXR5IGNhbiBj ZXJ0YWlubHkgYmUgYWRkcmVzc2VkIGluIHRoaXMNCj4gc3BlYy4gQnV0IFhNTCBoYXMgaXRzIG93 biBtZWNoYW5pc21zIHRvIHByb3ZpZGUgdGhlbS4gVGh1cyB0aGUNCj4gY29udGVudCBpdHNlbGYg Y2FuIHByb3ZpZGUgSW50ZWdyaXR5IGFuZCBDb25maWRlbnRpYWxpdHkuIEkgYW0gbm90DQo+IHN1 cmUgaWYgdGhlIHNwZWMgc2hvdWxkIGhhdmUgSW50ZWdyaXR5IGFuZCBDb25maWRlbnRpYWxpdHkg YXMNCj4gcmVxdWlyZWQgZmVhdHVyZXMuDQo+DQo+DQo+DQo+IC0gQWxzbywgc2hvdWxkIHRoZSBk YXRhIEV4Y2hhbmdlIG1lY2hhbmlzbSBiZSBwYXJ0IG9mIHRoaXMgZHJhZnQ/DQo+IEZvciBleGFt cGxlIEhUVFAvVExTIG1lc3NhZ2VzIGV0YyAoYXMgaW4gTUlMReKAmXMgcmZjNjU0Nikgb3IgSlNP TiwNCj4gU09BUCwgUkVTVCBhcyB3ZXJlIHN1Z2dlc3RlZCBpbiBTQUNN4oCZcyBhbGlhcyBiZWZv cmU/DQoNCldoYXQgaWYgSSB3YW50IHRvIGRlbGl2ZXIgaXQgb3ZlciBJUFNlYz8gb3IgdXNpbmcg YSBwdXNoIG1lY2hhbmlzbT8gb3INCm9mZmxpbmUgdmlhIGVuY3J5cHRlZCBVU0Iga2V5IChub3Qg YWxsIGhvc3RzIGhhdmUgY29ubmVjdGl2aXR5KT8gT3IgSQ0Kd2FudCB0byB1c2UgYSBjb250ZW50 IGRlbGl2ZXJ5IG5ldHdvcmsgKHN1Y2ggYXMgQWthbWFpLCBvciBteSBvd24NCmJhc2VkIG9uIHNv bWV0aGluZyBsaWtlIHB1bHApIGJlY2F1c2UgSSBoYXZlIDEwLDAwMCBob3N0cz8gV2hhdCBpZiBJ DQpoYXZlIGhvc3RzIHRoYXQgYXJlIG5vdCBhbGxvd2VkIHRvIHRhbGsgU1NMIChiZWNhdXNlIEkg bmVlZCB0byBtb25pdG9yDQp0aGUgbmV0d29yayBmb3IgbmVmYXJpb3VzIGFjdGl2aXR5KT8NCg0K RGVmaW5pbmcgdGhlIGRhdGEgZGVsaXZlcnkgbWV0aG9kIGZvciB3aGF0IGlzIGVzc2VudGlhbGx5 IGEgZmlsZQ0Kc3BlY2lmaWNhdGlvbiBzdHJpa2VzIG1lIGFzLi4uIGJpemFycmUuIEFnYWluIHNo b3VsZG4ndCB0aGlzIGJlIGxlZnQNCnVwIHRvIHRoZSBlbmQgaW1wbGVtZW50YXRpb24/DQoNCklm IHlvdSBwcm92aWRlIGEgUkVTVC9TT0FQIHNlcnZpY2UgKGVmZmVjdGl2ZWx5IHNvbWV0aGluZyB0 aGF0IHRhbGtzDQpIVFRQKSBpdCdzIG5vdCBsaWtlIHdlIGRvbid0IGhhdmUgd2F5cyB0byBzZWN1 cmUgaXQgdGhhdCBhcmUNCmFwcHJvcHJpYXRlIGZvciBwcmV0dHkgbXVjaCBhbnkgdXNlIGNhc2Ug eW91IGNhbiB0aGluayBvZi4gQWdhaW4sDQpkZWZpbmluZyB0aGlzIGluIHRoZSBzcGVjIG1lYW5z IG1vcmUgb3ZlciBoZWFkLCBhbmQgaW5jb21wYXRpYmlsaXR5DQp3aXRoIGFueW9uZSBub3QgZG9p bmcgaXQgZXhhY3RseSB0aGF0IHdheS4gTGVhdmluZyBpdCB1cCB0byB0aGUgZW5kDQppbXBsZW1l bnRhdGlvbiBtYWtlcyB3YXkgbW9yZSBzZW5zZSBhcyBkaWZmZXJlbnQgcGVvcGxlIGhhdmUgZGlm ZmVyZW50DQpBSUMvZXRjIHJlcXVpcmVtZW50cywgYW5kIGFnYWluIGluIHRoaXMgcHJvYmxlbSBz cGFjZSB3ZSBoYXZlIG1hbnkNCndlbGwgdW5kZXJzdG9vZCBzb2x1dGlvbnMuDQoNCj4NCj4NCj4g UmdzLA0KPg0KPiBQYW5vcw0KDQoNCi0gLS0NCkt1cnQgU2VpZnJpZWQgUmVkIEhhdCBTZWN1cml0 eSBSZXNwb25zZSBUZWFtIChTUlQpDQpQR1A6IDB4NUUyNjc5OTMgQTkwQiBGOTk1IDczNTAgMTQ4 RiA2NkJGIDc1NTQgMTYwRCA0NTUzIDVFMjYgNzk5Mw0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRV UkUtLS0tLQ0KVmVyc2lvbjogR251UEcgdjEuNC4xMiAoR05VL0xpbnV4KQ0KQ29tbWVudDogVXNp bmcgR251UEcgd2l0aCBNb3ppbGxhIC0gaHR0cDovL2VuaWdtYWlsLm1vemRldi5vcmcvDQoNCmlR SWNCQUVCQWdBR0JRSlB0bmdLQUFvSkVCWU5SVk5lSm5tVHA5c1AvM0FxSHN5anFpNlJXc0JoQmhW emNubFANCmdyb0pqZGV5d2M2T0orRVREaXpyaVlROXQzcU9EbDlwcDN4Ti96YkpsWE1UM1dyMll2 cXA2V3A0SzRDaUIxNVgNCmlZTlJ3by9JUzdSNGo3Nm1CVW1KaTQ4NFZnVWF2UEdzSGlWTEJKN3k0 aE9rSTlvSWZ5dDVzOCtYYWNiN3NlblINCittSHJEOHN0ODNlSzhMVmIrSUdSUm1tR09pdFJ6b0tK dTA4blYxRXE0dUp4ZGlxc25LM1JZQnFnWWlCWWJ2ZUINCll0Q1lMNDUvRXprTGFaVmhybFNQODRS djJqTjZNY0k5VHFyZzJUZDVkZVNtc2FpYlR2L09EdHdBSStDWUFJQ3gNCm5xY24yK3I4WEZ4RWxW K0FXUzYvNDFadEdkakhZR0hQVUx0WHFlVDJXNVNLSlhLSFNyOUZQV29qeU02bjVyb3QNCnNEUkZT T2tDc05haWR6YzJVZVd0YWhnWnJjaWdyN1dDeHJITi9GbWlDQ0ppbjJMMmcreGdFcEMrdWliR0Nt SVQNCnBQeGliSk10R3hyYTlHYVU5MFlXK2VaSW5vdHo3a25CQWRHRVd2bXNLRWpHVXREYTRUaG1t ZktxemNpV3Q0SGMNCnpVTTllMEdYYjNadWx4bVpmTTdockFNWEc2VFd2SmVXdGgxS2hZRkhDMkg3 TE1aZ0tIK3FHMldZUG1YSEcyODUNClNrcXEvdW9FTTdwMDNSQVpJYTJPNWZuM1dmcFJOL2RTQkNQ czFpREJVSlowYkNvYk5PazlVa0NnUTlJQ3lQQk4NCnRGbVQ4YzdBbkVQRlRvbEVjN2N5c0VKelpa SVJ0MFFHQk12dW5zd1JTTFBMR3c0WjhtcVZRWFRGYjJRdnhFL1INCm9iQkk0VjVPbjJPVVNzcmFK UHZuDQo9Q3JqbA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NhcC1kZXYgbWFpbGluZyBsaXN0DQpz Y2FwLWRldkBuaXN0Lmdvdg0KVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0 byBzY2FwLWRldi11bnN1YnNjcmliZUBuaXN0Lmdvdi4NCg0KDQo= ------_=_NextPart_001_01CD3519.3B7417AA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTQuMTIiPg0KPFRJVExFPlJlOiBbc2NhcC1k ZXZdIFtzYWNtXSBSZXF1ZXN0IGZvciBwYXJ0aWNpcGFudHMgLSBDb250ZW50IFJlcG9zaXRvcnkg U3BlY2lmaWNhdGlvbiBEZXZlbG9wbWVudDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NUGxlYXNl IHJlbW92ZSBmcm9tIGRpc3RyaWJ1dGlvbjxicj48YnI+UGF0aSBNY0dhZmZpZ2FuPGJyPg08YnI+ DSAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NPGI+RnJvbTombmJzcDs8L2I+S3VydCBT ZWlmcmllZCBbPGEgaHJlZj0ibWFpbHRvOmtzZWlmcmllZEByZWRoYXQuY29tIj5rc2VpZnJpZWRA cmVkaGF0LmNvbTwvYT5dPGJyPg08Yj5TZW50OiZuYnNwOzwvYj5GcmlkYXksIE1heSAxOCwgMjAx MiAwOToyOSBBTSBQYWNpZmljIFN0YW5kYXJkIFRpbWU8YnI+DTxiPlRvOiZuYnNwOzwvYj5QYW5v cyBLYW1wYW5ha2lzPGJyPg08Yj5DYzombmJzcDs8L2I+U0NBUC1ERVY7ICdXYWx0ZXJtaXJlLAlE YXZpZCBBLic7IHNhY21AaWV0Zi5vcmc8YnI+DTxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJlOiBbc2Nh cC1kZXZdIFtzYWNtXSBSZXF1ZXN0IGZvciBwYXJ0aWNpcGFudHMgLSBDb250ZW50IFJlcG9zaXRv cnkgU3BlY2lmaWNhdGlvbiBEZXZlbG9wbWVudDxicj4NPGJyPg0NCjwhLS0gQ29udmVydGVkIGZy b20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLUJFR0lOIFBH UCBTSUdORUQgTUVTU0FHRS0tLS0tPEJSPg0KSGFzaDogU0hBMTxCUj4NCjxCUj4NCk9uIDA1LzE3 LzIwMTIgMDQ6MjkgUE0sIFBhbm9zIEthbXBhbmFraXMgd3JvdGU6PEJSPg0KJmd0OyBHb29kIHN0 YXJ0aW5nIHBvaW50IERhdmUuPEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0 OyAyIHRob3VnaHRzOjxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDsgLSBJ bnRlZ3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBjYW4gY2VydGFpbmx5IGJlIGFkZHJlc3NlZCBp biB0aGlzPEJSPg0KJmd0OyBzcGVjLiBCdXQgWE1MIGhhcyBpdHMgb3duIG1lY2hhbmlzbXMgdG8g cHJvdmlkZSB0aGVtLiBUaHVzIHRoZTxCUj4NCiZndDsgY29udGVudCBpdHNlbGYgY2FuIHByb3Zp ZGUgSW50ZWdyaXR5IGFuZCBDb25maWRlbnRpYWxpdHkuIEkgYW0gbm90PEJSPg0KJmd0OyBzdXJl IGlmIHRoZSBzcGVjIHNob3VsZCBoYXZlIEludGVncml0eSBhbmQgQ29uZmlkZW50aWFsaXR5IGFz PEJSPg0KJmd0OyByZXF1aXJlZCBmZWF0dXJlcy48QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZn dDs8QlI+DQomZ3Q7IC0gQWxzbywgc2hvdWxkIHRoZSBkYXRhIEV4Y2hhbmdlIG1lY2hhbmlzbSBi ZSBwYXJ0IG9mIHRoaXMgZHJhZnQ/PEJSPg0KJmd0OyBGb3IgZXhhbXBsZSBIVFRQL1RMUyBtZXNz YWdlcyBldGMgKGFzIGluIE1JTEXigJlzIHJmYzY1NDYpIG9yIEpTT04sPEJSPg0KJmd0OyBTT0FQ LCBSRVNUIGFzIHdlcmUgc3VnZ2VzdGVkIGluIFNBQ03igJlzIGFsaWFzIGJlZm9yZT88QlI+DQo8 QlI+DQpXaGF0IGlmIEkgd2FudCB0byBkZWxpdmVyIGl0IG92ZXIgSVBTZWM/IG9yIHVzaW5nIGEg cHVzaCBtZWNoYW5pc20/IG9yPEJSPg0Kb2ZmbGluZSB2aWEgZW5jcnlwdGVkIFVTQiBrZXkgKG5v dCBhbGwgaG9zdHMgaGF2ZSBjb25uZWN0aXZpdHkpPyBPciBJPEJSPg0Kd2FudCB0byB1c2UgYSBj b250ZW50IGRlbGl2ZXJ5IG5ldHdvcmsgKHN1Y2ggYXMgQWthbWFpLCBvciBteSBvd248QlI+DQpi YXNlZCBvbiBzb21ldGhpbmcgbGlrZSBwdWxwKSBiZWNhdXNlIEkgaGF2ZSAxMCwwMDAgaG9zdHM/ IFdoYXQgaWYgSTxCUj4NCmhhdmUgaG9zdHMgdGhhdCBhcmUgbm90IGFsbG93ZWQgdG8gdGFsayBT U0wgKGJlY2F1c2UgSSBuZWVkIHRvIG1vbml0b3I8QlI+DQp0aGUgbmV0d29yayBmb3IgbmVmYXJp b3VzIGFjdGl2aXR5KT88QlI+DQo8QlI+DQpEZWZpbmluZyB0aGUgZGF0YSBkZWxpdmVyeSBtZXRo b2QgZm9yIHdoYXQgaXMgZXNzZW50aWFsbHkgYSBmaWxlPEJSPg0Kc3BlY2lmaWNhdGlvbiBzdHJp a2VzIG1lIGFzLi4uIGJpemFycmUuIEFnYWluIHNob3VsZG4ndCB0aGlzIGJlIGxlZnQ8QlI+DQp1 cCB0byB0aGUgZW5kIGltcGxlbWVudGF0aW9uPzxCUj4NCjxCUj4NCklmIHlvdSBwcm92aWRlIGEg UkVTVC9TT0FQIHNlcnZpY2UgKGVmZmVjdGl2ZWx5IHNvbWV0aGluZyB0aGF0IHRhbGtzPEJSPg0K SFRUUCkgaXQncyBub3QgbGlrZSB3ZSBkb24ndCBoYXZlIHdheXMgdG8gc2VjdXJlIGl0IHRoYXQg YXJlPEJSPg0KYXBwcm9wcmlhdGUgZm9yIHByZXR0eSBtdWNoIGFueSB1c2UgY2FzZSB5b3UgY2Fu IHRoaW5rIG9mLiBBZ2Fpbiw8QlI+DQpkZWZpbmluZyB0aGlzIGluIHRoZSBzcGVjIG1lYW5zIG1v cmUgb3ZlciBoZWFkLCBhbmQgaW5jb21wYXRpYmlsaXR5PEJSPg0Kd2l0aCBhbnlvbmUgbm90IGRv aW5nIGl0IGV4YWN0bHkgdGhhdCB3YXkuIExlYXZpbmcgaXQgdXAgdG8gdGhlIGVuZDxCUj4NCmlt cGxlbWVudGF0aW9uIG1ha2VzIHdheSBtb3JlIHNlbnNlIGFzIGRpZmZlcmVudCBwZW9wbGUgaGF2 ZSBkaWZmZXJlbnQ8QlI+DQpBSUMvZXRjIHJlcXVpcmVtZW50cywgYW5kIGFnYWluIGluIHRoaXMg cHJvYmxlbSBzcGFjZSB3ZSBoYXZlIG1hbnk8QlI+DQp3ZWxsIHVuZGVyc3Rvb2Qgc29sdXRpb25z LjxCUj4NCjxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBSZ3MsPEJSPg0KJmd0OzxCUj4N CiZndDsgUGFub3M8QlI+DQo8QlI+DQo8QlI+DQotIC0tPEJSPg0KS3VydCBTZWlmcmllZCBSZWQg SGF0IFNlY3VyaXR5IFJlc3BvbnNlIFRlYW0gKFNSVCk8QlI+DQpQR1A6IDB4NUUyNjc5OTMgQTkw QiBGOTk1IDczNTAgMTQ4RiA2NkJGIDc1NTQgMTYwRCA0NTUzIDVFMjYgNzk5MzxCUj4NCjxCUj4N Ci0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPEJSPg0KVmVyc2lvbjogR251UEcgdjEuNC4x MiAoR05VL0xpbnV4KTxCUj4NCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggTW96aWxsYSAtIDxB IEhSRUY9Imh0dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnLyI+aHR0cDovL2VuaWdtYWlsLm1vemRl di5vcmcvPC9BPjxCUj4NCjxCUj4NCmlRSWNCQUVCQWdBR0JRSlB0bmdLQUFvSkVCWU5SVk5lSm5t VHA5c1AvM0FxSHN5anFpNlJXc0JoQmhWemNubFA8QlI+DQpncm9KamRleXdjNk9KK0VURGl6cmlZ UTl0M3FPRGw5cHAzeE4vemJKbFhNVDNXcjJZdnFwNldwNEs0Q2lCMTVYPEJSPg0KaVlOUndvL0lT N1I0ajc2bUJVbUppNDg0VmdVYXZQR3NIaVZMQko3eTRoT2tJOW9JZnl0NXM4K1hhY2I3c2VuUjxC Uj4NCittSHJEOHN0ODNlSzhMVmIrSUdSUm1tR09pdFJ6b0tKdTA4blYxRXE0dUp4ZGlxc25LM1JZ QnFnWWlCWWJ2ZUI8QlI+DQpZdENZTDQ1L0V6a0xhWlZocmxTUDg0UnYyak42TWNJOVRxcmcyVGQ1 ZGVTbXNhaWJUdi9PRHR3QUkrQ1lBSUN4PEJSPg0KbnFjbjIrcjhYRnhFbFYrQVdTNi80MVp0R2Rq SFlHSFBVTHRYcWVUMlc1U0tKWEtIU3I5RlBXb2p5TTZuNXJvdDxCUj4NCnNEUkZTT2tDc05haWR6 YzJVZVd0YWhnWnJjaWdyN1dDeHJITi9GbWlDQ0ppbjJMMmcreGdFcEMrdWliR0NtSVQ8QlI+DQpw UHhpYkpNdEd4cmE5R2FVOTBZVytlWklub3R6N2tuQkFkR0VXdm1zS0VqR1V0RGE0VGhtbWZLcXpj aVd0NEhjPEJSPg0KelVNOWUwR1hiM1p1bHhtWmZNN2hyQU1YRzZUV3ZKZVd0aDFLaFlGSEMySDdM TVpnS0grcUcyV1lQbVhIRzI4NTxCUj4NClNrcXEvdW9FTTdwMDNSQVpJYTJPNWZuM1dmcFJOL2RT QkNQczFpREJVSlowYkNvYk5PazlVa0NnUTlJQ3lQQk48QlI+DQp0Rm1UOGM3QW5FUEZUb2xFYzdj eXNFSnpaWklSdDBRR0JNdnVuc3dSU0xQTEd3NFo4bXFWUVhURmIyUXZ4RS9SPEJSPg0Kb2JCSTRW NU9uMk9VU3NyYUpQdm48QlI+DQo9Q3JqbDxCUj4NCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0t LTxCUj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJS Pg0Kc2NhcC1kZXYgbWFpbGluZyBsaXN0PEJSPg0Kc2NhcC1kZXZAbmlzdC5nb3Y8QlI+DQpUbyB1 bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdlIHRvIHNjYXAtZGV2LXVuc3Vic2NyaWJl QG5pc3QuZ292LjxCUj4NCjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01CD3519.3B7417AA-- From gunnar.engelbach@threatguard.com Fri May 18 11:47: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 AB1A621F853E for ; Fri, 18 May 2012 11:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AWL=0.790] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki9cHDHoGpnk for ; Fri, 18 May 2012 11:47:32 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0572D21F853C for ; Fri, 18 May 2012 11:47:31 -0700 (PDT) Received: (qmail 16639 invoked from network); 18 May 2012 12:50:52 -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); 18 May 2012 12:50:52 -0700 Message-ID: <4FB6994C.3080009@ThreatGuard.com> Date: Fri, 18 May 2012 14:47:40 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: SCAP-DEV , "sacm@ietf.org" References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> <4FB667D5.2040906@ThreatGuard.com> <4FB67BB1.6000106@redhat.com> <4FB68BE8.2080606@ThreatGuard.com> <4FB68D19.9060302@redhat.com> In-Reply-To: <4FB68D19.9060302@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development 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, 18 May 2012 18:47:32 -0000 On 5/18/2012 1:55 PM, Kurt Seifried wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/18/2012 11:50 AM, Gunnar Engelbach wrote: >>> So used that way, as a text document that groups name/value >>> pairs, what would be the reason for using JSON over XML? > > Simplicity for one =). But in this case if everything is already XML > than XML is probably a better idea. I'd like to ignore that the SCAP world is already neck-deep in XML as far as this is concerned for the simple reason that I'd like to allow for the possibility that there might be repository/client relationships outside of the SCAP world. There's no reason, for example, that a repository can't also be used to serve up prose guides as PDF documents or checklists as spreadsheets. I'm going to create another opportunity to express my JSON ignorance, but it's really just nested groupings of name/value pairs, isn't it? XML requires a bit more markup to be legal, but it can be that simple as well. Does JSON support the equivalent of an XML schema that can be used to communicate the structure of the document? I can list many positive reasons for using XML but I'm not going to champion it at this point: I'd like to see a good description of the problem space and more information on possible alternatives before casting a vote, so thanks beforehand to anybody who presents good arguments for the consideration of any alternative. --gun > > - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPto0ZAAoJEBYNRVNeJnmTNK4P/3KFkGmffbTzKgL/E7CU/BGb > nTu+BHmoopLH2VaCPU/NmdbIPBxEiK6lvkAP15Tgp3d0LkToO8UU+kljdlo819OY > p7hBxyb2SNnahuva83vaB5PHhqeUi7tiWec/nY7q27E0MGdl47faHgy/xdmOKTX7 > gzgmmrW4e+Z234T9k68yfiROzPZ+GcG55j2r3JOa4I5lDNRsKY4WIIQuSt0gHp39 > 1Vm9TfHgjvtm0aX9YSS8/m7dbt54Q+a4NFTtAB4qYqsqmLpGM5pzXDK5k81Y1kv6 > GGBIJDApvB7sDHcDToas6plIsTcu+loIJiu3lNruIA1HR9va0py1zUlwJlJ0yGL9 > 9m+f4y+PKO3eoCVZjeypn2C3/XXlEevk5DmIjIsTo2VFhDfkkKqj8AG0dg2Omwt8 > nvMIvMJ5RU9AWnNMkGgfRdmcxVWGws1WTaIoU8sPG7LoXa3jlKvV2hGtB9Tq9uIN > hPWYrfyU6T48D5W5VvLNNw3d+DfCqpmw0toXr0JVdvrtLoCL4eB9li9YN+Th6o2S > Hqc7bl/ZXf42wzCFyD3uEkLsqLF7dLbKJyrEfpBwMdPAl2bWsz01g1sSXRcADs58 > DcZn9ygoPNzChlGuQVvnfVTG1w2AvDqILj+UBHmfn5qDkFnKbeNFlVwz8bbIw44W > OvM93OHktP45xXwavRPa > =i7NF > -----END PGP SIGNATURE----- From david.waltermire@nist.gov Mon May 21 07:42: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 B7F8121F8573 for ; Mon, 21 May 2012 07:42: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYxElz0FJ4kR for ; Mon, 21 May 2012 07:42:36 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 9063921F851C for ; Mon, 21 May 2012 07:42: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.355.2; Mon, 21 May 2012 10:42:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 21 May 2012 10:42:35 -0400 From: "Waltermire, David A." To: Kurt Seifried , Panos Kampanakis Date: Mon, 21 May 2012 10:41:33 -0400 Thread-Topic: [scap-dev] [sacm] Request for participants - Content Repository Specification Development Thread-Index: Ac01ErScFFX3H4DtRj6l3rZQQDTCeACMmXeg Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB6780A.1030407@redhat.com> In-Reply-To: <4FB6780A.1030407@redhat.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 Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 21 May 2012 14:42:37 -0000 My comments below, marked [DAW] Sincerely, Dave -----Original Message----- From: Kurt Seifried [mailto:kseifried@redhat.com] Sent: Friday, May 18, 2012 12:26 PM To: Panos Kampanakis Cc: Waltermire, David A.; SCAP-DEV; sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/17/2012 04:29 PM, Panos Kampanakis wrote: > Good starting point Dave. > > > > 2 thoughts: > > > > - Integrity and Confidentiality can certainly be addressed in this > spec. But XML has its own mechanisms to provide them. Thus the content > itself can provide Integrity and Confidentiality. I am not sure if the > spec should have Integrity and Confidentiality as required features. > > > > - Also, should the data Exchange mechanism be part of this draft? > For example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, > SOAP, REST as were suggested in SACM's alias before? What if I want to deliver it over IPSec? or using a push mechanism? or offline via encrypted USB key (not all hosts have connectivity)? Or I want to use a content delivery network (such as Akamai, or my own based on something like pulp) because I have 10,000 hosts? What if I have hosts that are not allowed to talk SSL (because I need to monitor the network for nefarious activity)? [DAW: This is a good argument to separate the definition of the transport from the interface definitions. I could go either way on this as well. If we want a high degree of interoperability, we will likely want to define a single transport as mandatory-to-implement (MTI). This doesn't mean that it has to be the only available transport. I just means that it is the default one that can be expected from any implementation. An implementation could support additional transports to address your use cases. These transports could be written as separate drafts. As for the MTI transport, if we want a high degree of interoperability here, (which I think we do), it may make sense to include the MTI transport in the main I/D, but include text stating that others are allowed as well. Thoughts] Defining the data delivery method for what is essentially a file specification strikes me as... bizarre. Again shouldn't this be left up to the end implementation? [DAW: If security automation content is a file based problem, then why is there any demand for a content repository at all? Basic file distribution technologies (e.g. HTTP, FTP, Atom, etc.) should be used instead. Where I see the demand coming from is that content authors and content users are generally only interested in part of the file. They want the useful parts of the file that matter to them (e.g. OVAL definitions, OCIL questionnaires), but not all the rest of the document. This means that file distribution mechanisms are not enough for their needs. What I am hearing from talking with content users is that they want a content repository capability that decomposes and works with content components (e.g. OVAL definitions, XCCDF Rules, NVD CVE records, etc) not the entire document. They ultimately want to be able to compose together components sourced from many files to produce a new document. If we want this kind of implementation to look the same from a client perspective, then we need to standardize the interfaces and transport(s) used at minimum.] If you provide a REST/SOAP service (effectively something that talks HTTP) it's not like we don't have ways to secure it that are appropriate for pretty much any use case you can think of. Again, defining this in the spec means more over head, and incompatibility with anyone not doing it exactly that way. Leaving it up to the end implementation makes way more sense as different people have different AIC/etc requirements, and again in this problem space we have many well understood solutions. [DAW: I can see your point. As part of this process, we need to identify security requirements and recommendations. My concern is mostly around interoperability. Which way we go depends on how much interoperability we want to have between ALL conformant implementations. This decision will set the minimum threshold required by all implementations and must allow for alternatives. If we want secure, interoperable communications, then we will need to make some choices as to what is required vs. recommended.] > > > Rgs, > > Panos - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtngKAAoJEBYNRVNeJnmTp9sP/3AqHsyjqi6RWsBhBhVzcnlP groJjdeywc6OJ+ETDizriYQ9t3qODl9pp3xN/zbJlXMT3Wr2Yvqp6Wp4K4CiB15X iYNRwo/IS7R4j76mBUmJi484VgUavPGsHiVLBJ7y4hOkI9oIfyt5s8+Xacb7senR +mHrD8st83eK8LVb+IGRRmmGOitRzoKJu08nV1Eq4uJxdiqsnK3RYBqgYiBYbveB YtCYL45/EzkLaZVhrlSP84Rv2jN6McI9Tqrg2Td5deSmsaibTv/ODtwAI+CYAICx nqcn2+r8XFxElV+AWS6/41ZtGdjHYGHPULtXqeT2W5SKJXKHSr9FPWojyM6n5rot sDRFSOkCsNaidzc2UeWtahgZrcigr7WCxrHN/FmiCCJin2L2g+xgEpC+uibGCmIT pPxibJMtGxra9GaU90YW+eZInotz7knBAdGEWvmsKEjGUtDa4ThmmfKqzciWt4Hc zUM9e0GXb3ZulxmZfM7hrAMXG6TWvJeWth1KhYFHC2H7LMZgKH+qG2WYPmXHG285 Skqq/uoEM7p03RAZIa2O5fn3WfpRN/dSBCPs1iDBUJZ0bCobNOk9UkCgQ9ICyPBN tFmT8c7AnEPFTolEc7cysEJzZZIRt0QGBMvunswRSLPLGw4Z8mqVQXTFb2QvxE/R obBI4V5On2OUSsraJPvn =Crjl -----END PGP SIGNATURE----- From david.waltermire@nist.gov Mon May 21 07:42: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 A1DBD21F8573 for ; Mon, 21 May 2012 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx7GFY2ikO+J for ; Mon, 21 May 2012 07:42:37 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9077B21F852A for ; Mon, 21 May 2012 07:42: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.355.2; Mon, 21 May 2012 10:42:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 21 May 2012 10:41:34 -0400 From: "Waltermire, David A." To: Gunnar Engelbach Date: Mon, 21 May 2012 10:41:34 -0400 Thread-Topic: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Thread-Index: Ac01GBYk7hnQHKrZSAmVBNc/e79oZwCM3iuA Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> <4FB680F6.9090607@ThreatGuard.com> In-Reply-To: <4FB680F6.9090607@ThreatGuard.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 Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 21 May 2012 14:42:38 -0000 Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 18, 2012 1:04 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Dave, It sounds like you are trying to solve two separate problems here. The first is the ability to retrieve content from a repository, the second is the ability to locate repositories. I'm not seeing enough of an overlap between these two sets to need to address them in the same standard. [DAW: We would be introducing significant complexity into the client if we separate these concerns. By mirroring the DNS approach for repository federation, we can keep things simple on the client side. In my view, both of these operations would be handled by the local content repository associated with the client. Just like in DNS, the local content repository server will resolve the location of each content repository based on the content identifier namespace using the corresponding SRV record. It will then dispatch a request to these content repositories to retrieve the content. It can optionally cache the content and then provide it back to the client. This entire process is transparent to the client. For example, a configuration scanning agent is ordered by the scanning manager to perform a scan on a repeating interval using a set of content. The set of content required is a list of OVAL definition IDs developed by a third party vendor hosted in the third party vendor's content repository. The agent has been preconfigured to point to the local content repository to which it sends a request to for the content. The local repository looks up the namespace associated with the third party content IDs in DNS retrieving the SRV record for the third party content repository. It dispatches a request for the content to the third party repository and retrieves the content, caching it, and providing it to the client.] As far as modeling discovery on DNS, I'm not sold, but that could just be a lack of understanding on my part -- and I still haven't had time to read your draft spec. [DAW: What I am suggesting is not "discovery" per se, it is resolution using DNS SRV records. This is the general purpose of the SRV mechanism.] But it sounds like a chicken-and-egg problem. In order to locate a repository you first have to know something about the repository -- the publisher's namespace URI from your example. In my experience discovery is more likely to be based on search criteria: affected platform, guidance source, supported languages, content formats, regulation applicability (SOX, HIPAA, etc), and so on. That's more like a searchable registry -- I don't see where DNS-style name resolution comes into it. [DAW: My example pre-supposes that the content IDs have already been selected. Meaning that the organization performing the scan pre-selected content from the third party registry. This introduces a third problem that needs to be solved that is a discovery style problem. For the web, we have web-based search engines that index content from a variety of sources and then provide persistent pointers to the location of the content. We probably need something like this too, but that is a concept that more than likely needs to be addressed by one or more additional specifications. Initially, organizations are going to seek content from sources that act as authorities for their organization or that are trusted. Discovery matters at the point where digital policy is constructed. In this scenario, if a content repository supports simple standardized query capabilities, we probably have a workable solution for the short-term. In my example above, the scanning manager is responsible for many different agents on many different hosts. The system user would create scanning configurations based on content they have pre-selected and these configurations would then get propagated to the individual scanners. The pre-selection could be the result of querying a list of authoritative and trusted repositories. This usage pattern also applies to single host and agentless approaches.] --gun On 5/18/2012 8:42 AM, Waltermire, David A. wrote: > My comments marked with [DAW2]. > > Sincerely, > Dave > > > -----Original Message----- > From: Chandrashekhar B [mailto:bchandra@secpod.com] > Sent: Friday, May 18, 2012 1:50 AM > To: Waltermire, David A.; 'Kurt Seifried' > Cc: sacm@ietf.org; SCAP-DEV > Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development > > My comments marked [CHA] > > Chandra. > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. > Sent: Friday, May 18, 2012 8:02 AM > To: Kurt Seifried > Cc: sacm@ietf.org > Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development > > Comments inline marked [DAW]. > > Sincerely, > Dave > > > -----Original Message----- > From: Kurt Seifried [mailto:kseifried@redhat.com] > Sent: Thursday, May 17, 2012 10:18 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Note: all opinions/comments are my own, not official Red Hat policy and so on. > > On 05/17/2012 07:19 PM, Waltermire, David A. wrote: >> Kurt, >> >> My assumption is that each organization would stand up a content >> repository based on this specification for their own authoritative >> content, content they produce. They would sign the content using >> their own private key. I haven't worked out an approach for public key >> distribution yet. It would be if we could use DNS or some other >> standardized key distribution mechanism. I am open to ideas. > > Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). > > [DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. > > [CHA: Yes, distributed network of repository, with may be a central registry. Even for a central registry, I feel we aren't there yet. Central repository or a registry would mean getting into operational aspects, who'll own, manage, control etc., So, limiting it to organizational repositories and content providers repository is good in my view.] > > [DAW2: This is why I am advocating for a federated system. With the right approach, we can avoid having to stand up a single central registry and all the operational and logistical aspects involved. Using the DNS SRV approach below, DNS essentially becomes the registry. Using DNS, every organization that produces content is able to point to the authoritative content repositories that they use to host their content. They can create as many namespaces as needed, by using sub-domains within their own domain(s). A SRV record would be associated with each sub-domain in this case.] > > As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. > > I'd like to hear other thoughts related to X.509.] > > [CHA: I am not sure if I understand the DNS resolution approach here completely, will anyway pose a question. If one content repository were to host a content authored by someone else and the namespace wasn't modified, may be for IP reasons. DNS namespace qualification would not work if I want to pick the content from this repository instead of the original author. Not sure if I am making sense :) ] > > [DAW2: I am modeling this approach after DNS. There are authoritative content servers that originate content. The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server. This is an analog to domains hosted by an authoritative DNS server. Here is a basic communication flow: > > 1) Client: sends request for content by ID to local, organizational content repository. > 2) Organizational repository: retrieve the requested content > a) If the namespace is a local namespace, return the content. > b) If the namespace is a foreign namespace, check if the content is in the local cache. > c) Lookup the DNS SRV record associated with the ID's namespace. > d) Dispatch a request to the foreign authoritative content repository based on the SRV record to retrieve the content > e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server. > 3) Organizational repository: respond to the client with the content > > This approach allows content for a given namespace to be managed by a single authoritative content repository. If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository. > > Access to local cache can (and probably should) be limited to IPs within an organization or thru the use of access controls to prevent leakage of cached content.] > >> It may also make sense to allow for counter signing of content to >> allow 3rd parties to sign content. Again, I have not worked out how >> best to do this. Any ideas? > > Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. > > [DAW: agreed.] > >> Related to restricting access to content, it is my hope that content >> is made freely available. For some kinds of content, it probably >> makes sense to support some kind of access control. This could be >> driven by commercialization of content or to restrict access to some >> content to authorized users within an organization. >> Client/Server certificates might be a mechanism to support this. > > I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: > > 1) be incompatible (and thus either removed, or an active problem) for many vendors/customers (I doubt any existing system for selling content will end up being super compatible with what you guys build) > 2) be unnecessary in most (if not almost all) cases > 3) add significantly to the overhead of building this and not add any real value to the actual problem space of securing machines > > For some idea of the scope of this type of problem check out > http://www.candlepinproject.org/ which provides subscription and > entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. > > TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. > > [DAW: Points well taken. I am interested in other thoughts on how best to address this. What I was recommending was looking more towards service authentication and less towards DRM. Maybe we don't address this in the first pass. Thoughts?] > > [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. > > In our repository, we have implemented a policy driven access control and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. > > So, service authentication is required to be standardized. For access control, may be an error condition if one is not allowed to fetch the content?] > > [DAW2: agreed. I see this as a minimal standardization approach.] > >> I hope this answers your questions. >> >> Sincerely, Dave >> >> >> -----Original Message----- From: Kurt Seifried >> [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM >> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for >> participants - Content Repository Specification Development >> >> On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >>> Good points. It makes sense to use the mechanisms provided by XML >>> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >>> underlying transport (e.g. TLS) to address as much of this as >>> possible. It may be desirable to provide mechanisms for >>> authentication to restrict access to content. This may also need to >>> be integrated into the underlying transport. >> I have some questions, asking off list, not sure if they are >> appropriate, if they are feel free to reply on the list. >> >> 1) if using XMLDsig who would be the signing authority? How secure >> would signing be (e.g. using a hardware card/appliance/etc?). >> Where would the key be published/would it be signed/etc? 2) You >> mention restricting access to content, why would the content need to >> be restricted? Are there IP issues I am unaware of? >> >> Thanks >> >>> Sincerely, Dave >> > - - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ > uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR > GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK > MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf > LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew > xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus > u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r > GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH > TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK > +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi > oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv > XCldnHSPS6O7qeRTgMtL > =QJsL > -----END PGP SIGNATURE----- > _______________________________________________ > 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 michael.hammer@yaanatech.com Mon May 21 09:59: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 CAACB21F8562 for ; Mon, 21 May 2012 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvq0T7JnfWSm for ; Mon, 21 May 2012 09:59:30 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 062F921F8446 for ; Mon, 21 May 2012 09:59:30 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 21 May 2012 09:59:29 -0700 From: Michael Hammer To: "david.waltermire@nist.gov" , "Gunnar.Engelbach@ThreatGuard.com" Thread-Topic: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Thread-Index: AQHNNPOpi2FrVnWCoUakn+FRJ3pSaJbQO9UAgASPPwD//7DDsA== Date: Mon, 21 May 2012 16:59:28 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38ADD64@EX2K10MB1.corp.yaanatech.com> References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> <4FB680F6.9090607@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.15] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0099_01CD3751.8D563C10" MIME-Version: 1.0 Cc: "SCAP-DEV@nist.gov" , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 21 May 2012 16:59:31 -0000 ------=_NextPart_000_0099_01CD3751.8D563C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Rather than having a lot of polling, could you use a Subscribe-Notify type of framework, where notices of new information or updates get distributed? Polling seems like it could get chatty, and raises the question of how often. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, May 21, 2012 10:42 AM To: Gunnar Engelbach Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 18, 2012 1:04 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Dave, It sounds like you are trying to solve two separate problems here. The first is the ability to retrieve content from a repository, the second is the ability to locate repositories. I'm not seeing enough of an overlap between these two sets to need to address them in the same standard. [DAW: We would be introducing significant complexity into the client if we separate these concerns. By mirroring the DNS approach for repository federation, we can keep things simple on the client side. In my view, both of these operations would be handled by the local content repository associated with the client. Just like in DNS, the local content repository server will resolve the location of each content repository based on the content identifier namespace using the corresponding SRV record. It will then dispatch a request to these content repositories to retrieve the content. It can optionally cache the content and then provide it back to the client. This entire process is transparent to the client. For example, a configuration scanning agent is ordered by the scanning manager to perform a scan on a repeating interval using a set of content. The set of content required is a list of OVAL definition IDs developed by a third party vendor hosted in the third party vendor's content repository. The agent has been preconfigured to point to the local content repository to which it sends a request to for the content. The local repository looks up the namespace associated with the third party content IDs in DNS retrieving the SRV record for the third party content repository. It dispatches a request for the content to the third party repository and retrieves the content, caching it, and providing it to the client.] As far as modeling discovery on DNS, I'm not sold, but that could just be a lack of understanding on my part -- and I still haven't had time to read your draft spec. [DAW: What I am suggesting is not "discovery" per se, it is resolution using DNS SRV records. This is the general purpose of the SRV mechanism.] But it sounds like a chicken-and-egg problem. In order to locate a repository you first have to know something about the repository -- the publisher's namespace URI from your example. In my experience discovery is more likely to be based on search criteria: affected platform, guidance source, supported languages, content formats, regulation applicability (SOX, HIPAA, etc), and so on. That's more like a searchable registry -- I don't see where DNS-style name resolution comes into it. [DAW: My example pre-supposes that the content IDs have already been selected. Meaning that the organization performing the scan pre-selected content from the third party registry. This introduces a third problem that needs to be solved that is a discovery style problem. For the web, we have web-based search engines that index content from a variety of sources and then provide persistent pointers to the location of the content. We probably need something like this too, but that is a concept that more than likely needs to be addressed by one or more additional specifications. Initially, organizations are going to seek content from sources that act as authorities for their organization or that are trusted. Discovery matters at the point where digital policy is constructed. In this scenario, if a content repository supports simple standardized query capabilities, we probably have a workable solution for the short-term. In my example above, the scanning manager is responsible for many different agents on many different hosts. The system user would create scanning configurations based on content they have pre-selected and these configurations would then get propagated to the individual scanners. The pre-selection could be the result of querying a list of authoritative and trusted repositories. This usage pattern also applies to single host and agentless approaches.] --gun On 5/18/2012 8:42 AM, Waltermire, David A. wrote: > My comments marked with [DAW2]. > > Sincerely, > Dave > > > -----Original Message----- > From: Chandrashekhar B [mailto:bchandra@secpod.com] > Sent: Friday, May 18, 2012 1:50 AM > To: Waltermire, David A.; 'Kurt Seifried' > Cc: sacm@ietf.org; SCAP-DEV > Subject: RE: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > My comments marked [CHA] > > Chandra. > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. > Sent: Friday, May 18, 2012 8:02 AM > To: Kurt Seifried > Cc: sacm@ietf.org > Subject: Re: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > Comments inline marked [DAW]. > > Sincerely, > Dave > > > -----Original Message----- > From: Kurt Seifried [mailto:kseifried@redhat.com] > Sent: Thursday, May 17, 2012 10:18 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [scap-dev] [sacm] Request for participants - Content > Repository Specification Development > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Note: all opinions/comments are my own, not official Red Hat policy and so on. > > On 05/17/2012 07:19 PM, Waltermire, David A. wrote: >> Kurt, >> >> My assumption is that each organization would stand up a content >> repository based on this specification for their own authoritative >> content, content they produce. They would sign the content using >> their own private key. I haven't worked out an approach for public >> key distribution yet. It would be if we could use DNS or some other >> standardized key distribution mechanism. I am open to ideas. > > Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). > > [DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. > > [CHA: Yes, distributed network of repository, with may be a central > registry. Even for a central registry, I feel we aren't there yet. > Central repository or a registry would mean getting into operational > aspects, who'll own, manage, control etc., So, limiting it to > organizational repositories and content providers repository is good > in my view.] > > [DAW2: This is why I am advocating for a federated system. With the > right approach, we can avoid having to stand up a single central > registry and all the operational and logistical aspects involved. > Using the DNS SRV approach below, DNS essentially becomes the > registry. Using DNS, every organization that produces content is able > to point to the authoritative content repositories that they use to > host their content. They can create as many namespaces as needed, by > using sub-domains within their own domain(s). A SRV record would be > associated with each sub-domain in this case.] > > As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. > > I'd like to hear other thoughts related to X.509.] > > [CHA: I am not sure if I understand the DNS resolution approach here > completely, will anyway pose a question. If one content repository > were to host a content authored by someone else and the namespace > wasn't modified, may be for IP reasons. DNS namespace qualification > would not work if I want to pick the content from this repository > instead of the original author. Not sure if I am making sense :) ] > > [DAW2: I am modeling this approach after DNS. There are authoritative content servers that originate content. The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server. This is an analog to domains hosted by an authoritative DNS server. Here is a basic communication flow: > > 1) Client: sends request for content by ID to local, organizational content repository. > 2) Organizational repository: retrieve the requested content > a) If the namespace is a local namespace, return the content. > b) If the namespace is a foreign namespace, check if the content is in the local cache. > c) Lookup the DNS SRV record associated with the ID's namespace. > d) Dispatch a request to the foreign authoritative content repository based on the SRV record to retrieve the content > e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server. > 3) Organizational repository: respond to the client with the content > > This approach allows content for a given namespace to be managed by a single authoritative content repository. If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository. > > Access to local cache can (and probably should) be limited to IPs > within an organization or thru the use of access controls to prevent > leakage of cached content.] > >> It may also make sense to allow for counter signing of content to >> allow 3rd parties to sign content. Again, I have not worked out how >> best to do this. Any ideas? > > Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. > > [DAW: agreed.] > >> Related to restricting access to content, it is my hope that content >> is made freely available. For some kinds of content, it probably >> makes sense to support some kind of access control. This could be >> driven by commercialization of content or to restrict access to some >> content to authorized users within an organization. >> Client/Server certificates might be a mechanism to support this. > > I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: > > 1) be incompatible (and thus either removed, or an active problem) for > many vendors/customers (I doubt any existing system for selling > content will end up being super compatible with what you guys build) > 2) be unnecessary in most (if not almost all) cases > 3) add significantly to the overhead of building this and not add any > real value to the actual problem space of securing machines > > For some idea of the scope of this type of problem check out > http://www.candlepinproject.org/ which provides subscription and > entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. > > TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. > > [DAW: Points well taken. I am interested in other thoughts on how > best to address this. What I was recommending was looking more > towards service authentication and less towards DRM. Maybe we don't > address this in the first pass. Thoughts?] > > [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. > > In our repository, we have implemented a policy driven access control and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. > > So, service authentication is required to be standardized. For access > control, may be an error condition if one is not allowed to fetch the > content?] > > [DAW2: agreed. I see this as a minimal standardization approach.] > >> I hope this answers your questions. >> >> Sincerely, Dave >> >> >> -----Original Message----- From: Kurt Seifried >> [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM >> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for >> participants - Content Repository Specification Development >> >> On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >>> Good points. It makes sense to use the mechanisms provided by XML >>> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >>> underlying transport (e.g. TLS) to address as much of this as >>> possible. It may be desirable to provide mechanisms for >>> authentication to restrict access to content. This may also need to >>> be integrated into the underlying transport. >> I have some questions, asking off list, not sure if they are >> appropriate, if they are feel free to reply on the list. >> >> 1) if using XMLDsig who would be the signing authority? How secure >> would signing be (e.g. using a hardware card/appliance/etc?). >> Where would the key be published/would it be signed/etc? 2) You >> mention restricting access to content, why would the content need to >> be restricted? Are there IP issues I am unaware of? >> >> Thanks >> >>> Sincerely, Dave >> > - - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ > uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR > GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK > MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf > LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew > xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus > u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r > GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH > TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK > +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi > oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv > XCldnHSPS6O7qeRTgMtL > =QJsL > -----END PGP SIGNATURE----- > _______________________________________________ > 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 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0099_01CD3751.8D563C10 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUy MTE2NTkyNlowIwYJKoZIhvcNAQkEMRYEFJqR0JqBpaWsl3FjLe90VkHMPO+8MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAMR5cgku0Xwdkkghux+lO0FUtSZJpOZNnrZK8rVNIF0LC THIHgDr64iDN23XYSsMcP6RcRGr27mm7eT6G3WJq7I1EOR9A64937Hwfem1HvkJFkjImUfJHqLRm JbLw1763kwrCfrZUDr2i0yNl7hx0y/Ad6wTp0ZgwLCk5IgoYypYAAAAAAAA= ------=_NextPart_000_0099_01CD3751.8D563C10-- From david.waltermire@nist.gov Mon May 21 10:09: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 9E16421F856C for ; Mon, 21 May 2012 10:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wZ8ihYrEBRK for ; Mon, 21 May 2012 10:09:11 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 873EC21F8562 for ; Mon, 21 May 2012 10:09: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.355.2; Mon, 21 May 2012 13:09:07 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 21 May 2012 13:08:08 -0400 From: "Waltermire, David A." To: Michael Hammer , "Gunnar.Engelbach@ThreatGuard.com" Date: Mon, 21 May 2012 13:09:08 -0400 Thread-Topic: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Thread-Index: AQHNNPOpi2FrVnWCoUakn+FRJ3pSaJbQO9UAgASPPwD//7DDsIAAAh0A Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> <4FB680F6.9090607@ThreatGuard.com> <00C069FD01E0324C9FFCADF539701DB38ADD64@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38ADD64@EX2K10MB1.corp.yaanatech.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 Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 21 May 2012 17:09:12 -0000 That is also an option. It could be supported in addition to a polling method also. The challenge with pub-sub is that content servers would need to register with other content servers to make this work. The DNS model doesn't require any prior knowledge on behalf of the content servers and it is essentially stateless. A pub-sub model would require a lot of state tracking. Sincerely, Dave -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Monday, May 21, 2012 12:59 PM To: Waltermire, David A.; Gunnar.Engelbach@ThreatGuard.com Cc: SCAP-DEV; sacm@ietf.org Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Rather than having a lot of polling, could you use a Subscribe-Notify type of framework, where notices of new information or updates get distributed? Polling seems like it could get chatty, and raises the question of how often. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, May 21, 2012 10:42 AM To: Gunnar Engelbach Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 18, 2012 1:04 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Dave, It sounds like you are trying to solve two separate problems here. The first is the ability to retrieve content from a repository, the second is the ability to locate repositories. I'm not seeing enough of an overlap between these two sets to need to address them in the same standard. [DAW: We would be introducing significant complexity into the client if we separate these concerns. By mirroring the DNS approach for repository federation, we can keep things simple on the client side. In my view, both of these operations would be handled by the local content repository associated with the client. Just like in DNS, the local content repository server will resolve the location of each content repository based on the content identifier namespace using the corresponding SRV record. It will then dispatch a request to these content repositories to retrieve the content. It can optionally cache the content and then provide it back to the client. This entire process is transparent to the client. For example, a configuration scanning agent is ordered by the scanning manager to perform a scan on a repeating interval using a set of content. The set of content required is a list of OVAL definition IDs developed by a third party vendor hosted in the third party vendor's content repository. The agent has been preconfigured to point to the local content repository to which it sends a request to for the content. The local repository looks up the namespace associated with the third party content IDs in DNS retrieving the SRV record for the third party content repository. It dispatches a request for the content to the third party repository and retrieves the content, caching it, and providing it to the client.] As far as modeling discovery on DNS, I'm not sold, but that could just be a lack of understanding on my part -- and I still haven't had time to read your draft spec. [DAW: What I am suggesting is not "discovery" per se, it is resolution using DNS SRV records. This is the general purpose of the SRV mechanism.] But it sounds like a chicken-and-egg problem. In order to locate a repository you first have to know something about the repository -- the publisher's namespace URI from your example. In my experience discovery is more likely to be based on search criteria: affected platform, guidance source, supported languages, content formats, regulation applicability (SOX, HIPAA, etc), and so on. That's more like a searchable registry -- I don't see where DNS-style name resolution comes into it. [DAW: My example pre-supposes that the content IDs have already been selected. Meaning that the organization performing the scan pre-selected content from the third party registry. This introduces a third problem that needs to be solved that is a discovery style problem. For the web, we have web-based search engines that index content from a variety of sources and then provide persistent pointers to the location of the content. We probably need something like this too, but that is a concept that more than likely needs to be addressed by one or more additional specifications. Initially, organizations are going to seek content from sources that act as authorities for their organization or that are trusted. Discovery matters at the point where digital policy is constructed. In this scenario, if a content repository supports simple standardized query capabilities, we probably have a workable solution for the short-term. In my example above, the scanning manager is responsible for many different agents on many different hosts. The system user would create scanning configurations based on content they have pre-selected and these configurations would then get propagated to the individual scanners. The pre-selection could be the result of querying a list of authoritative and trusted repositories. This usage pattern also applies to single host and agentless approaches.] --gun On 5/18/2012 8:42 AM, Waltermire, David A. wrote: > My comments marked with [DAW2]. > > Sincerely, > Dave > > > -----Original Message----- > From: Chandrashekhar B [mailto:bchandra@secpod.com] > Sent: Friday, May 18, 2012 1:50 AM > To: Waltermire, David A.; 'Kurt Seifried' > Cc: sacm@ietf.org; SCAP-DEV > Subject: RE: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > My comments marked [CHA] > > Chandra. > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. > Sent: Friday, May 18, 2012 8:02 AM > To: Kurt Seifried > Cc: sacm@ietf.org > Subject: Re: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > Comments inline marked [DAW]. > > Sincerely, > Dave > > > -----Original Message----- > From: Kurt Seifried [mailto:kseifried@redhat.com] > Sent: Thursday, May 17, 2012 10:18 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [scap-dev] [sacm] Request for participants - Content > Repository Specification Development > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Note: all opinions/comments are my own, not official Red Hat policy and so on. > > On 05/17/2012 07:19 PM, Waltermire, David A. wrote: >> Kurt, >> >> My assumption is that each organization would stand up a content >> repository based on this specification for their own authoritative >> content, content they produce. They would sign the content using >> their own private key. I haven't worked out an approach for public >> key distribution yet. It would be if we could use DNS or some other >> standardized key distribution mechanism. I am open to ideas. > > Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). > > [DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. > > [CHA: Yes, distributed network of repository, with may be a central > registry. Even for a central registry, I feel we aren't there yet. > Central repository or a registry would mean getting into operational > aspects, who'll own, manage, control etc., So, limiting it to > organizational repositories and content providers repository is good > in my view.] > > [DAW2: This is why I am advocating for a federated system. With the > right approach, we can avoid having to stand up a single central > registry and all the operational and logistical aspects involved. > Using the DNS SRV approach below, DNS essentially becomes the > registry. Using DNS, every organization that produces content is able > to point to the authoritative content repositories that they use to > host their content. They can create as many namespaces as needed, by > using sub-domains within their own domain(s). A SRV record would be > associated with each sub-domain in this case.] > > As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. > > I'd like to hear other thoughts related to X.509.] > > [CHA: I am not sure if I understand the DNS resolution approach here > completely, will anyway pose a question. If one content repository > were to host a content authored by someone else and the namespace > wasn't modified, may be for IP reasons. DNS namespace qualification > would not work if I want to pick the content from this repository > instead of the original author. Not sure if I am making sense :) ] > > [DAW2: I am modeling this approach after DNS. There are authoritative content servers that originate content. The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server. This is an analog to domains hosted by an authoritative DNS server. Here is a basic communication flow: > > 1) Client: sends request for content by ID to local, organizational content repository. > 2) Organizational repository: retrieve the requested content > a) If the namespace is a local namespace, return the content. > b) If the namespace is a foreign namespace, check if the content is in the local cache. > c) Lookup the DNS SRV record associated with the ID's namespace. > d) Dispatch a request to the foreign authoritative content repository based on the SRV record to retrieve the content > e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server. > 3) Organizational repository: respond to the client with the content > > This approach allows content for a given namespace to be managed by a single authoritative content repository. If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository. > > Access to local cache can (and probably should) be limited to IPs > within an organization or thru the use of access controls to prevent > leakage of cached content.] > >> It may also make sense to allow for counter signing of content to >> allow 3rd parties to sign content. Again, I have not worked out how >> best to do this. Any ideas? > > Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. > > [DAW: agreed.] > >> Related to restricting access to content, it is my hope that content >> is made freely available. For some kinds of content, it probably >> makes sense to support some kind of access control. This could be >> driven by commercialization of content or to restrict access to some >> content to authorized users within an organization. >> Client/Server certificates might be a mechanism to support this. > > I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: > > 1) be incompatible (and thus either removed, or an active problem) for > many vendors/customers (I doubt any existing system for selling > content will end up being super compatible with what you guys build) > 2) be unnecessary in most (if not almost all) cases > 3) add significantly to the overhead of building this and not add any > real value to the actual problem space of securing machines > > For some idea of the scope of this type of problem check out > http://www.candlepinproject.org/ which provides subscription and > entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. > > TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. > > [DAW: Points well taken. I am interested in other thoughts on how > best to address this. What I was recommending was looking more > towards service authentication and less towards DRM. Maybe we don't > address this in the first pass. Thoughts?] > > [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. > > In our repository, we have implemented a policy driven access control and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. > > So, service authentication is required to be standardized. For access > control, may be an error condition if one is not allowed to fetch the > content?] > > [DAW2: agreed. I see this as a minimal standardization approach.] > >> I hope this answers your questions. >> >> Sincerely, Dave >> >> >> -----Original Message----- From: Kurt Seifried >> [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM >> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for >> participants - Content Repository Specification Development >> >> On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >>> Good points. It makes sense to use the mechanisms provided by XML >>> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >>> underlying transport (e.g. TLS) to address as much of this as >>> possible. It may be desirable to provide mechanisms for >>> authentication to restrict access to content. This may also need to >>> be integrated into the underlying transport. >> I have some questions, asking off list, not sure if they are >> appropriate, if they are feel free to reply on the list. >> >> 1) if using XMLDsig who would be the signing authority? How secure >> would signing be (e.g. using a hardware card/appliance/etc?). >> Where would the key be published/would it be signed/etc? 2) You >> mention restricting access to content, why would the content need to >> be restricted? Are there IP issues I am unaware of? >> >> Thanks >> >>> Sincerely, Dave >> > - - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ > uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR > GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK > MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf > LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew > xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus > u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r > GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH > TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK > +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi > oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv > XCldnHSPS6O7qeRTgMtL > =QJsL > -----END PGP SIGNATURE----- > _______________________________________________ > 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 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From michael.hammer@yaanatech.com Mon May 21 10:17:46 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 B5E6221F8566 for ; Mon, 21 May 2012 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtDzU3BMuZEp for ; Mon, 21 May 2012 10:17:45 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6121F8562 for ; Mon, 21 May 2012 10:17:45 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 21 May 2012 10:17:45 -0700 From: Michael Hammer To: "david.waltermire@nist.gov" , "Gunnar.Engelbach@ThreatGuard.com" Thread-Topic: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Thread-Index: AQHNNPOpi2FrVnWCoUakn+FRJ3pSaJbQO9UAgASPPwD//7DDsIAAAh0AgAACgZA= Date: Mon, 21 May 2012 17:17:43 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38ADDDE@EX2K10MB1.corp.yaanatech.com> References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> <4FB680F6.9090607@ThreatGuard.com> <00C069FD01E0324C9FFCADF539701DB38ADD64@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.15] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00B1_01CD3754.1A262360" MIME-Version: 1.0 Cc: "SCAP-DEV@nist.gov" , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 21 May 2012 17:17:46 -0000 ------=_NextPart_000_00B1_01CD3754.1A262360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It would be possible for centralized star, with reciprocal subscriptions. Sources publish, and central devise broadcasts to subscribers. Filters could also be applied. Guess it depends on whether you want a pull or push model. May depend on how often you see data needing to be transferred. And whether an intra-poll delay is acceptable or not. Mike -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, May 21, 2012 1:09 PM To: Michael Hammer; Gunnar.Engelbach@ThreatGuard.com Cc: SCAP-DEV; sacm@ietf.org Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development That is also an option. It could be supported in addition to a polling method also. The challenge with pub-sub is that content servers would need to register with other content servers to make this work. The DNS model doesn't require any prior knowledge on behalf of the content servers and it is essentially stateless. A pub-sub model would require a lot of state tracking. Sincerely, Dave -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Monday, May 21, 2012 12:59 PM To: Waltermire, David A.; Gunnar.Engelbach@ThreatGuard.com Cc: SCAP-DEV; sacm@ietf.org Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Rather than having a lot of polling, could you use a Subscribe-Notify type of framework, where notices of new information or updates get distributed? Polling seems like it could get chatty, and raises the question of how often. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, May 21, 2012 10:42 AM To: Gunnar Engelbach Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 18, 2012 1:04 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Dave, It sounds like you are trying to solve two separate problems here. The first is the ability to retrieve content from a repository, the second is the ability to locate repositories. I'm not seeing enough of an overlap between these two sets to need to address them in the same standard. [DAW: We would be introducing significant complexity into the client if we separate these concerns. By mirroring the DNS approach for repository federation, we can keep things simple on the client side. In my view, both of these operations would be handled by the local content repository associated with the client. Just like in DNS, the local content repository server will resolve the location of each content repository based on the content identifier namespace using the corresponding SRV record. It will then dispatch a request to these content repositories to retrieve the content. It can optionally cache the content and then provide it back to the client. This entire process is transparent to the client. For example, a configuration scanning agent is ordered by the scanning manager to perform a scan on a repeating interval using a set of content. The set of content required is a list of OVAL definition IDs developed by a third party vendor hosted in the third party vendor's content repository. The agent has been preconfigured to point to the local content repository to which it sends a request to for the content. The local repository looks up the namespace associated with the third party content IDs in DNS retrieving the SRV record for the third party content repository. It dispatches a request for the content to the third party repository and retrieves the content, caching it, and providing it to the client.] As far as modeling discovery on DNS, I'm not sold, but that could just be a lack of understanding on my part -- and I still haven't had time to read your draft spec. [DAW: What I am suggesting is not "discovery" per se, it is resolution using DNS SRV records. This is the general purpose of the SRV mechanism.] But it sounds like a chicken-and-egg problem. In order to locate a repository you first have to know something about the repository -- the publisher's namespace URI from your example. In my experience discovery is more likely to be based on search criteria: affected platform, guidance source, supported languages, content formats, regulation applicability (SOX, HIPAA, etc), and so on. That's more like a searchable registry -- I don't see where DNS-style name resolution comes into it. [DAW: My example pre-supposes that the content IDs have already been selected. Meaning that the organization performing the scan pre-selected content from the third party registry. This introduces a third problem that needs to be solved that is a discovery style problem. For the web, we have web-based search engines that index content from a variety of sources and then provide persistent pointers to the location of the content. We probably need something like this too, but that is a concept that more than likely needs to be addressed by one or more additional specifications. Initially, organizations are going to seek content from sources that act as authorities for their organization or that are trusted. Discovery matters at the point where digital policy is constructed. In this scenario, if a content repository supports simple standardized query capabilities, we probably have a workable solution for the short-term. In my example above, the scanning manager is responsible for many different agents on many different hosts. The system user would create scanning configurations based on content they have pre-selected and these configurations would then get propagated to the individual scanners. The pre-selection could be the result of querying a list of authoritative and trusted repositories. This usage pattern also applies to single host and agentless approaches.] --gun On 5/18/2012 8:42 AM, Waltermire, David A. wrote: > My comments marked with [DAW2]. > > Sincerely, > Dave > > > -----Original Message----- > From: Chandrashekhar B [mailto:bchandra@secpod.com] > Sent: Friday, May 18, 2012 1:50 AM > To: Waltermire, David A.; 'Kurt Seifried' > Cc: sacm@ietf.org; SCAP-DEV > Subject: RE: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > My comments marked [CHA] > > Chandra. > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of Waltermire, David A. > Sent: Friday, May 18, 2012 8:02 AM > To: Kurt Seifried > Cc: sacm@ietf.org > Subject: Re: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > Comments inline marked [DAW]. > > Sincerely, > Dave > > > -----Original Message----- > From: Kurt Seifried [mailto:kseifried@redhat.com] > Sent: Thursday, May 17, 2012 10:18 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [scap-dev] [sacm] Request for participants - Content > Repository Specification Development > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Note: all opinions/comments are my own, not official Red Hat policy > and so on. > > On 05/17/2012 07:19 PM, Waltermire, David A. wrote: >> Kurt, >> >> My assumption is that each organization would stand up a content >> repository based on this specification for their own authoritative >> content, content they produce. They would sign the content using >> their own private key. I haven't worked out an approach for public >> key distribution yet. It would be if we could use DNS or some other >> standardized key distribution mechanism. I am open to ideas. > > Ah my bad I assumed you guys were talking about the central repo > (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). > > [DAW: I am assuming that there will be no central repo. From talking > with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. > > [CHA: Yes, distributed network of repository, with may be a central > registry. Even for a central registry, I feel we aren't there yet. > Central repository or a registry would mean getting into operational > aspects, who'll own, manage, control etc., So, limiting it to > organizational repositories and content providers repository is good > in my view.] > > [DAW2: This is why I am advocating for a federated system. With the > right approach, we can avoid having to stand up a single central > registry and all the operational and logistical aspects involved. > Using the DNS SRV approach below, DNS essentially becomes the > registry. Using DNS, every organization that produces content is able > to point to the authoritative content repositories that they use to > host their content. They can create as many namespaces as needed, by > using sub-domains within their own domain(s). A SRV record would be > associated with each sub-domain in this case.] > > As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. > > I'd like to hear other thoughts related to X.509.] > > [CHA: I am not sure if I understand the DNS resolution approach here > completely, will anyway pose a question. If one content repository > were to host a content authored by someone else and the namespace > wasn't modified, may be for IP reasons. DNS namespace qualification > would not work if I want to pick the content from this repository > instead of the original author. Not sure if I am making sense :) ] > > [DAW2: I am modeling this approach after DNS. There are authoritative content servers that originate content. The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server. This is an analog to domains hosted by an authoritative DNS server. Here is a basic communication flow: > > 1) Client: sends request for content by ID to local, organizational content repository. > 2) Organizational repository: retrieve the requested content > a) If the namespace is a local namespace, return the content. > b) If the namespace is a foreign namespace, check if the content is > in the local cache. > c) Lookup the DNS SRV record associated with the ID's namespace. > d) Dispatch a request to the foreign authoritative content > repository based on the SRV record to retrieve the content > e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server. > 3) Organizational repository: respond to the client with the content > > This approach allows content for a given namespace to be managed by a single authoritative content repository. If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository. > > Access to local cache can (and probably should) be limited to IPs > within an organization or thru the use of access controls to prevent > leakage of cached content.] > >> It may also make sense to allow for counter signing of content to >> allow 3rd parties to sign content. Again, I have not worked out how >> best to do this. Any ideas? > > Chained signatures would be really nice, e.g. Linux vendor releases an > RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. > > [DAW: agreed.] > >> Related to restricting access to content, it is my hope that content >> is made freely available. For some kinds of content, it probably >> makes sense to support some kind of access control. This could be >> driven by commercialization of content or to restrict access to some >> content to authorized users within an organization. >> Client/Server certificates might be a mechanism to support this. > > I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: > > 1) be incompatible (and thus either removed, or an active problem) for > many vendors/customers (I doubt any existing system for selling > content will end up being super compatible with what you guys build) > 2) be unnecessary in most (if not almost all) cases > 3) add significantly to the overhead of building this and not add any > real value to the actual problem space of securing machines > > For some idea of the scope of this type of problem check out > http://www.candlepinproject.org/ which provides subscription and > entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. > > TLDR: Please, please don't do this, it'll be a huge time/effort sink > and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. > > [DAW: Points well taken. I am interested in other thoughts on how > best to address this. What I was recommending was looking more > towards service authentication and less towards DRM. Maybe we don't > address this in the first pass. Thoughts?] > > [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. > > In our repository, we have implemented a policy driven access control > and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. > > So, service authentication is required to be standardized. For access > control, may be an error condition if one is not allowed to fetch the > content?] > > [DAW2: agreed. I see this as a minimal standardization approach.] > >> I hope this answers your questions. >> >> Sincerely, Dave >> >> >> -----Original Message----- From: Kurt Seifried >> [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM >> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for >> participants - Content Repository Specification Development >> >> On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >>> Good points. It makes sense to use the mechanisms provided by XML >>> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >>> underlying transport (e.g. TLS) to address as much of this as >>> possible. It may be desirable to provide mechanisms for >>> authentication to restrict access to content. This may also need to >>> be integrated into the underlying transport. >> I have some questions, asking off list, not sure if they are >> appropriate, if they are feel free to reply on the list. >> >> 1) if using XMLDsig who would be the signing authority? How secure >> would signing be (e.g. using a hardware card/appliance/etc?). >> Where would the key be published/would it be signed/etc? 2) You >> mention restricting access to content, why would the content need to >> be restricted? Are there IP issues I am unaware of? >> >> Thanks >> >>> Sincerely, Dave >> > - - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ > uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR > GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK > MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf > LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew > xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus > u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r > GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH > TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK > +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi > oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv > XCldnHSPS6O7qeRTgMtL > =QJsL > -----END PGP SIGNATURE----- > _______________________________________________ > 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 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_00B1_01CD3754.1A262360 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUy MTE3MTc0MVowIwYJKoZIhvcNAQkEMRYEFILqujfG4qKqZ+Qdk63mZPEK/KgKMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA32Wy6cSXDvkbRFUg9ChylEjomhaZJKUKO4Yb5dVU6El7 a97DzuTCax3owpcD8ccFVDBi6NQr2BXrkSlVMbNyrPMr12wfeMW6xIA9BTM7i50ktydEunXxbZDc QmOxh19M38Us3twxK0MloPHsd+kTGWmLitEcpxCQj/rLOlFdw/IAAAAAAAA= ------=_NextPart_000_00B1_01CD3754.1A262360-- From david.waltermire@nist.gov Mon May 21 10:25: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 01AE821F8476 for ; Mon, 21 May 2012 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RmII1dAyVsB for ; Mon, 21 May 2012 10:25:10 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id C252721F858A for ; Mon, 21 May 2012 10:25:09 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 21 May 2012 13:25:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 21 May 2012 13:24:03 -0400 From: "Waltermire, David A." To: Michael Hammer , "Gunnar.Engelbach@ThreatGuard.com" Date: Mon, 21 May 2012 13:25:03 -0400 Thread-Topic: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Thread-Index: AQHNNPOpi2FrVnWCoUakn+FRJ3pSaJbQO9UAgASPPwD//7DDsIAAAh0AgAACgZCAAAH4MA== Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <4FB5A18E.4090709@redhat.com> <4FB5B148.40403@redhat.com> <00aa01cd34ba$0ecdc460$2c694d20$@secpod.com> <4FB680F6.9090607@ThreatGuard.com> <00C069FD01E0324C9FFCADF539701DB38ADD64@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB38ADDDE@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38ADDDE@EX2K10MB1.corp.yaanatech.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 Cc: SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 21 May 2012 17:25:14 -0000 The centralized star is interesting, but I am not sure we want to get into the management concerns around who would maintain the "hub". My preference has been for loose federation with distributed management of the nodes. Any other thoughts? Sincerely, Dave -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Monday, May 21, 2012 1:18 PM To: Waltermire, David A.; Gunnar.Engelbach@ThreatGuard.com Cc: SCAP-DEV; sacm@ietf.org Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development It would be possible for centralized star, with reciprocal subscriptions. Sources publish, and central devise broadcasts to subscribers. Filters could also be applied. Guess it depends on whether you want a pull or push model. May depend on how often you see data needing to be transferred. And whether an intra-poll delay is acceptable or not. Mike -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, May 21, 2012 1:09 PM To: Michael Hammer; Gunnar.Engelbach@ThreatGuard.com Cc: SCAP-DEV; sacm@ietf.org Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development That is also an option. It could be supported in addition to a polling method also. The challenge with pub-sub is that content servers would need to register with other content servers to make this work. The DNS model doesn't require any prior knowledge on behalf of the content servers and it is essentially stateless. A pub-sub model would require a lot of state tracking. Sincerely, Dave -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Monday, May 21, 2012 12:59 PM To: Waltermire, David A.; Gunnar.Engelbach@ThreatGuard.com Cc: SCAP-DEV; sacm@ietf.org Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Rather than having a lot of polling, could you use a Subscribe-Notify type of framework, where notices of new information or updates get distributed? Polling seems like it could get chatty, and raises the question of how often. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, May 21, 2012 10:42 AM To: Gunnar Engelbach Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Comments inline marked [DAW]. Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach Sent: Friday, May 18, 2012 1:04 PM Cc: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development Dave, It sounds like you are trying to solve two separate problems here. The first is the ability to retrieve content from a repository, the second is the ability to locate repositories. I'm not seeing enough of an overlap between these two sets to need to address them in the same standard. [DAW: We would be introducing significant complexity into the client if we separate these concerns. By mirroring the DNS approach for repository federation, we can keep things simple on the client side. In my view, both of these operations would be handled by the local content repository associated with the client. Just like in DNS, the local content repository server will resolve the location of each content repository based on the content identifier namespace using the corresponding SRV record. It will then dispatch a request to these content repositories to retrieve the content. It can optionally cache the content and then provide it back to the client. This entire process is transparent to the client. For example, a configuration scanning agent is ordered by the scanning manager to perform a scan on a repeating interval using a set of content. The set of content required is a list of OVAL definition IDs developed by a third party vendor hosted in the third party vendor's content repository. The agent has been preconfigured to point to the local content repository to which it sends a request to for the content. The local repository looks up the namespace associated with the third party content IDs in DNS retrieving the SRV record for the third party content repository. It dispatches a request for the content to the third party repository and retrieves the content, caching it, and providing it to the client.] As far as modeling discovery on DNS, I'm not sold, but that could just be a lack of understanding on my part -- and I still haven't had time to read your draft spec. [DAW: What I am suggesting is not "discovery" per se, it is resolution using DNS SRV records. This is the general purpose of the SRV mechanism.] But it sounds like a chicken-and-egg problem. In order to locate a repository you first have to know something about the repository -- the publisher's namespace URI from your example. In my experience discovery is more likely to be based on search criteria: affected platform, guidance source, supported languages, content formats, regulation applicability (SOX, HIPAA, etc), and so on. That's more like a searchable registry -- I don't see where DNS-style name resolution comes into it. [DAW: My example pre-supposes that the content IDs have already been selected. Meaning that the organization performing the scan pre-selected content from the third party registry. This introduces a third problem that needs to be solved that is a discovery style problem. For the web, we have web-based search engines that index content from a variety of sources and then provide persistent pointers to the location of the content. We probably need something like this too, but that is a concept that more than likely needs to be addressed by one or more additional specifications. Initially, organizations are going to seek content from sources that act as authorities for their organization or that are trusted. Discovery matters at the point where digital policy is constructed. In this scenario, if a content repository supports simple standardized query capabilities, we probably have a workable solution for the short-term. In my example above, the scanning manager is responsible for many different agents on many different hosts. The system user would create scanning configurations based on content they have pre-selected and these configurations would then get propagated to the individual scanners. The pre-selection could be the result of querying a list of authoritative and trusted repositories. This usage pattern also applies to single host and agentless approaches.] --gun On 5/18/2012 8:42 AM, Waltermire, David A. wrote: > My comments marked with [DAW2]. > > Sincerely, > Dave > > > -----Original Message----- > From: Chandrashekhar B [mailto:bchandra@secpod.com] > Sent: Friday, May 18, 2012 1:50 AM > To: Waltermire, David A.; 'Kurt Seifried' > Cc: sacm@ietf.org; SCAP-DEV > Subject: RE: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > My comments marked [CHA] > > Chandra. > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of Waltermire, David A. > Sent: Friday, May 18, 2012 8:02 AM > To: Kurt Seifried > Cc: sacm@ietf.org > Subject: Re: [sacm] [scap-dev] Request for participants - Content > Repository Specification Development > > Comments inline marked [DAW]. > > Sincerely, > Dave > > > -----Original Message----- > From: Kurt Seifried [mailto:kseifried@redhat.com] > Sent: Thursday, May 17, 2012 10:18 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [scap-dev] [sacm] Request for participants - Content > Repository Specification Development > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Note: all opinions/comments are my own, not official Red Hat policy > and so on. > > On 05/17/2012 07:19 PM, Waltermire, David A. wrote: >> Kurt, >> >> My assumption is that each organization would stand up a content >> repository based on this specification for their own authoritative >> content, content they produce. They would sign the content using >> their own private key. I haven't worked out an approach for public >> key distribution yet. It would be if we could use DNS or some other >> standardized key distribution mechanism. I am open to ideas. > > Ah my bad I assumed you guys were talking about the central repo > (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS). > > [DAW: I am assuming that there will be no central repo. From talking > with content publishers, there are IP rights and other issues with this type of approach. I think the better solution is to support a distributed network of repositories. Some organizations and consortiums may decide to stand up centralized repos for their own purposes. This should be allowed, but not required. > > [CHA: Yes, distributed network of repository, with may be a central > registry. Even for a central registry, I feel we aren't there yet. > Central repository or a registry would mean getting into operational > aspects, who'll own, manage, control etc., So, limiting it to > organizational repositories and content providers repository is good > in my view.] > > [DAW2: This is why I am advocating for a federated system. With the > right approach, we can avoid having to stand up a single central > registry and all the operational and logistical aspects involved. > Using the DNS SRV approach below, DNS essentially becomes the > registry. Using DNS, every organization that produces content is able > to point to the authoritative content repositories that they use to > host their content. They can create as many namespaces as needed, by > using sub-domains within their own domain(s). A SRV record would be > associated with each sub-domain in this case.] > > As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names. Many of the security automation identifiers have reverse DNS names incorporated into them. For those that done, simple DNS namespace qualification would provide the same effect. In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID. This can be handled using a DNS SRV record (RFC2783). We would need to get an IANA allocation for this (RFC6335). This approach avoids having to create a root server infrastructure for content repositories. > > I'd like to hear other thoughts related to X.509.] > > [CHA: I am not sure if I understand the DNS resolution approach here > completely, will anyway pose a question. If one content repository > were to host a content authored by someone else and the namespace > wasn't modified, may be for IP reasons. DNS namespace qualification > would not work if I want to pick the content from this repository > instead of the original author. Not sure if I am making sense :) ] > > [DAW2: I am modeling this approach after DNS. There are authoritative content servers that originate content. The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server. This is an analog to domains hosted by an authoritative DNS server. Here is a basic communication flow: > > 1) Client: sends request for content by ID to local, organizational content repository. > 2) Organizational repository: retrieve the requested content > a) If the namespace is a local namespace, return the content. > b) If the namespace is a foreign namespace, check if the content is > in the local cache. > c) Lookup the DNS SRV record associated with the ID's namespace. > d) Dispatch a request to the foreign authoritative content > repository based on the SRV record to retrieve the content > e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server. > 3) Organizational repository: respond to the client with the content > > This approach allows content for a given namespace to be managed by a single authoritative content repository. If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository. > > Access to local cache can (and probably should) be limited to IPs > within an organization or thru the use of access controls to prevent > leakage of cached content.] > >> It may also make sense to allow for counter signing of content to >> allow 3rd parties to sign content. Again, I have not worked out how >> best to do this. Any ideas? > > Chained signatures would be really nice, e.g. Linux vendor releases an > RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains. > > [DAW: agreed.] > >> Related to restricting access to content, it is my hope that content >> is made freely available. For some kinds of content, it probably >> makes sense to support some kind of access control. This could be >> driven by commercialization of content or to restrict access to some >> content to authorized users within an organization. >> Client/Server certificates might be a mechanism to support this. > > I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will: > > 1) be incompatible (and thus either removed, or an active problem) for > many vendors/customers (I doubt any existing system for selling > content will end up being super compatible with what you guys build) > 2) be unnecessary in most (if not almost all) cases > 3) add significantly to the overhead of building this and not add any > real value to the actual problem space of securing machines > > For some idea of the scope of this type of problem check out > http://www.candlepinproject.org/ which provides subscription and > entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc. > > TLDR: Please, please don't do this, it'll be a huge time/effort sink > and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them. > > [DAW: Points well taken. I am interested in other thoughts on how > best to address this. What I was recommending was looking more > towards service authentication and less towards DRM. Maybe we don't > address this in the first pass. Thoughts?] > > [CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. > > In our repository, we have implemented a policy driven access control > and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. > > So, service authentication is required to be standardized. For access > control, may be an error condition if one is not allowed to fetch the > content?] > > [DAW2: agreed. I see this as a minimal standardization approach.] > >> I hope this answers your questions. >> >> Sincerely, Dave >> >> >> -----Original Message----- From: Kurt Seifried >> [mailto:kseifried@redhat.com] Sent: Thursday, May 17, 2012 9:11 PM >> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for >> participants - Content Repository Specification Development >> >> On 05/17/2012 04:44 PM, Waltermire, David A. wrote: >>> Good points. It makes sense to use the mechanisms provided by XML >>> (e.g. XMLDsig, XML Encryption) and capabilities provided by the >>> underlying transport (e.g. TLS) to address as much of this as >>> possible. It may be desirable to provide mechanisms for >>> authentication to restrict access to content. This may also need to >>> be integrated into the underlying transport. >> I have some questions, asking off list, not sure if they are >> appropriate, if they are feel free to reply on the list. >> >> 1) if using XMLDsig who would be the signing authority? How secure >> would signing be (e.g. using a hardware card/appliance/etc?). >> Where would the key be published/would it be signed/etc? 2) You >> mention restricting access to content, why would the content need to >> be restricted? Are there IP issues I am unaware of? >> >> Thanks >> >>> Sincerely, Dave >> > - - -- > Kurt Seifried Red Hat Security Response Team (SRT) > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ > uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR > GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK > MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf > LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew > xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus > u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r > GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH > TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK > +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi > oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv > XCldnHSPS6O7qeRTgMtL > =QJsL > -----END PGP SIGNATURE----- > _______________________________________________ > 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 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Wed May 23 05:39:00 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 A415F21F8648 for ; Wed, 23 May 2012 05:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.233 X-Spam-Level: X-Spam-Status: No, score=-101.233 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYvBi-cEkk3E for ; Wed, 23 May 2012 05:38:58 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.41.245.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6C21F8611 for ; Wed, 23 May 2012 05:38:58 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id C0D0368A8DBEF; Wed, 23 May 2012 07:38:57 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id B4FFA68A8DBCE for ; Wed, 23 May 2012 07:38:57 -0500 (CDT) Received: from [96.231.117.87] (port=39746 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SXAq6-0003K6-QQ; Wed, 23 May 2012 07:38:57 -0500 Message-ID: <4FBCDA5D.1090706@ieca.com> Date: Wed, 23 May 2012 08:38:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kent_Landfield@McAfee.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: pool-96-231-117-87.washdc.east.verizon.net (thunderfish.local) [96.231.117.87]:39746 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: SCAP-DEV@nist.gov, kathleen.moriarty@emc.com, sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specification Development 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, 23 May 2012 12:39:00 -0000 Kent, Technically, authors can specify really just about anything they want - but they're going to have to defend it. Some defenses are easier than others. At least one person said they'd have to ask why SOAP, and that they'd be skeptical of any answer that didn't involve interoperating with something written a long time ago. I asked around some to verify that my impression wasn't just mine and confirmed that SOAP has pretty much fallen out of favor while REST seems to be where it's at. You might ask why - well SOAP is XML based and XML has also fallen out of favor. As Kathleen pointed out, all the cool kids are doing JSON ;) For some, REST doesn't rely on XML so it's just better. Hope this helps, spt PS - But, if JSON ends up being used you're going to have to wait for a security solution. On 5/14/12 3:39 PM, kathleen.moriarty@emc.com wrote: > Sean – please do chime in. > > My .02: When MILE was INCH, the WG had thought SOAP and BEEP were good > solutions to fit the protocol (so the WG can drive what they think is > needed). But the IETF saw that the direction at the time was HTTPS, > which would seem to agree with the statement below. There really were > not many BEEP implementations, so it didn’t seem practical even if the > protocol design was a better fit. REST wasn’t popular then, so we also > took the approach to separate out the protocol from the binding to allow > for changes later (add new bindings). With this approach, you can build > in the security at the protocol so that you don’t rely fully on the > binding for authentication and encryption. > > Discussions in some WGs have been debating XML or JSON and there are 2 > camps here, but the theory of having a data model approach and selecting > one for the WG seems to be the go-forward decision. > > Best regards, > > Kathleen > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Kent_Landfield@McAfee.com > *Sent:* Monday, May 14, 2012 3:24 PM > *To:* SCAP-DEV@nist.gov; sacm@ietf.org > *Cc:* turners@ieca.com > *Subject:* Re: [sacm] Request for participants - Content Repository > Specification Development > > Hi Sean, > > Can you help here? I too have heard that but I want to make sure we are > not being confused by hearsay… > > Thanks. > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, David Waltermire > > *To: *"bchandra@secpod.com " > >, SCAP-DEV > >, "sacm@ietf.org > " > > *Subject: *Re: [sacm] Request for participants - Content Repository > Specification Development > > One problem with SOAP web services is that they are often considered > very heavy weight. From what I have seen, the IETF tends to prefer > lighter weight protocols (e.g. REST, standardized messages over > HTTP, etc). Anyone else have any insights on this? > > Sincerely, > > Dave > > -----Original Message----- > > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of Chandrashekhar B > > Sent: Saturday, May 12, 2012 2:43 AM > > To: SCAP-DEV; sacm@ietf.org > > Subject: Re: [sacm] Request for participants - Content Repository > Specification Development > > Having a standard access interface is really important for content > repository. I had proposed a simple WSDL in a presentation I shared > with Kent, last year's ITSAC. We are looking forward to take active > participation in it. > > Thanks, > > Chandra. > > www.secpod.com > > -----Original Message----- > > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach > > Sent: Friday, May 11, 2012 11:33 PM > > Cc: SCAP-DEV; sacm@ietf.org > > Subject: Re: [sacm] Request for participants - Content Repository > Specification Development > > It would be great to have as many of these considerations as > possible in mind from the start as the actual work begins. As > another example, I'd like to see active participation from vendors > that have commercial content repositories so those concerns also > don't have to be later addressed with major changes. > > But we also see a lot of these type of topics come up on the lists, > get discussed for a bit, then languish. If reducing the problem set > is what it takes to spur some action, let's get started. > > It kinda sounds like this is headed towards having a dedicated > working group to take it on, which is what I'd prefer to see, so I'm > avoiding making specific comments until then. > > And my apologies to Dave: I'd like to see how much you've already > addressed, but I just haven't had a chance to look through your > draft yet. > > --gun > > ThreatGuard, Inc. > > On 5/11/2012 1:13 PM, Waltermire, David A. wrote: > > Kent, > > I have already started work on a draft specification in this > area. My > > hope is that this work could be used as an initial draft within SACM > > at the appropriate time. Count me in. > > I mostly agree with what you are describing below. The only area I > > disagree with is in regards to federation. If we do not > implement the > > specification for an organizational repository in the right way, we > > may need to make major changes to support federation. This is not > > good for anyone. In my mind these two concepts cannot be decoupled. > > We need to insure that any work towards supporting an organizational > > repository provides a foundation for supporting a federated > repository network. > > Imagine if DNS was designed with a single organization mindset first > > without thinking about federation. Top Level Domains (TLDs) and > > subdomains would not likely exist as concepts. An individual DNS > > server would likely not support caching, time-to-live and delegating > > capabilities that are necessary for federation to happen. All of > > these things would need to be retrofitted. To prevent this, we need > > to address the building blocks of federation in the basic design. > > Sincerely, > > Dave > > *From:*Kent_Landfield@McAfee.com > > [mailto:Kent_Landfield@McAfee.com] > > *Sent:* Friday, May 11, 2012 12:36 PM > > *To:* m.kinne@radium.ncsc.mil ; > Waltermire, David A.; SCAP-DEV; > > sacm@ietf.org > > *Subject:* Request for participants - Content Repository > Specification > > Development > > Mike I love it when you tee something up like that.. ;-) Thank > you. ;) > > Mike wrote: > > I still think that any specification for a repository is wishful > > thinking until someone builds one and learns the lessons it will > just > > be another whitepaper spec. I believe the DoD needs to incorporate a > > metadata repository as part of it and other customizations that may > > not be useful for everyone. > > We need to talk more. > > If you are talking about a holistic, complete federated approach > to a > > content repository, I some what agree. If you are talking about an > > organizational repository, I totally disagree. But you knew I would. > > ;) > > Here is how I see the problem. There is an immediate need for > SCAP and > > other related content to be served up inside an organization. > Today we > > have situation where the standards allow us to provide sites the > > capability to have a single SCAP implemented policy they call > official > > for their environment. Yes this is a rather simplistic since > there are > > things such as targeting specific platforms, specific > operational use > > needs, but for now lets agree SCAP is a massive improvement over the > > proprietary situations of the past. While we have created this > > standard content so that sites can implement their local site > security > > once and then assure they are measuring all appropriately targeted > > devices the same way, we have failed to support the operational > needs of the sites. > > We have a situation where no two vendors distribute content the same > > way. This causes massive problems for the administration staff when > > they need to incorporate a new SCAP enabled product into their > architecture. > > They need to discover how the new product supports distributing SCAP > > content to it's various components. If they have one product > then they > > do this one and they are done. If they have multiple products they > > will have to figure out how to minimize the impact by incorporating > > the update process for the new product into the existing SCAP > security > > content processes. Now when the inevitable happens and the site > staff > > needs to make a change to their security policy, they have to > make the > > modifications to the benchmark or checks or both and then distribute > > those updates across their network. For each SCAP enabled > product they > > have in place, they have doubled, tripled or more the work needed to > > make those updates available. > > There is another content repository problem and that is the > Federated > > Content Distribution. If you think global DNS you have a general > frame > > of reference. The guidance authors need to be able to publish > content > > in an authoritative manner so their content is updated in a > timely fashion. > > This is a much harder problem to solve if there is no local > > organizational infrastructure to support it. ;) > > So here is what I am thinking. We should consider addressing > these as > > two separate but integrated efforts. I believe the Organizational > > Content Repository is the more critical piece that is actually > easier > > to address. The Federated Content Distribution should be a > subsequent > > effort integrating / augmenting the Organizational repository > > specification. > > Mike, to your point that we need someone to build one first. > That has > > happened already. I have one as do other vendors but what we don't > > have is the access specification. Ours are focused on our specific > > product needs. Additionally there is a company that has developed a > > commercial SCAP content repository that will be announced later this > > month. I won't steal their thunder but I was recently given a sneak > > peek at it and I must admit I was very impressed. Again, to your > point, it has been done. > > What is needed to address the initial operational problem is to > > develop a specification that provides a consistent means for all > SCAP > > products to retrieve the appropriate content as configured and > managed > > but the > > site. > > TO THAT END.. > > I am requesting participation from those in the community that > see the > > need and want to put in the work to make this specification > happen. I > > have talked to a couple of you but I do not want to assume your > > participation. If you are interested please contact me so we can get > > this started. > > Thanks! > > *Kent Landfield* > > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > > 5000 Headquarters Dr. > > Plano, Texas 75024 > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > *From: *, Michael A > > > > > > *To: *David Waltermire > > > >, SCAP-DEV > > > >, > "sacm@ietf.org > " > > > > > > *Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation > > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Dave, > > I have no problem with webinars, I do want to keep developer days > > actionable and use it to make decisions, and vote and accomplish > > things good or bad. I do not want this to be an informational > > briefing conference. > > Thanks for the links. > > I still think that any specification for a repository is wishful > > thinking until someone builds one and learns the lessons it will > > just be another whitepaper spec. I believe the DoD needs to > > incorporate a metadata repository as part of it and other > > customizations that may not be useful for everyone. > > We need to talk more. > > -Mike > > *From:*Waltermire, David A. [mailto:david.waltermire@nist.gov] > > *Sent:* Tuesday, May 08, 2012 10:44 AM > > *To:* Kinney, Michael A; SCAP-DEV; sacm@ietf.org > > > > > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > > Days: Summer 2012 at MITRE in Bedford, MA > > Mike, > > What about having webinars in-place of the 30 minute briefs? > > Regarding content management, we are building the prototype content > > repository for use in a production environment. As an open source > > project, it will be free for use by anyone interested. My thinking > > is that this project can bridge the gap until commercial solutions > > are available to augment it. This is a similar path that was > > followed with DNS (bind) and HTTP (apache). When it is ready for > > use, I am hoping to use it to host USGCB content. You would be > > welcome to use it for your needs. > > It is good that OCIL is moving forward. This is an important piece > > of supporting risk management and aspects of continuous monitoring. > > I would also like to see some discussion on OCIL at Developer Days. > > With the proposals we will likely have a sense of what needs to be > > discussed and what we can achieve consensus on outside the meeting. > > Remediation is a topic near and dear to my heart. I too would like > > to see it move forward. > > We just published the draft ASR specification for public comment. > > This specification supports enterprise aggregate reporting which > > greatly reduces the data volumes needed verses detailed host-based > > reports. This specification has been designed as a more robust > > replacement for LASR. It can be used in continuous monitoring > > applications to support aggregate data reporting needs (e.g. FISMA > > reporting, CyberScope). > > Here are the links: > > http://csrc.nist.gov/publications/PubsDrafts.html > > http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 > > The primary reason we have suggested waiting on XCCDF is not the > > internationalization issue. Many vendors have commented that they > > are still working on implementing the XCCDF 1.2.1 specification. We > > will be in a better place in a few months once more development > > around XCCDF has occurred. As we consider changes to the SCAP stack > > to address OCIL and other issues, we will identify areas that need > > improvement in XCCDF. These are good and necessary discussions to > > have now, but we have a good deal of work to do before we are ready > > to open up XCCDF. My suggestion is to work on these related areas > > and then work up change proposals for XCCDF as needed. By that time > > we should be ready to work on a new revision of XCCDF. > > I am also looking forward to the discussions at the conference. It > > has been too long. > > Sincerely, > > Dave > > *From:*Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil] > > *Sent:* Tuesday, May 08, 2012 7:09 AM > > *To:* SCAP-DEV > > *Cc:* Waltermire, David A. > > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > It's good to read your thoughts, and a realistic actionable approach > > is indeed needed. Since all the activity hasn't been on the lists a > > brief 1Ž2 hour recap may be in order to bring everyone up to speed > > since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX > > CEE and others. > > We could write a content repository specification, but without > > someone willing to stand one up it will be as valuable as the CCSS > > specification is today. I've been trying for two years to get my > > management to get a coordinated effort together for the DoD to stand > > up a repository, it is a tough problem and will require funding with > > a tail, I'm not sure a specification will solve that problem. > > We (DoD) have been putting a lot of effort into OCIL over the last > > year trying to make it useful in an enterprise environment and will > > be posting our ideas to the list before developer days it should > > have already started, we need to get consensus and a vote on how the > > community wishes to proceed. > > Remediation is stalled but I'm making every effort to get it kick > > started from our perspective. I hope to assist in getting the draft > > ERI finished this year. We are writing some new STIG content and > > intend to used the draft CRE specification to insert CRE into the > > content so we (DoD) can do some automatic configuration fixes, part > > of a self healing network concept. It is just a start but the best > > we can do at this point. > > Enterprise reporting is an interesting subject, since XML adds size > > to and content to roll up reporting, in any enterprise of size the > > problem gets greater, I look forward to your thoughts on that > subject. > > I am concerned that the internationalization efforts are detracting > > from efforts to meet use cases, we have some things we would like > > changed in XCCDF to support our OCIl use case and I have been told > > that I need to wait. I didn't think that a move to > > internationalization should impede efforts to move forward with use > > cases. > > I look forward to talking with you at the conference. > > v/r > > Mike Kinney > > Project Director > > Computer Network Defense Research and Technology (CND R&T) Office > > 9800 Savage Road Ste 6767 > > Ft Meade, MD 20755-6767 > > Phone: 410-854-4422 > > NSTS: 968-8886 > > Fax 410-854-4681 > > makinn2@nsa.gov > > > *From:*scap-dev@nist.gov > > > [mailto:scap-dev@nist.gov] *On > > Behalf Of *Waltermire, David A. > > *Sent:* Monday, May 07, 2012 7:09 PM > > *To:* Multiple recipients of list > > *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer > > Days: Summer 2012 at MITRE in Bedford, MA > > Kent, > > I like what you are saying here. We are also in support of this type > > of approach. We would like to see some community discussion around > > what are the key areas/priorities that the community would like to > > see discussed at Dev Days. Your topics below look like a good start. > > The SACM list might be a better venue than the OVAL list for this > > discussion. For each area we should focus the discussion around > > developing objectives for each session. The sessions can be time > > boxed based on what would be a reasonable amount of time to > > accomplish each objective. For example if continuous monitoring is a > > priority and collectively it takes 3 days to work through all the > > objectives, I see no problem with that. We can also keep a few > > sessions "on deck" if all the objectives are reached and we complete > > all the scheduled sessions early. > > Thoughts? > > Sincerely, > > David Waltermire > > SCAP Architect > > National Institute of Standards and Technology > > (301) 975-3390 > > david.waltermire@nist.gov > > > *From:*scap-dev@nist.gov > > > [mailto:scap-dev@nist.gov] *On > > Behalf Of *Kent_Landfield@mcafee.com > > > > > *Sent:* Monday, May 07, 2012 4:25 PM > > *To:* SCAP-DEV > > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > > Days: Summer 2012 at MITRE in Bedford, MA > > All, > > I would like to discuss the format for the SCAP Developer Days that > > seems to be listed below. > > I see this appears to follow a path we have discussed in the past as > > the way not to hold a Dev Days event. We have been trying to get > > away from 'Death by Powerpoint' and back to the type of event we > > held years ago when we were highly productive. In the past we had a > > topic to be discussed and a time box to work within. That allowed us > > to have very active brainstorming sessions in a high bandwidth > > environment. > > At past Summer events we have got into a pattern of lots of > > powerpoint, lots of status of the efforts and very little discussion > > about things that need active discussions. We need to keep moving > > forward and making progress as an effort. We can get status from > > various places such as the lists, a presentation being sent out in > > advance, a webinar if it is felt there will be questions and answers > > from those that are new to the efforts. We have a limited amount of > > time and all who are attending are investing a great deal of time > > and money to be there. We should not be spending a great deal of > > time reeducating everyone when we could be focused on advancing > > needed efforts. > > The type of approach to a Dev Days event was discussed at the last > > Summer Dev Days. I have seen the following work quite well in other > > efforts. > > 1. Presentations are sent out to the attendees and the lists a week > > in advance. > > 2. Status for any effort is limited to 30 minutes > > 3. Focused brainstorming time should be established for certain > > areas that need real work by the community > > 4. Efforts to be discussed should be based on needs of the security > > automation space to move existing efforts to completion. > > For example: > > Continuous monitoring is a major direction the efforts are becoming > > involved with. There are going to be things we need to do as a > > security automation community to be able to accomplish what is > > listed in the CAESARS FE. There are interfaces that need to be > > worked and established. That is one area that is not listed below. > > CM will have a major impact on all of us in the next couple years > > and it is being ignored. We can't keep trying to solve what has > > already been solved. We need to address the needed interface > > development now. This is an effort that could take nearly a whole > > day by itself. > > Operationally we have a real need to be able to deliver SCAP content > > internally within an organization. Today the SCAP vendors cannot > > share a single local site security policy (XCCDF + OVAL + CPE +.) > > without the site staff having to go to each of the individual > > products and figuring out how to inject that new or updated policy > > into that products delivery mechanisms. That is limiting sites from > > wanting to buy multiple focused SCAP products since they are such a > > pain to manage from a content perspective. It is easier to buy from > > one vendor that has a single means for distributing content than it > > is to deal with the management issues that having multiple SCAP > > products presents. We need to have at least an entire 1/2 a day on > > the development of a Content Repository specification. > > OCIL is a positive and a negative at the same time. It has real > > value that is being underutilized and under implemented because of > > the limitations of how it addresses uses in an enterprise > > environment. People don't need security automation to do things > > on/for a single host. They need security automation to focus on the > > enterprise issues that reduce their costs and improve their > > efficiencies. OCIL is failing in the enterprise and we all > > understand that. We need to address developing a definitive solution > > for incorporating OCIL into the enterprise and that means into the > > existing specifications. Scheduling and tracking are key to it's > > success. We need to make that happen. This too needs a focused > > brainstorming time box to discuss options. > > I am really disappointed that Remediation is not on the list below. > > Yes, last Summer Dev Days, the time spent on Remediation was wasted > > time but that does not mean we should ignore it and not try to make > > some real progress. As far as I am concerned we need to reboot the > > remediation effort. We cannot keep being the set of specifications / > > tools that act as the little boy crying "Wolf" in the night. We need > > to be able to find and fix issues if we are going to really make a > > difference in organizational security postures. But today we think > > it is too hard so we don't try ? I think we need a couple hours to > > discuss the reboot of the effort even if that means minimizing work > > already done. > > A focused discussion on enterprise reporting is also critically > > needed. For the vendors here, we have all gone through the > > Cyberscope goat rope, delivering limited capabilities to specific > > data call requirements of the Federal Agencies. The initial effort > > was a mess, did little more than prove it was possible and cause the > > vendor community a great deal of thrashing to put a kludgey > > 'solution' in place. Reality is all our customers need roll up > > reporting and an infrastructure that supports it. A data call should > > not be special to anyone other than the agencies responding. The > > tools should be able to select the types of data needed and deliver > > that on a scheduled basis automatically. Enterprise Reporting > > pertains to commercial as well as Federal customers. We need to > > focus some time on what that would look like using the ARF and ASR > > as the foundational pieces. But there are missing pieces.. We need > > this discussed. > > I would hope we can make this summer's SCAP Dev Days useful in > > advancing the security automation efforts by addressing some of the > > more critical issues our customers are facing now or will be facing > > in the very short term. Status presentations are not interesting to > > those active in the efforts. Let's try to do those before we get to > > Bedford so we can real make some progress while we are all in the > > same room. This is always a big event for the 'consensus of the > > willing' that assemble and driven to see security automation make a > > difference. Let's see if we can have an event that, when we all walk > > out the last day, we all feel that every minute was well spent and > > moves us forward. > > Thanks. > > *Kent Landfield* > > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > > 5000 Headquarters Dr. > > Plano, Texas 75024 > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > *From: *, Steve > > > > > *Reply-To: *"OVAL Developer List (Closed Public Discussion)" > > > > > > > > *To: *"OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > > > > " > > > > > > > > *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer > > Days: Summer 2012 at MITRE in Bedford, MA > > Frank; > > We hope to have the registration site up next week. The event > > will be during the week of July 9 - starting Monday at 10:00 AM > > and ending on Friday at 12:00. > > Meanwhile, we are working on the agenda and are currently > > considering this list of topics: > > CCE > > CPE/SWID > > CEE > > XCCDF > > OVAL > > ASR > > Enterprise OCIL > > CybOX/MAEC > > Federated Content Repository Spec > > Endpoint Reporting for Continuous Monitoring and Compliance > > (ERCC) > > MILE > > TAXII > > IF-M for SCAP > > IF-MAP > > SCAP Releases > > SCAP and IETF > > NETCONF and SCAP > > Steve > > *From:*Frank Lindsay Acker [mailto:afrank@NOVA.EDU] > > *Sent:* Tuesday, May 01, 2012 9:32 AM > > *To:* oval-developer-list OVAL Developer List/Closed Public > > Discussion > > *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation > > Developer Days: Summer 2012 at MITRE in Bedford, MA > > Steve.... > > Has there been any additional information regarding this event? > > Thanks, > > Frank Acker > > ------------------------------------------------------------------------ > > *From:*Boczenowski, Steve [sboczeno@MITRE.ORG > > > ] > > *Sent:* Tuesday, March 20, 2012 16:38 > > *To:* OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG > > > > > *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer > > Days: Summer 2012 at MITRE in Bedford, MA > > Save the Date: week of July 9, 2012 > > This year's MITRE-hosted Security Automation Developer Days > > event will be held during the week of July 9, 2012 at MITRE's > > facility in Bedford, MA. > > Details to follow. > > Regards, > > Steve > > ______________________________________________ > > /Stephen P. Boczenowski/ > > The MITRECorporation > > Office: (781) 271-7682 > > Cell: (978) 302-3849 > > sboczeno@mitre.org > > > To unsubscribe, send an email message to > > LISTSERV@LISTS.MITRE.ORG > with > > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > > have difficulties, write to > > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > > > . > > To unsubscribe, send an email message to > > LISTSERV@LISTS.MITRE.ORG > with > > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > > have difficulties, write to > > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > > > . > > To unsubscribe, send an email message to > > LISTSERV@LISTS.MITRE.ORG > with > > SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you > > have difficulties, write to > > OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG > > > . > > _______________________________________________ > > 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 > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > From prvs=489a8a45a=halbardier_adam@bah.com Tue May 29 08:35: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 E4FED11E808C for ; Tue, 29 May 2012 08:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfdEgPpN1Yt2 for ; Tue, 29 May 2012 08:35:07 -0700 (PDT) Received: from mclniron02-ext.bah.com (mclniron02-ext.bah.com [128.229.5.22]) by ietfa.amsl.com (Postfix) with ESMTP id AC54D21F8613 for ; Tue, 29 May 2012 08:35:06 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 10.12.10.218 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=xYpG0s+6OEYo55oDTxI+ZV10xUm87zK+RtXdz36pjHY= c=1 sm=2 a=dfkcHyh1kukA:10 a=dGKP-eO2SE8A:10 a=VSl--tYzzWsA:10 a=IkcTkHD0fZMA:10 a=SyYMxH9GAAAA:8 a=G0_B3m8xAAAA:8 a=48vgC7mUAAAA:8 a=o4D-YMODAAAA:8 a=_HsgSZrtAAAA:8 a=PYnjg3YJAAAA:8 a=sMBj6sIwAAAA:8 a=d1Je7BBudPJGVeSqnFUA:9 a=QEXdDO2ut3YA:10 a=1QQx0cDIF3AA:10 a=cjL59tRlRLsA:10 a=gELb6KLQ9YUA:10 a=XT4B79g8RrEA:10 a=hz29XmwHSwYA:10 a=HoppX_JdNxgA:10 a=AS2GB_Yci6YA:10 a=RNPrVPU4Xz8A:10 a=zlqjOcb3pwsA:10 a=fvCSaKYq87sA:10 a=czR-1NxMsvQA:10 a=7Mp4iTy_7NIA:10 a=Z8xhO9XkECYA:10 a=YbOTLnh8yesA:10 a=lW_bInUQU2sA:10 a=lZB815dzVvQA:10 a=De4saq_zUVgA:10 a=N8MQ_3apaBcA:10 a=caXvx148PxfaloSX:21 a=iqqnzNeCnFX3y1aZ:21 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEALHrxE8KDAra/2dsb2JhbAA6BwOFMK5zghmCFwEBAQMBAQEBFwEIERUFBhQGBQsHAgICAQgHCgECAQEBAQICBh0DAgICFAUMAQkBFAECBggCBAEHBwQBBwwHAgSHZRCmGJI8BIEgiV8QBIICggkyYAOScoM0kUKBVgk X-IronPort-AV: E=Sophos;i="4.75,677,1330923600"; d="scan'208";a="412483188" Received: from ashbcwsv03.usae.bah.com (HELO ASHBCSHB06.resource.ds.bah.com) ([10.12.10.218]) by mclniron02-int.bah.com with ESMTP; 29 May 2012 11:35:03 -0400 Received: from ASHBDAG1M3.resource.ds.bah.com ([169.254.4.143]) by ASHBCSHB06.resource.ds.bah.com ([10.12.10.218]) with mapi id 14.01.0355.002; Tue, 29 May 2012 11:34:50 -0400 From: "Halbardier, Adam [USA]" To: SCAP-DEV , "sacm@ietf.org" Thread-Topic: [scap-dev] [sacm] Request for participants - Content Repository Specification Development Thread-Index: AQHNMgczbXdPvqE6NkGH4VTUCL/h+5bJ8ZSAgA2vcYCACZ8ygA== Date: Tue, 29 May 2012 15:34:49 +0000 Message-ID: <2578EC0197492A4384C669854F185EAB13AE53@ASHBDAG1M3.resource.ds.bah.com> References: <4FBCDA5D.1090706@ieca.com> In-Reply-To: <4FBCDA5D.1090706@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.230.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development 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, 29 May 2012 15:35:10 -0000 Rm9yZ2l2ZSB0aGUgZGVsYXllZCByZXNwb25zZS4gV2hpbGUgUkVTVCBpcyBsaWdodHdlaWdodCBj b21wYXJlZCB0byBTT0FQLCBTT0FQIGlzIGZhdm9yYWJsZSB3aGVuIHRoZSBzbGV3IG9mIFdTLSog c3BlY2lmaWNhdGlvbnMgYXJlIGxldmVyYWdlZCAocmVhZDogcmVxdWlyZWQpLiBUaGUgY2FwYWJp bGl0aWVzIG1hbnkgV1MtKiBzcGVjaWZpY2F0aW9ucyBicmluZyB0byBTT0FQIGFzIGJ1aWx0LWlu IGZlYXR1cmVzIGhhdmUgdG8gYmUgYnJ1dGUtZm9yY2VkIGluIGEgbWFudWFsIGZhc2hpb24gaW4g UkVTVC4gSW4gdGhhdCBjYXNlLCBTT0FQIGhvbGRzIGEgY2VydGFpbiBlbGVnYW5jZSB0aGF0J3Mg bG9zdCBvbiBSRVNULiBXaGVuIHRob3NlIHJlcXVpcmVtZW50cyBhcmVuJ3QgcHJlc2VudCwgdGhv dWdoLCBSRVNUIGRvZXMgZ2VuZXJhbGx5IHJlZHVjZSB0aGUgY29tcGxleGl0eSBhbmQgbWVzc2Fn ZSBzaXplIG9mIHNlcnZpY2VzLg0KDQotQWRhbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc2NhcC1kZXYtYm91bmNlc0BuaXN0LmdvdiBbbWFpbHRvOnNjYXAtZGV2LWJvdW5j ZXNAbmlzdC5nb3ZdIE9uIEJlaGFsZiBPZiBTZWFuIFR1cm5lcg0KU2VudDogV2VkbmVzZGF5LCBN YXkgMjMsIDIwMTIgNTozOSBBTQ0KVG86IEtlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20NCkNjOiBT Q0FQLURFVjsga2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbTsgc2FjbUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzY2FwLWRldl0gW3NhY21dIFJlcXVlc3QgZm9yIHBhcnRpY2lwYW50cyAtIENvbnRl bnQgUmVwb3NpdG9yeSBTcGVjaWZpY2F0aW9uIERldmVsb3BtZW50DQoNCktlbnQsDQoNClRlY2hu aWNhbGx5LCBhdXRob3JzIGNhbiBzcGVjaWZ5IHJlYWxseSBqdXN0IGFib3V0IGFueXRoaW5nIHRo ZXkgd2FudCAtIGJ1dCB0aGV5J3JlIGdvaW5nIHRvIGhhdmUgdG8gZGVmZW5kIGl0LiAgU29tZSBk ZWZlbnNlcyBhcmUgZWFzaWVyIHRoYW4gb3RoZXJzLiAgQXQgbGVhc3Qgb25lIHBlcnNvbiBzYWlk IHRoZXknZCBoYXZlIHRvIGFzayB3aHkgU09BUCwgYW5kIHRoYXQgdGhleSdkIGJlIHNrZXB0aWNh bCBvZiBhbnkgYW5zd2VyIHRoYXQgZGlkbid0IGludm9sdmUgaW50ZXJvcGVyYXRpbmcgd2l0aCBz b21ldGhpbmcgd3JpdHRlbiBhIGxvbmcgdGltZSBhZ28uDQoNCkkgYXNrZWQgYXJvdW5kIHNvbWUg dG8gdmVyaWZ5IHRoYXQgbXkgaW1wcmVzc2lvbiB3YXNuJ3QganVzdCBtaW5lIGFuZCBjb25maXJt ZWQgdGhhdCBTT0FQIGhhcyBwcmV0dHkgbXVjaCBmYWxsZW4gb3V0IG9mIGZhdm9yIHdoaWxlIFJF U1Qgc2VlbXMgdG8gYmUgd2hlcmUgaXQncyBhdC4gIFlvdSBtaWdodCBhc2sgd2h5IC0gd2VsbCBT T0FQIGlzIFhNTCBiYXNlZCBhbmQgWE1MIGhhcyBhbHNvIGZhbGxlbiBvdXQgb2YgZmF2b3IuICBB cyBLYXRobGVlbiBwb2ludGVkIG91dCwgYWxsIHRoZSBjb29sIGtpZHMgYXJlIGRvaW5nIEpTT04g OykgIEZvciBzb21lLCBSRVNUIGRvZXNuJ3QgcmVseSBvbiBYTUwgc28gaXQncyBqdXN0IGJldHRl ci4NCg0KSG9wZSB0aGlzIGhlbHBzLA0KDQpzcHQNCg0KUFMgLSBCdXQsIGlmIEpTT04gZW5kcyB1 cCBiZWluZyB1c2VkIHlvdSdyZSBnb2luZyB0byBoYXZlIHRvIHdhaXQgZm9yIGEgc2VjdXJpdHkg c29sdXRpb24uDQoNCk9uIDUvMTQvMTIgMzozOSBQTSwga2F0aGxlZW4ubW9yaWFydHlAZW1jLmNv bSB3cm90ZToNCj4gU2VhbiDigJMgcGxlYXNlIGRvIGNoaW1lIGluLg0KPg0KPiBNeSAuMDI6ICAg V2hlbiBNSUxFIHdhcyBJTkNILCB0aGUgV0cgaGFkIHRob3VnaHQgU09BUCBhbmQgQkVFUCB3ZXJl IGdvb2QNCj4gc29sdXRpb25zIHRvIGZpdCB0aGUgcHJvdG9jb2wgKHNvIHRoZSBXRyBjYW4gZHJp dmUgd2hhdCB0aGV5IHRoaW5rIGlzIA0KPiBuZWVkZWQpLiAgQnV0IHRoZSBJRVRGIHNhdyB0aGF0 IHRoZSBkaXJlY3Rpb24gYXQgdGhlIHRpbWUgd2FzIEhUVFBTLCANCj4gd2hpY2ggd291bGQgc2Vl bSB0byBhZ3JlZSB3aXRoIHRoZSBzdGF0ZW1lbnQgYmVsb3cuICBUaGVyZSByZWFsbHkgd2VyZSAN Cj4gbm90IG1hbnkgQkVFUCBpbXBsZW1lbnRhdGlvbnMsIHNvIGl0IGRpZG7igJl0IHNlZW0gcHJh Y3RpY2FsIGV2ZW4gaWYgdGhlIA0KPiBwcm90b2NvbCBkZXNpZ24gd2FzIGEgYmV0dGVyIGZpdC4g IFJFU1Qgd2FzbuKAmXQgcG9wdWxhciB0aGVuLCBzbyB3ZSANCj4gYWxzbyB0b29rIHRoZSBhcHBy b2FjaCB0byBzZXBhcmF0ZSBvdXQgdGhlIHByb3RvY29sIGZyb20gdGhlIGJpbmRpbmcgDQo+IHRv IGFsbG93IGZvciBjaGFuZ2VzIGxhdGVyIChhZGQgbmV3IGJpbmRpbmdzKS4gIFdpdGggdGhpcyBh cHByb2FjaCwgDQo+IHlvdSBjYW4gYnVpbGQgaW4gdGhlIHNlY3VyaXR5IGF0IHRoZSBwcm90b2Nv bCBzbyB0aGF0IHlvdSBkb27igJl0IHJlbHkgDQo+IGZ1bGx5IG9uIHRoZSBiaW5kaW5nIGZvciBh dXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbi4NCj4NCj4gRGlzY3Vzc2lvbnMgaW4gc29tZSBX R3MgaGF2ZSBiZWVuIGRlYmF0aW5nIFhNTCBvciBKU09OIGFuZCB0aGVyZSBhcmUgMiANCj4gY2Ft cHMgaGVyZSwgYnV0IHRoZSB0aGVvcnkgb2YgaGF2aW5nIGEgZGF0YSBtb2RlbCBhcHByb2FjaCBh bmQgDQo+IHNlbGVjdGluZyBvbmUgZm9yIHRoZSBXRyBzZWVtcyB0byBiZSB0aGUgZ28tZm9yd2Fy ZCBkZWNpc2lvbi4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBLYXRobGVlbg0KPg0KPiAqRnJv bToqc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnXSAq T24gQmVoYWxmIA0KPiBPZiAqS2VudF9MYW5kZmllbGRATWNBZmVlLmNvbQ0KPiAqU2VudDoqIE1v bmRheSwgTWF5IDE0LCAyMDEyIDM6MjQgUE0NCj4gKlRvOiogU0NBUC1ERVZAbmlzdC5nb3Y7IHNh Y21AaWV0Zi5vcmcNCj4gKkNjOiogdHVybmVyc0BpZWNhLmNvbQ0KPiAqU3ViamVjdDoqIFJlOiBb c2FjbV0gUmVxdWVzdCBmb3IgcGFydGljaXBhbnRzIC0gQ29udGVudCBSZXBvc2l0b3J5IA0KPiBT cGVjaWZpY2F0aW9uIERldmVsb3BtZW50DQo+DQo+IEhpIFNlYW4sDQo+DQo+IENhbiB5b3UgaGVs cCBoZXJlPyBJIHRvbyBoYXZlIGhlYXJkIHRoYXQgYnV0IEkgd2FudCB0byBtYWtlIHN1cmUgd2Ug DQo+IGFyZSBub3QgYmVpbmcgY29uZnVzZWQgYnkgaGVhcnNheeKApg0KPg0KPiBUaGFua3MuDQo+ DQo+ICpLZW50IExhbmRmaWVsZCoNCj4gRGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0 ZWN0dXJlIGFuZCBTdGFuZGFyZHMNCj4NCj4gKk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnkqDQo+ IDUwMDAgSGVhZHF1YXJ0ZXJzIERyLg0KPiBQbGFubywgVGV4YXMgNzUwMjQNCj4NCj4gRGlyZWN0 OiArMS45NzIuOTYzLjcwOTYNCj4gTW9iaWxlOiArMS44MTcuNjM3LjgwMjYNCj4gKldlYjogKnd3 dy5tY2FmZWUuY29tIDxodHRwOi8vd3d3Lm1jYWZlZS5jb20vPg0KPg0KPiAqRnJvbTogKjxXYWx0 ZXJtaXJlPiwgRGF2aWQgV2FsdGVybWlyZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiANCj4g PG1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Pj4NCj4gKlRvOiAqImJjaGFuZHJhQHNl Y3BvZC5jb20gPG1haWx0bzpiY2hhbmRyYUBzZWNwb2QuY29tPiINCj4gPGJjaGFuZHJhQHNlY3Bv ZC5jb20gPG1haWx0bzpiY2hhbmRyYUBzZWNwb2QuY29tPj4sIFNDQVAtREVWIA0KPiA8U0NBUC1E RVZAbmlzdC5nb3YgPG1haWx0bzpTQ0FQLURFVkBuaXN0Lmdvdj4+LCAic2FjbUBpZXRmLm9yZyAN Cj4gPG1haWx0bzpzYWNtQGlldGYub3JnPiIgPHNhY21AaWV0Zi5vcmcgPG1haWx0bzpzYWNtQGll dGYub3JnPj4NCj4gKlN1YmplY3Q6ICpSZTogW3NhY21dIFJlcXVlc3QgZm9yIHBhcnRpY2lwYW50 cyAtIENvbnRlbnQgUmVwb3NpdG9yeSANCj4gU3BlY2lmaWNhdGlvbiBEZXZlbG9wbWVudA0KPg0K PiAgICAgT25lIHByb2JsZW0gd2l0aCBTT0FQIHdlYiBzZXJ2aWNlcyBpcyB0aGF0IHRoZXkgYXJl IG9mdGVuIGNvbnNpZGVyZWQNCj4gICAgIHZlcnkgaGVhdnkgd2VpZ2h0LiBGcm9tIHdoYXQgSSBo YXZlIHNlZW4sIHRoZSBJRVRGIHRlbmRzIHRvIHByZWZlcg0KPiAgICAgbGlnaHRlciB3ZWlnaHQg cHJvdG9jb2xzIChlLmcuIFJFU1QsIHN0YW5kYXJkaXplZCBtZXNzYWdlcyBvdmVyDQo+ICAgICBI VFRQLCBldGMpLiBBbnlvbmUgZWxzZSBoYXZlIGFueSBpbnNpZ2h0cyBvbiB0aGlzPw0KPg0KPiAg ICAgU2luY2VyZWx5LA0KPg0KPiAgICAgRGF2ZQ0KPg0KPiAgICAgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4NCj4gICAgIEZyb206IHNhY20tYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnNh Y20tYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgIFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQ2hhbmRyYXNoZWtoYXIgQg0KPg0KPiAgICAgU2VudDogU2F0dXJkYXks IE1heSAxMiwgMjAxMiAyOjQzIEFNDQo+DQo+ICAgICBUbzogU0NBUC1ERVY7IHNhY21AaWV0Zi5v cmcgPG1haWx0bzpzYWNtQGlldGYub3JnPg0KPg0KPiAgICAgU3ViamVjdDogUmU6IFtzYWNtXSBS ZXF1ZXN0IGZvciBwYXJ0aWNpcGFudHMgLSBDb250ZW50IFJlcG9zaXRvcnkNCj4gICAgIFNwZWNp ZmljYXRpb24gRGV2ZWxvcG1lbnQNCj4NCj4gICAgIEhhdmluZyBhIHN0YW5kYXJkIGFjY2VzcyBp bnRlcmZhY2UgaXMgcmVhbGx5IGltcG9ydGFudCBmb3IgY29udGVudA0KPiAgICAgcmVwb3NpdG9y eS4gSSBoYWQgcHJvcG9zZWQgYSBzaW1wbGUgV1NETCBpbiBhIHByZXNlbnRhdGlvbiBJIHNoYXJl ZA0KPiAgICAgd2l0aCBLZW50LCBsYXN0IHllYXIncyBJVFNBQy4gV2UgYXJlIGxvb2tpbmcgZm9y d2FyZCB0byB0YWtlIGFjdGl2ZQ0KPiAgICAgcGFydGljaXBhdGlvbiBpbiBpdC4NCj4NCj4gICAg IFRoYW5rcywNCj4NCj4gICAgIENoYW5kcmEuDQo+DQo+ICAgICB3d3cuc2VjcG9kLmNvbQ0KPg0K PiAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4NCj4gICAgIEZyb206IHNhY20tYm91 bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgIFttYWls dG86c2FjbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3VubmFyIEVuZ2VsYmFjaA0K Pg0KPiAgICAgU2VudDogRnJpZGF5LCBNYXkgMTEsIDIwMTIgMTE6MzMgUE0NCj4NCj4gICAgIENj OiBTQ0FQLURFVjsgc2FjbUBpZXRmLm9yZyA8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQo+DQo+ICAg ICBTdWJqZWN0OiBSZTogW3NhY21dIFJlcXVlc3QgZm9yIHBhcnRpY2lwYW50cyAtIENvbnRlbnQg UmVwb3NpdG9yeQ0KPiAgICAgU3BlY2lmaWNhdGlvbiBEZXZlbG9wbWVudA0KPg0KPiAgICAgSXQg d291bGQgYmUgZ3JlYXQgdG8gaGF2ZSBhcyBtYW55IG9mIHRoZXNlIGNvbnNpZGVyYXRpb25zIGFz DQo+ICAgICBwb3NzaWJsZSBpbiBtaW5kIGZyb20gdGhlIHN0YXJ0IGFzIHRoZSBhY3R1YWwgd29y ayBiZWdpbnMuIEFzDQo+ICAgICBhbm90aGVyIGV4YW1wbGUsIEknZCBsaWtlIHRvIHNlZSBhY3Rp dmUgcGFydGljaXBhdGlvbiBmcm9tIHZlbmRvcnMNCj4gICAgIHRoYXQgaGF2ZSBjb21tZXJjaWFs IGNvbnRlbnQgcmVwb3NpdG9yaWVzIHNvIHRob3NlIGNvbmNlcm5zIGFsc28NCj4gICAgIGRvbid0 IGhhdmUgdG8gYmUgbGF0ZXIgYWRkcmVzc2VkIHdpdGggbWFqb3IgY2hhbmdlcy4NCj4NCj4gICAg IEJ1dCB3ZSBhbHNvIHNlZSBhIGxvdCBvZiB0aGVzZSB0eXBlIG9mIHRvcGljcyBjb21lIHVwIG9u IHRoZSBsaXN0cywNCj4gICAgIGdldCBkaXNjdXNzZWQgZm9yIGEgYml0LCB0aGVuIGxhbmd1aXNo LiBJZiByZWR1Y2luZyB0aGUgcHJvYmxlbSBzZXQNCj4gICAgIGlzIHdoYXQgaXQgdGFrZXMgdG8g c3B1ciBzb21lIGFjdGlvbiwgbGV0J3MgZ2V0IHN0YXJ0ZWQuDQo+DQo+ICAgICBJdCBraW5kYSBz b3VuZHMgbGlrZSB0aGlzIGlzIGhlYWRlZCB0b3dhcmRzIGhhdmluZyBhIGRlZGljYXRlZA0KPiAg ICAgd29ya2luZyBncm91cCB0byB0YWtlIGl0IG9uLCB3aGljaCBpcyB3aGF0IEknZCBwcmVmZXIg dG8gc2VlLCBzbyBJJ20NCj4gICAgIGF2b2lkaW5nIG1ha2luZyBzcGVjaWZpYyBjb21tZW50cyB1 bnRpbCB0aGVuLg0KPg0KPiAgICAgQW5kIG15IGFwb2xvZ2llcyB0byBEYXZlOiBJJ2QgbGlrZSB0 byBzZWUgaG93IG11Y2ggeW91J3ZlIGFscmVhZHkNCj4gICAgIGFkZHJlc3NlZCwgYnV0IEkganVz dCBoYXZlbid0IGhhZCBhIGNoYW5jZSB0byBsb29rIHRocm91Z2ggeW91cg0KPiAgICAgZHJhZnQg eWV0Lg0KPg0KPiAgICAgLS1ndW4NCj4NCj4gICAgIFRocmVhdEd1YXJkLCBJbmMuDQo+DQo+ICAg ICBPbiA1LzExLzIwMTIgMToxMyBQTSwgV2FsdGVybWlyZSwgRGF2aWQgQS4gd3JvdGU6DQo+DQo+ ICAgICAgICAgS2VudCwNCj4NCj4gICAgICAgICBJIGhhdmUgYWxyZWFkeSBzdGFydGVkIHdvcmsg b24gYSBkcmFmdCBzcGVjaWZpY2F0aW9uIGluIHRoaXMNCj4gICAgICAgICBhcmVhLiBNeQ0KPg0K PiAgICAgICAgIGhvcGUgaXMgdGhhdCB0aGlzIHdvcmsgY291bGQgYmUgdXNlZCBhcyBhbiBpbml0 aWFsIGRyYWZ0IA0KPiB3aXRoaW4gU0FDTQ0KPg0KPiAgICAgICAgIGF0IHRoZSBhcHByb3ByaWF0 ZSB0aW1lLiBDb3VudCBtZSBpbi4NCj4NCj4gICAgICAgICBJIG1vc3RseSBhZ3JlZSB3aXRoIHdo YXQgeW91IGFyZSBkZXNjcmliaW5nIGJlbG93LiBUaGUgb25seSANCj4gYXJlYSBJDQo+DQo+ICAg ICAgICAgZGlzYWdyZWUgd2l0aCBpcyBpbiByZWdhcmRzIHRvIGZlZGVyYXRpb24uIElmIHdlIGRv IG5vdA0KPiAgICAgICAgIGltcGxlbWVudCB0aGUNCj4NCj4gICAgICAgICBzcGVjaWZpY2F0aW9u IGZvciBhbiBvcmdhbml6YXRpb25hbCByZXBvc2l0b3J5IGluIHRoZSByaWdodCANCj4gd2F5LCB3 ZQ0KPg0KPiAgICAgICAgIG1heSBuZWVkIHRvIG1ha2UgbWFqb3IgY2hhbmdlcyB0byBzdXBwb3J0 IGZlZGVyYXRpb24uIFRoaXMgaXMgDQo+IG5vdA0KPg0KPiAgICAgICAgIGdvb2QgZm9yIGFueW9u ZS4gSW4gbXkgbWluZCB0aGVzZSB0d28gY29uY2VwdHMgY2Fubm90IGJlIGRlY291cGxlZC4NCj4N Cj4gICAgICAgICBXZSBuZWVkIHRvIGluc3VyZSB0aGF0IGFueSB3b3JrIHRvd2FyZHMgc3VwcG9y dGluZyBhbiANCj4gb3JnYW5pemF0aW9uYWwNCj4NCj4gICAgICAgICByZXBvc2l0b3J5IHByb3Zp ZGVzIGEgZm91bmRhdGlvbiBmb3Igc3VwcG9ydGluZyBhIGZlZGVyYXRlZA0KPiAgICAgICAgIHJl cG9zaXRvcnkgbmV0d29yay4NCj4NCj4gICAgICAgICBJbWFnaW5lIGlmIEROUyB3YXMgZGVzaWdu ZWQgd2l0aCBhIHNpbmdsZSBvcmdhbml6YXRpb24gbWluZHNldCANCj4gZmlyc3QNCj4NCj4gICAg ICAgICB3aXRob3V0IHRoaW5raW5nIGFib3V0IGZlZGVyYXRpb24uIFRvcCBMZXZlbCBEb21haW5z IChUTERzKSANCj4gYW5kDQo+DQo+ICAgICAgICAgc3ViZG9tYWlucyB3b3VsZCBub3QgbGlrZWx5 IGV4aXN0IGFzIGNvbmNlcHRzLiBBbiBpbmRpdmlkdWFsIA0KPiBETlMNCj4NCj4gICAgICAgICBz ZXJ2ZXIgd291bGQgbGlrZWx5IG5vdCBzdXBwb3J0IGNhY2hpbmcsIHRpbWUtdG8tbGl2ZSBhbmQg DQo+IGRlbGVnYXRpbmcNCj4NCj4gICAgICAgICBjYXBhYmlsaXRpZXMgdGhhdCBhcmUgbmVjZXNz YXJ5IGZvciBmZWRlcmF0aW9uIHRvIGhhcHBlbi4gQWxsIA0KPiBvZg0KPg0KPiAgICAgICAgIHRo ZXNlIHRoaW5ncyB3b3VsZCBuZWVkIHRvIGJlIHJldHJvZml0dGVkLiBUbyBwcmV2ZW50IHRoaXMs IHdlIA0KPiBuZWVkDQo+DQo+ICAgICAgICAgdG8gYWRkcmVzcyB0aGUgYnVpbGRpbmcgYmxvY2tz IG9mIGZlZGVyYXRpb24gaW4gdGhlIGJhc2ljIGRlc2lnbi4NCj4NCj4gICAgICAgICBTaW5jZXJl bHksDQo+DQo+ICAgICAgICAgRGF2ZQ0KPg0KPiAgICAgICAgICpGcm9tOipLZW50X0xhbmRmaWVs ZEBNY0FmZWUuY29tDQo+ICAgICAgICAgPG1haWx0bzoqS2VudF9MYW5kZmllbGRATWNBZmVlLmNv bT4NCj4gICAgICAgICBbbWFpbHRvOktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb21dDQo+DQo+ICAg ICAgICAgKlNlbnQ6KiBGcmlkYXksIE1heSAxMSwgMjAxMiAxMjozNiBQTQ0KPg0KPiAgICAgICAg ICpUbzoqIG0ua2lubmVAcmFkaXVtLm5jc2MubWlsIDxtYWlsdG86bS5raW5uZUByYWRpdW0ubmNz Yy5taWw+Ow0KPiAgICAgICAgIFdhbHRlcm1pcmUsIERhdmlkIEEuOyBTQ0FQLURFVjsNCj4NCj4g ICAgIHNhY21AaWV0Zi5vcmcgPG1haWx0bzpzYWNtQGlldGYub3JnPg0KPg0KPiAgICAgICAgICpT dWJqZWN0OiogUmVxdWVzdCBmb3IgcGFydGljaXBhbnRzIC0gQ29udGVudCBSZXBvc2l0b3J5DQo+ ICAgICAgICAgU3BlY2lmaWNhdGlvbg0KPg0KPiAgICAgICAgIERldmVsb3BtZW50DQo+DQo+ICAg ICAgICAgTWlrZSBJIGxvdmUgaXQgd2hlbiB5b3UgdGVlIHNvbWV0aGluZyB1cCBsaWtlIHRoYXQu LiA7LSkgVGhhbmsNCj4gICAgICAgICB5b3UuIDspDQo+DQo+ICAgICAgICAgTWlrZSB3cm90ZToN Cj4NCj4gICAgICAgICBJIHN0aWxsIHRoaW5rIHRoYXQgYW55IHNwZWNpZmljYXRpb24gZm9yIGEg cmVwb3NpdG9yeSBpcyANCj4gd2lzaGZ1bA0KPg0KPiAgICAgICAgIHRoaW5raW5nIHVudGlsIHNv bWVvbmUgYnVpbGRzIG9uZSBhbmQgbGVhcm5zIHRoZSBsZXNzb25zIGl0IHdpbGwNCj4gICAgICAg ICBqdXN0DQo+DQo+ICAgICAgICAgYmUgYW5vdGhlciB3aGl0ZXBhcGVyIHNwZWMuIEkgYmVsaWV2 ZSB0aGUgRG9EIG5lZWRzIHRvIA0KPiBpbmNvcnBvcmF0ZSBhDQo+DQo+ICAgICAgICAgbWV0YWRh dGEgcmVwb3NpdG9yeSBhcyBwYXJ0IG9mIGl0IGFuZCBvdGhlciBjdXN0b21pemF0aW9ucyANCj4g dGhhdCBtYXkNCj4NCj4gICAgICAgICBub3QgYmUgdXNlZnVsIGZvciBldmVyeW9uZS4NCj4NCj4g ICAgICAgICBXZSBuZWVkIHRvIHRhbGsgbW9yZS4NCj4NCj4gICAgICAgICBJZiB5b3UgYXJlIHRh bGtpbmcgYWJvdXQgYSBob2xpc3RpYywgY29tcGxldGUgZmVkZXJhdGVkIGFwcHJvYWNoDQo+ICAg ICAgICAgdG8gYQ0KPg0KPiAgICAgICAgIGNvbnRlbnQgcmVwb3NpdG9yeSwgSSBzb21lIHdoYXQg YWdyZWUuIElmIHlvdSBhcmUgdGFsa2luZyANCj4gYWJvdXQgYW4NCj4NCj4gICAgICAgICBvcmdh bml6YXRpb25hbCByZXBvc2l0b3J5LCBJIHRvdGFsbHkgZGlzYWdyZWUuIEJ1dCB5b3Uga25ldyBJ IHdvdWxkLg0KPg0KPiAgICAgICAgIDspDQo+DQo+ICAgICAgICAgSGVyZSBpcyBob3cgSSBzZWUg dGhlIHByb2JsZW0uIFRoZXJlIGlzIGFuIGltbWVkaWF0ZSBuZWVkIGZvcg0KPiAgICAgICAgIFND QVAgYW5kDQo+DQo+ICAgICAgICAgb3RoZXIgcmVsYXRlZCBjb250ZW50IHRvIGJlIHNlcnZlZCB1 cCBpbnNpZGUgYW4gb3JnYW5pemF0aW9uLg0KPiAgICAgICAgIFRvZGF5IHdlDQo+DQo+ICAgICAg ICAgaGF2ZSBzaXR1YXRpb24gd2hlcmUgdGhlIHN0YW5kYXJkcyBhbGxvdyB1cyB0byBwcm92aWRl IHNpdGVzIA0KPiB0aGUNCj4NCj4gICAgICAgICBjYXBhYmlsaXR5IHRvIGhhdmUgYSBzaW5nbGUg U0NBUCBpbXBsZW1lbnRlZCBwb2xpY3kgdGhleSBjYWxsDQo+ICAgICAgICAgb2ZmaWNpYWwNCj4N Cj4gICAgICAgICBmb3IgdGhlaXIgZW52aXJvbm1lbnQuIFllcyB0aGlzIGlzIGEgcmF0aGVyIHNp bXBsaXN0aWMgc2luY2UNCj4gICAgICAgICB0aGVyZSBhcmUNCj4NCj4gICAgICAgICB0aGluZ3Mg c3VjaCBhcyB0YXJnZXRpbmcgc3BlY2lmaWMgcGxhdGZvcm1zLCBzcGVjaWZpYw0KPiAgICAgICAg IG9wZXJhdGlvbmFsIHVzZQ0KPg0KPiAgICAgICAgIG5lZWRzLCBidXQgZm9yIG5vdyBsZXRzIGFn cmVlIFNDQVAgaXMgYSBtYXNzaXZlIGltcHJvdmVtZW50IA0KPiBvdmVyIHRoZQ0KPg0KPiAgICAg ICAgIHByb3ByaWV0YXJ5IHNpdHVhdGlvbnMgb2YgdGhlIHBhc3QuIFdoaWxlIHdlIGhhdmUgY3Jl YXRlZCB0aGlzDQo+DQo+ICAgICAgICAgc3RhbmRhcmQgY29udGVudCBzbyB0aGF0IHNpdGVzIGNh biBpbXBsZW1lbnQgdGhlaXIgbG9jYWwgc2l0ZQ0KPiAgICAgICAgIHNlY3VyaXR5DQo+DQo+ICAg ICAgICAgb25jZSBhbmQgdGhlbiBhc3N1cmUgdGhleSBhcmUgbWVhc3VyaW5nIGFsbCBhcHByb3By aWF0ZWx5IA0KPiB0YXJnZXRlZA0KPg0KPiAgICAgICAgIGRldmljZXMgdGhlIHNhbWUgd2F5LCB3 ZSBoYXZlIGZhaWxlZCB0byBzdXBwb3J0IHRoZSBvcGVyYXRpb25hbA0KPiAgICAgICAgIG5lZWRz IG9mIHRoZSBzaXRlcy4NCj4NCj4gICAgICAgICBXZSBoYXZlIGEgc2l0dWF0aW9uIHdoZXJlIG5v IHR3byB2ZW5kb3JzIGRpc3RyaWJ1dGUgY29udGVudCANCj4gdGhlIHNhbWUNCj4NCj4gICAgICAg ICB3YXkuIFRoaXMgY2F1c2VzIG1hc3NpdmUgcHJvYmxlbXMgZm9yIHRoZSBhZG1pbmlzdHJhdGlv biBzdGFmZiANCj4gd2hlbg0KPg0KPiAgICAgICAgIHRoZXkgbmVlZCB0byBpbmNvcnBvcmF0ZSBh IG5ldyBTQ0FQIGVuYWJsZWQgcHJvZHVjdCBpbnRvIHRoZWlyDQo+ICAgICAgICAgYXJjaGl0ZWN0 dXJlLg0KPg0KPiAgICAgICAgIFRoZXkgbmVlZCB0byBkaXNjb3ZlciBob3cgdGhlIG5ldyBwcm9k dWN0IHN1cHBvcnRzIA0KPiBkaXN0cmlidXRpbmcgU0NBUA0KPg0KPiAgICAgICAgIGNvbnRlbnQg dG8gaXQncyB2YXJpb3VzIGNvbXBvbmVudHMuIElmIHRoZXkgaGF2ZSBvbmUgcHJvZHVjdA0KPiAg ICAgICAgIHRoZW4gdGhleQ0KPg0KPiAgICAgICAgIGRvIHRoaXMgb25lIGFuZCB0aGV5IGFyZSBk b25lLiBJZiB0aGV5IGhhdmUgbXVsdGlwbGUgcHJvZHVjdHMgDQo+IHRoZXkNCj4NCj4gICAgICAg ICB3aWxsIGhhdmUgdG8gZmlndXJlIG91dCBob3cgdG8gbWluaW1pemUgdGhlIGltcGFjdCBieSAN Cj4gaW5jb3Jwb3JhdGluZw0KPg0KPiAgICAgICAgIHRoZSB1cGRhdGUgcHJvY2VzcyBmb3IgdGhl IG5ldyBwcm9kdWN0IGludG8gdGhlIGV4aXN0aW5nIFNDQVANCj4gICAgICAgICBzZWN1cml0eQ0K Pg0KPiAgICAgICAgIGNvbnRlbnQgcHJvY2Vzc2VzLiBOb3cgd2hlbiB0aGUgaW5ldml0YWJsZSBo YXBwZW5zIGFuZCB0aGUgc2l0ZQ0KPiAgICAgICAgIHN0YWZmDQo+DQo+ICAgICAgICAgbmVlZHMg dG8gbWFrZSBhIGNoYW5nZSB0byB0aGVpciBzZWN1cml0eSBwb2xpY3ksIHRoZXkgaGF2ZSB0bw0K PiAgICAgICAgIG1ha2UgdGhlDQo+DQo+ICAgICAgICAgbW9kaWZpY2F0aW9ucyB0byB0aGUgYmVu Y2htYXJrIG9yIGNoZWNrcyBvciBib3RoIGFuZCB0aGVuIA0KPiBkaXN0cmlidXRlDQo+DQo+ICAg ICAgICAgdGhvc2UgdXBkYXRlcyBhY3Jvc3MgdGhlaXIgbmV0d29yay4gRm9yIGVhY2ggU0NBUCBl bmFibGVkDQo+ICAgICAgICAgcHJvZHVjdCB0aGV5DQo+DQo+ICAgICAgICAgaGF2ZSBpbiBwbGFj ZSwgdGhleSBoYXZlIGRvdWJsZWQsIHRyaXBsZWQgb3IgbW9yZSB0aGUgd29yayANCj4gbmVlZGVk IHRvDQo+DQo+ICAgICAgICAgbWFrZSB0aG9zZSB1cGRhdGVzIGF2YWlsYWJsZS4NCj4NCj4gICAg ICAgICBUaGVyZSBpcyBhbm90aGVyIGNvbnRlbnQgcmVwb3NpdG9yeSBwcm9ibGVtIGFuZCB0aGF0 IGlzIHRoZQ0KPiAgICAgICAgIEZlZGVyYXRlZA0KPg0KPiAgICAgICAgIENvbnRlbnQgRGlzdHJp YnV0aW9uLiBJZiB5b3UgdGhpbmsgZ2xvYmFsIEROUyB5b3UgaGF2ZSBhIGdlbmVyYWwNCj4gICAg ICAgICBmcmFtZQ0KPg0KPiAgICAgICAgIG9mIHJlZmVyZW5jZS4gVGhlIGd1aWRhbmNlIGF1dGhv cnMgbmVlZCB0byBiZSBhYmxlIHRvIHB1Ymxpc2gNCj4gICAgICAgICBjb250ZW50DQo+DQo+ICAg ICAgICAgaW4gYW4gYXV0aG9yaXRhdGl2ZSBtYW5uZXIgc28gdGhlaXIgY29udGVudCBpcyB1cGRh dGVkIGluIGENCj4gICAgICAgICB0aW1lbHkgZmFzaGlvbi4NCj4NCj4gICAgICAgICBUaGlzIGlz IGEgbXVjaCBoYXJkZXIgcHJvYmxlbSB0byBzb2x2ZSBpZiB0aGVyZSBpcyBubyBsb2NhbA0KPg0K PiAgICAgICAgIG9yZ2FuaXphdGlvbmFsIGluZnJhc3RydWN0dXJlIHRvIHN1cHBvcnQgaXQuIDsp DQo+DQo+ICAgICAgICAgU28gaGVyZSBpcyB3aGF0IEkgYW0gdGhpbmtpbmcuIFdlIHNob3VsZCBj b25zaWRlciBhZGRyZXNzaW5nDQo+ICAgICAgICAgdGhlc2UgYXMNCj4NCj4gICAgICAgICB0d28g c2VwYXJhdGUgYnV0IGludGVncmF0ZWQgZWZmb3J0cy4gSSBiZWxpZXZlIHRoZSANCj4gT3JnYW5p emF0aW9uYWwNCj4NCj4gICAgICAgICBDb250ZW50IFJlcG9zaXRvcnkgaXMgdGhlIG1vcmUgY3Jp dGljYWwgcGllY2UgdGhhdCBpcyBhY3R1YWxseQ0KPiAgICAgICAgIGVhc2llcg0KPg0KPiAgICAg ICAgIHRvIGFkZHJlc3MuIFRoZSBGZWRlcmF0ZWQgQ29udGVudCBEaXN0cmlidXRpb24gc2hvdWxk IGJlIGENCj4gICAgICAgICBzdWJzZXF1ZW50DQo+DQo+ICAgICAgICAgZWZmb3J0IGludGVncmF0 aW5nIC8gYXVnbWVudGluZyB0aGUgT3JnYW5pemF0aW9uYWwgcmVwb3NpdG9yeQ0KPg0KPiAgICAg ICAgIHNwZWNpZmljYXRpb24uDQo+DQo+ICAgICAgICAgTWlrZSwgdG8geW91ciBwb2ludCB0aGF0 IHdlIG5lZWQgc29tZW9uZSB0byBidWlsZCBvbmUgZmlyc3QuDQo+ICAgICAgICAgVGhhdCBoYXMN Cj4NCj4gICAgICAgICBoYXBwZW5lZCBhbHJlYWR5LiBJIGhhdmUgb25lIGFzIGRvIG90aGVyIHZl bmRvcnMgYnV0IHdoYXQgd2UgDQo+IGRvbid0DQo+DQo+ICAgICAgICAgaGF2ZSBpcyB0aGUgYWNj ZXNzIHNwZWNpZmljYXRpb24uIE91cnMgYXJlIGZvY3VzZWQgb24gb3VyIA0KPiBzcGVjaWZpYw0K Pg0KPiAgICAgICAgIHByb2R1Y3QgbmVlZHMuIEFkZGl0aW9uYWxseSB0aGVyZSBpcyBhIGNvbXBh bnkgdGhhdCBoYXMgDQo+IGRldmVsb3BlZCBhDQo+DQo+ICAgICAgICAgY29tbWVyY2lhbCBTQ0FQ IGNvbnRlbnQgcmVwb3NpdG9yeSB0aGF0IHdpbGwgYmUgYW5ub3VuY2VkIA0KPiBsYXRlciB0aGlz DQo+DQo+ICAgICAgICAgbW9udGguIEkgd29uJ3Qgc3RlYWwgdGhlaXIgdGh1bmRlciBidXQgSSB3 YXMgcmVjZW50bHkgZ2l2ZW4gYSANCj4gc25lYWsNCj4NCj4gICAgICAgICBwZWVrIGF0IGl0IGFu ZCBJIG11c3QgYWRtaXQgSSB3YXMgdmVyeSBpbXByZXNzZWQuIEFnYWluLCB0byB5b3VyDQo+ICAg ICAgICAgcG9pbnQsIGl0IGhhcyBiZWVuIGRvbmUuDQo+DQo+ICAgICAgICAgV2hhdCBpcyBuZWVk ZWQgdG8gYWRkcmVzcyB0aGUgaW5pdGlhbCBvcGVyYXRpb25hbCBwcm9ibGVtIGlzIA0KPiB0bw0K Pg0KPiAgICAgICAgIGRldmVsb3AgYSBzcGVjaWZpY2F0aW9uIHRoYXQgcHJvdmlkZXMgYSBjb25z aXN0ZW50IG1lYW5zIGZvciBhbGwNCj4gICAgICAgICBTQ0FQDQo+DQo+ICAgICAgICAgcHJvZHVj dHMgdG8gcmV0cmlldmUgdGhlIGFwcHJvcHJpYXRlIGNvbnRlbnQgYXMgY29uZmlndXJlZCBhbmQN Cj4gICAgICAgICBtYW5hZ2VkDQo+DQo+ICAgICAgICAgYnV0IHRoZQ0KPg0KPiAgICAgc2l0ZS4N Cj4NCj4gICAgICAgICBUTyBUSEFUIEVORC4uDQo+DQo+ICAgICAgICAgSSBhbSByZXF1ZXN0aW5n IHBhcnRpY2lwYXRpb24gZnJvbSB0aG9zZSBpbiB0aGUgY29tbXVuaXR5IHRoYXQNCj4gICAgICAg ICBzZWUgdGhlDQo+DQo+ICAgICAgICAgbmVlZCBhbmQgd2FudCB0byBwdXQgaW4gdGhlIHdvcmsg dG8gbWFrZSB0aGlzIHNwZWNpZmljYXRpb24NCj4gICAgICAgICBoYXBwZW4uIEkNCj4NCj4gICAg ICAgICBoYXZlIHRhbGtlZCB0byBhIGNvdXBsZSBvZiB5b3UgYnV0IEkgZG8gbm90IHdhbnQgdG8g YXNzdW1lIA0KPiB5b3VyDQo+DQo+ICAgICAgICAgcGFydGljaXBhdGlvbi4gSWYgeW91IGFyZSBp bnRlcmVzdGVkIHBsZWFzZSBjb250YWN0IG1lIHNvIHdlIA0KPiBjYW4gZ2V0DQo+DQo+ICAgICAg ICAgdGhpcyBzdGFydGVkLg0KPg0KPiAgICAgICAgIFRoYW5rcyENCj4NCj4gICAgICAgICAqS2Vu dCBMYW5kZmllbGQqDQo+DQo+ICAgICAgICAgRGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJj aGl0ZWN0dXJlIGFuZCBTdGFuZGFyZHMNCj4NCj4gICAgICAgICAqTWNBZmVlIHwgQW4gSW50ZWwg Q29tcGFueSoNCj4NCj4gICAgICAgICA1MDAwIEhlYWRxdWFydGVycyBEci4NCj4NCj4gICAgICAg ICBQbGFubywgVGV4YXMgNzUwMjQNCj4NCj4gICAgICAgICBEaXJlY3Q6ICsxLjk3Mi45NjMuNzA5 Ng0KPg0KPiAgICAgICAgIE1vYmlsZTogKzEuODE3LjYzNy44MDI2DQo+DQo+ICAgICAgICAgKldl YjogKnd3dy5tY2FmZWUuY29tIDxodHRwOi8vd3d3Lm1jYWZlZS5jb20vPg0KPg0KPiAgICAgICAg ICpGcm9tOiAqPEtpbm5leT4sIE1pY2hhZWwgQSA8bS5raW5uZUByYWRpdW0ubmNzYy5taWwNCj4g ICAgICAgICA8bWFpbHRvOm0ua2lubmVAcmFkaXVtLm5jc2MubWlsPg0KPg0KPiAgICAgICAgIDxt YWlsdG86bS5raW5uZUByYWRpdW0ubmNzYy5taWw+DQo+ICAgICAgICAgPG1haWx0bzptLmtpbm5l QHJhZGl1bS5uY3NjLm1pbCUzZT4+DQo+DQo+ICAgICAgICAgKlRvOiAqRGF2aWQgV2FsdGVybWly ZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdg0KPiAgICAgICAgIDxtYWlsdG86ZGF2aWQud2Fs dGVybWlyZUBuaXN0Lmdvdj4NCj4NCj4gICAgICAgICA8bWFpbHRvOmRhdmlkLndhbHRlcm1pcmVA bmlzdC5nb3Y+DQo+ICAgICAgICAgPG1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292JTNl Pj4sIFNDQVAtREVWDQo+ICAgICAgICAgPFNDQVAtREVWQG5pc3QuZ292IDxtYWlsdG86U0NBUC1E RVZAbmlzdC5nb3Y+DQo+DQo+ICAgICAgICAgPG1haWx0bzpTQ0FQLURFVkBuaXN0Lmdvdj4gPG1h aWx0bzpTQ0FQLURFVkBuaXN0LmdvdiUzZT4+LA0KPiAgICAgICAgICJzYWNtQGlldGYub3JnIDxt YWlsdG86c2FjbUBpZXRmLm9yZz4gPG1haWx0bzpzYWNtQGlldGYub3JnPg0KPiAgICAgICAgIDxt YWlsdG86c2FjbUBpZXRmLm9yZyUzZT4iDQo+DQo+ICAgICAgICAgPHNhY21AaWV0Zi5vcmcgPG1h aWx0bzpzYWNtQGlldGYub3JnPiA8bWFpbHRvOnNhY21AaWV0Zi5vcmc+DQo+ICAgICAgICAgPG1h aWx0bzpzYWNtQGlldGYub3JnJTNlPj4NCj4NCj4gICAgICAgICAqU3ViamVjdDogKlJlOiBbc2Fj bV0gW09WQUwtREVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IA0KPiBBdXRvbWF0aW9uDQo+DQo+ICAg ICAgICAgRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1JVFJFIGluIEJlZGZvcmQsIE1B DQo+DQo+ICAgICAgICAgRGF2ZSwNCj4NCj4gICAgICAgICBJIGhhdmUgbm8gcHJvYmxlbSB3aXRo IHdlYmluYXJzLCBJIGRvIHdhbnQgdG8ga2VlcCBkZXZlbG9wZXIgDQo+IGRheXMNCj4NCj4gICAg ICAgICBhY3Rpb25hYmxlIGFuZCB1c2UgaXQgdG8gbWFrZSBkZWNpc2lvbnMsIGFuZCB2b3RlIGFu ZCANCj4gYWNjb21wbGlzaA0KPg0KPiAgICAgICAgIHRoaW5ncyBnb29kIG9yIGJhZC4gSSBkbyBu b3Qgd2FudCB0aGlzIHRvIGJlIGFuIGluZm9ybWF0aW9uYWwNCj4NCj4gICAgICAgICBicmllZmlu ZyBjb25mZXJlbmNlLg0KPg0KPiAgICAgICAgIFRoYW5rcyBmb3IgdGhlIGxpbmtzLg0KPg0KPiAg ICAgICAgIEkgc3RpbGwgdGhpbmsgdGhhdCBhbnkgc3BlY2lmaWNhdGlvbiBmb3IgYSByZXBvc2l0 b3J5IGlzIA0KPiB3aXNoZnVsDQo+DQo+ICAgICAgICAgdGhpbmtpbmcgdW50aWwgc29tZW9uZSBi dWlsZHMgb25lIGFuZCBsZWFybnMgdGhlIGxlc3NvbnMgaXQgDQo+IHdpbGwNCj4NCj4gICAgICAg ICBqdXN0IGJlIGFub3RoZXIgd2hpdGVwYXBlciBzcGVjLiBJIGJlbGlldmUgdGhlIERvRCBuZWVk cyB0bw0KPg0KPiAgICAgICAgIGluY29ycG9yYXRlIGEgbWV0YWRhdGEgcmVwb3NpdG9yeSBhcyBw YXJ0IG9mIGl0IGFuZCBvdGhlcg0KPg0KPiAgICAgICAgIGN1c3RvbWl6YXRpb25zIHRoYXQgbWF5 IG5vdCBiZSB1c2VmdWwgZm9yIGV2ZXJ5b25lLg0KPg0KPiAgICAgICAgIFdlIG5lZWQgdG8gdGFs ayBtb3JlLg0KPg0KPiAgICAgICAgIC1NaWtlDQo+DQo+ICAgICAgICAgKkZyb206KldhbHRlcm1p cmUsIERhdmlkIEEuIFttYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdl0NCj4NCj4gICAg ICAgICAqU2VudDoqIFR1ZXNkYXksIE1heSAwOCwgMjAxMiAxMDo0NCBBTQ0KPg0KPiAgICAgICAg ICpUbzoqIEtpbm5leSwgTWljaGFlbCBBOyBTQ0FQLURFVjsgc2FjbUBpZXRmLm9yZw0KPiAgICAg ICAgIDxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCj4NCj4gICAgIDxtYWlsdG86c2FjbUBpZXRmLm9y Zz4NCj4NCj4gICAgICAgICAqU3ViamVjdDoqIFJFOiBbT1ZBTC1ERVZFTE9QRVItTElTVF0gU2Vj dXJpdHkgQXV0b21hdGlvbiANCj4gRGV2ZWxvcGVyDQo+DQo+ICAgICAgICAgRGF5czogU3VtbWVy IDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwgTUENCj4NCj4gICAgICAgICBNaWtlLA0KPg0KPiAg ICAgICAgIFdoYXQgYWJvdXQgaGF2aW5nIHdlYmluYXJzIGluLXBsYWNlIG9mIHRoZSAzMCBtaW51 dGUgYnJpZWZzPw0KPg0KPiAgICAgICAgIFJlZ2FyZGluZyBjb250ZW50IG1hbmFnZW1lbnQsIHdl IGFyZSBidWlsZGluZyB0aGUgcHJvdG90eXBlIA0KPiBjb250ZW50DQo+DQo+ICAgICAgICAgcmVw b3NpdG9yeSBmb3IgdXNlIGluIGEgcHJvZHVjdGlvbiBlbnZpcm9ubWVudC4gQXMgYW4gb3BlbiAN Cj4gc291cmNlDQo+DQo+ICAgICAgICAgcHJvamVjdCwgaXQgd2lsbCBiZSBmcmVlIGZvciB1c2Ug YnkgYW55b25lIGludGVyZXN0ZWQuIE15IA0KPiB0aGlua2luZw0KPg0KPiAgICAgICAgIGlzIHRo YXQgdGhpcyBwcm9qZWN0IGNhbiBicmlkZ2UgdGhlIGdhcCB1bnRpbCBjb21tZXJjaWFsIA0KPiBz b2x1dGlvbnMNCj4NCj4gICAgICAgICBhcmUgYXZhaWxhYmxlIHRvIGF1Z21lbnQgaXQuIFRoaXMg aXMgYSBzaW1pbGFyIHBhdGggdGhhdCB3YXMNCj4NCj4gICAgICAgICBmb2xsb3dlZCB3aXRoIERO UyAoYmluZCkgYW5kIEhUVFAgKGFwYWNoZSkuIFdoZW4gaXQgaXMgcmVhZHkgDQo+IGZvcg0KPg0K PiAgICAgICAgIHVzZSwgSSBhbSBob3BpbmcgdG8gdXNlIGl0IHRvIGhvc3QgVVNHQ0IgY29udGVu dC4gWW91IHdvdWxkIGJlDQo+DQo+ICAgICAgICAgd2VsY29tZSB0byB1c2UgaXQgZm9yIHlvdXIg bmVlZHMuDQo+DQo+ICAgICAgICAgSXQgaXMgZ29vZCB0aGF0IE9DSUwgaXMgbW92aW5nIGZvcndh cmQuIFRoaXMgaXMgYW4gaW1wb3J0YW50IA0KPiBwaWVjZQ0KPg0KPiAgICAgICAgIG9mIHN1cHBv cnRpbmcgcmlzayBtYW5hZ2VtZW50IGFuZCBhc3BlY3RzIG9mIGNvbnRpbnVvdXMgbW9uaXRvcmlu Zy4NCj4NCj4gICAgICAgICBJIHdvdWxkIGFsc28gbGlrZSB0byBzZWUgc29tZSBkaXNjdXNzaW9u IG9uIE9DSUwgYXQgRGV2ZWxvcGVyIERheXMuDQo+DQo+ICAgICAgICAgV2l0aCB0aGUgcHJvcG9z YWxzIHdlIHdpbGwgbGlrZWx5IGhhdmUgYSBzZW5zZSBvZiB3aGF0IG5lZWRzIA0KPiB0byBiZQ0K Pg0KPiAgICAgICAgIGRpc2N1c3NlZCBhbmQgd2hhdCB3ZSBjYW4gYWNoaWV2ZSBjb25zZW5zdXMg b24gb3V0c2lkZSB0aGUgbWVldGluZy4NCj4NCj4gICAgICAgICBSZW1lZGlhdGlvbiBpcyBhIHRv cGljIG5lYXIgYW5kIGRlYXIgdG8gbXkgaGVhcnQuIEkgdG9vIHdvdWxkIA0KPiBsaWtlDQo+DQo+ ICAgICAgICAgdG8gc2VlIGl0IG1vdmUgZm9yd2FyZC4NCj4NCj4gICAgICAgICBXZSBqdXN0IHB1 Ymxpc2hlZCB0aGUgZHJhZnQgQVNSIHNwZWNpZmljYXRpb24gZm9yIHB1YmxpYyBjb21tZW50Lg0K Pg0KPiAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBzdXBwb3J0cyBlbnRlcnByaXNlIGFnZ3Jl Z2F0ZSByZXBvcnRpbmcgDQo+IHdoaWNoDQo+DQo+ICAgICAgICAgZ3JlYXRseSByZWR1Y2VzIHRo ZSBkYXRhIHZvbHVtZXMgbmVlZGVkIHZlcnNlcyBkZXRhaWxlZCANCj4gaG9zdC1iYXNlZA0KPg0K PiAgICAgICAgIHJlcG9ydHMuIFRoaXMgc3BlY2lmaWNhdGlvbiBoYXMgYmVlbiBkZXNpZ25lZCBh cyBhIG1vcmUgcm9idXN0DQo+DQo+ICAgICAgICAgcmVwbGFjZW1lbnQgZm9yIExBU1IuIEl0IGNh biBiZSB1c2VkIGluIGNvbnRpbnVvdXMgbW9uaXRvcmluZw0KPg0KPiAgICAgICAgIGFwcGxpY2F0 aW9ucyB0byBzdXBwb3J0IGFnZ3JlZ2F0ZSBkYXRhIHJlcG9ydGluZyBuZWVkcyAoZS5nLiANCj4g RklTTUENCj4NCj4gICAgICAgICByZXBvcnRpbmcsIEN5YmVyU2NvcGUpLg0KPg0KPiAgICAgICAg IEhlcmUgYXJlIHRoZSBsaW5rczoNCj4NCj4gICAgICAgICBodHRwOi8vY3NyYy5uaXN0Lmdvdi9w dWJsaWNhdGlvbnMvUHVic0RyYWZ0cy5odG1sDQo+DQo+ICAgICAgICAgDQo+IGh0dHA6Ly9jc3Jj Lm5pc3QuZ292L3B1YmxpY2F0aW9ucy9QdWJzTklTVElScy5odG1sI05JU1QtSVItNzg0OA0KPg0K PiAgICAgICAgIFRoZSBwcmltYXJ5IHJlYXNvbiB3ZSBoYXZlIHN1Z2dlc3RlZCB3YWl0aW5nIG9u IFhDQ0RGIGlzIG5vdCANCj4gdGhlDQo+DQo+ICAgICAgICAgaW50ZXJuYXRpb25hbGl6YXRpb24g aXNzdWUuIE1hbnkgdmVuZG9ycyBoYXZlIGNvbW1lbnRlZCB0aGF0IA0KPiB0aGV5DQo+DQo+ICAg ICAgICAgYXJlIHN0aWxsIHdvcmtpbmcgb24gaW1wbGVtZW50aW5nIHRoZSBYQ0NERiAxLjIuMSAN Cj4gc3BlY2lmaWNhdGlvbi4gV2UNCj4NCj4gICAgICAgICB3aWxsIGJlIGluIGEgYmV0dGVyIHBs YWNlIGluIGEgZmV3IG1vbnRocyBvbmNlIG1vcmUgDQo+IGRldmVsb3BtZW50DQo+DQo+ICAgICAg ICAgYXJvdW5kIFhDQ0RGIGhhcyBvY2N1cnJlZC4gQXMgd2UgY29uc2lkZXIgY2hhbmdlcyB0byB0 aGUgU0NBUCANCj4gc3RhY2sNCj4NCj4gICAgICAgICB0byBhZGRyZXNzIE9DSUwgYW5kIG90aGVy IGlzc3Vlcywgd2Ugd2lsbCBpZGVudGlmeSBhcmVhcyB0aGF0IA0KPiBuZWVkDQo+DQo+ICAgICAg ICAgaW1wcm92ZW1lbnQgaW4gWENDREYuIFRoZXNlIGFyZSBnb29kIGFuZCBuZWNlc3NhcnkgZGlz Y3Vzc2lvbnMgDQo+IHRvDQo+DQo+ICAgICAgICAgaGF2ZSBub3csIGJ1dCB3ZSBoYXZlIGEgZ29v ZCBkZWFsIG9mIHdvcmsgdG8gZG8gYmVmb3JlIHdlIGFyZSANCj4gcmVhZHkNCj4NCj4gICAgICAg ICB0byBvcGVuIHVwIFhDQ0RGLiBNeSBzdWdnZXN0aW9uIGlzIHRvIHdvcmsgb24gdGhlc2UgcmVs YXRlZCANCj4gYXJlYXMNCj4NCj4gICAgICAgICBhbmQgdGhlbiB3b3JrIHVwIGNoYW5nZSBwcm9w b3NhbHMgZm9yIFhDQ0RGIGFzIG5lZWRlZC4gQnkgdGhhdCANCj4gdGltZQ0KPg0KPiAgICAgICAg IHdlIHNob3VsZCBiZSByZWFkeSB0byB3b3JrIG9uIGEgbmV3IHJldmlzaW9uIG9mIFhDQ0RGLg0K Pg0KPiAgICAgICAgIEkgYW0gYWxzbyBsb29raW5nIGZvcndhcmQgdG8gdGhlIGRpc2N1c3Npb25z IGF0IHRoZSANCj4gY29uZmVyZW5jZS4gSXQNCj4NCj4gICAgICAgICBoYXMgYmVlbiB0b28gbG9u Zy4NCj4NCj4gICAgICAgICBTaW5jZXJlbHksDQo+DQo+ICAgICAgICAgRGF2ZQ0KPg0KPiAgICAg ICAgICpGcm9tOipLaW5uZXksIE1pY2hhZWwgQSBbbWFpbHRvOm0ua2lubmVAcmFkaXVtLm5jc2Mu bWlsXQ0KPg0KPiAgICAgICAgICpTZW50OiogVHVlc2RheSwgTWF5IDA4LCAyMDEyIDc6MDkgQU0N Cj4NCj4gICAgICAgICAqVG86KiBTQ0FQLURFVg0KPg0KPiAgICAgICAgICpDYzoqIFdhbHRlcm1p cmUsIERhdmlkIEEuDQo+DQo+ICAgICAgICAgKlN1YmplY3Q6KiBSRTogW09WQUwtREVWRUxPUEVS LUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gDQo+IERldmVsb3Blcg0KPg0KPiAgICAgICAgIERh eXM6IFN1bW1lciAyMDEyIGF0IE1JVFJFIGluIEJlZGZvcmQsIE1BDQo+DQo+ICAgICAgICAgS2Vu dCwNCj4NCj4gICAgICAgICBJdCdzIGdvb2QgdG8gcmVhZCB5b3VyIHRob3VnaHRzLCBhbmQgYSBy ZWFsaXN0aWMgYWN0aW9uYWJsZSANCj4gYXBwcm9hY2gNCj4NCj4gICAgICAgICBpcyBpbmRlZWQg bmVlZGVkLiBTaW5jZSBhbGwgdGhlIGFjdGl2aXR5IGhhc24ndCBiZWVuIG9uIHRoZSANCj4gbGlz dHMgYQ0KPg0KPiAgICAgICAgIGJyaWVmIDHFvTIgaG91ciByZWNhcCBtYXkgYmUgaW4gb3JkZXIg dG8gYnJpbmcgZXZlcnlvbmUgdXAgdG8gDQo+IHNwZWVkDQo+DQo+ICAgICAgICAgc2luY2UgdGhl cmUgaGFzIGJlZW4gYSBsb3Qgb2YgYWN0aXZpdHkgb24gQ1BFL1NXSUQsIE9DSWwsIA0KPiBNQUVD L0N5Yk9YDQo+DQo+ICAgICAgICAgQ0VFIGFuZCBvdGhlcnMuDQo+DQo+ICAgICAgICAgV2UgY291 bGQgd3JpdGUgYSBjb250ZW50IHJlcG9zaXRvcnkgc3BlY2lmaWNhdGlvbiwgYnV0IHdpdGhvdXQN Cj4NCj4gICAgICAgICBzb21lb25lIHdpbGxpbmcgdG8gc3RhbmQgb25lIHVwIGl0IHdpbGwgYmUg YXMgdmFsdWFibGUgYXMgdGhlIA0KPiBDQ1NTDQo+DQo+ICAgICAgICAgc3BlY2lmaWNhdGlvbiBp cyB0b2RheS4gSSd2ZSBiZWVuIHRyeWluZyBmb3IgdHdvIHllYXJzIHRvIGdldCANCj4gbXkNCj4N Cj4gICAgICAgICBtYW5hZ2VtZW50IHRvIGdldCBhIGNvb3JkaW5hdGVkIGVmZm9ydCB0b2dldGhl ciBmb3IgdGhlIERvRCB0byANCj4gc3RhbmQNCj4NCj4gICAgICAgICB1cCBhIHJlcG9zaXRvcnks IGl0IGlzIGEgdG91Z2ggcHJvYmxlbSBhbmQgd2lsbCByZXF1aXJlIA0KPiBmdW5kaW5nIHdpdGgN Cj4NCj4gICAgICAgICBhIHRhaWwsIEknbSBub3Qgc3VyZSBhIHNwZWNpZmljYXRpb24gd2lsbCBz b2x2ZSB0aGF0IHByb2JsZW0uDQo+DQo+ICAgICAgICAgV2UgKERvRCkgaGF2ZSBiZWVuIHB1dHRp bmcgYSBsb3Qgb2YgZWZmb3J0IGludG8gT0NJTCBvdmVyIHRoZSANCj4gbGFzdA0KPg0KPiAgICAg ICAgIHllYXIgdHJ5aW5nIHRvIG1ha2UgaXQgdXNlZnVsIGluIGFuIGVudGVycHJpc2UgZW52aXJv bm1lbnQgYW5kIA0KPiB3aWxsDQo+DQo+ICAgICAgICAgYmUgcG9zdGluZyBvdXIgaWRlYXMgdG8g dGhlIGxpc3QgYmVmb3JlIGRldmVsb3BlciBkYXlzIGl0IA0KPiBzaG91bGQNCj4NCj4gICAgICAg ICBoYXZlIGFscmVhZHkgc3RhcnRlZCwgd2UgbmVlZCB0byBnZXQgY29uc2Vuc3VzIGFuZCBhIHZv dGUgb24gDQo+IGhvdyB0aGUNCj4NCj4gICAgICAgICBjb21tdW5pdHkgd2lzaGVzIHRvIHByb2Nl ZWQuDQo+DQo+ICAgICAgICAgUmVtZWRpYXRpb24gaXMgc3RhbGxlZCBidXQgSSdtIG1ha2luZyBl dmVyeSBlZmZvcnQgdG8gZ2V0IGl0IA0KPiBraWNrDQo+DQo+ICAgICAgICAgc3RhcnRlZCBmcm9t IG91ciBwZXJzcGVjdGl2ZS4gSSBob3BlIHRvIGFzc2lzdCBpbiBnZXR0aW5nIHRoZSANCj4gZHJh ZnQNCj4NCj4gICAgICAgICBFUkkgZmluaXNoZWQgdGhpcyB5ZWFyLiBXZSBhcmUgd3JpdGluZyBz b21lIG5ldyBTVElHIGNvbnRlbnQgDQo+IGFuZA0KPg0KPiAgICAgICAgIGludGVuZCB0byB1c2Vk IHRoZSBkcmFmdCBDUkUgc3BlY2lmaWNhdGlvbiB0byBpbnNlcnQgQ1JFIGludG8gDQo+IHRoZQ0K Pg0KPiAgICAgICAgIGNvbnRlbnQgc28gd2UgKERvRCkgY2FuIGRvIHNvbWUgYXV0b21hdGljIGNv bmZpZ3VyYXRpb24gZml4ZXMsIA0KPiBwYXJ0DQo+DQo+ICAgICAgICAgb2YgYSBzZWxmIGhlYWxp bmcgbmV0d29yayBjb25jZXB0LiBJdCBpcyBqdXN0IGEgc3RhcnQgYnV0IHRoZSANCj4gYmVzdA0K Pg0KPiAgICAgICAgIHdlIGNhbiBkbyBhdCB0aGlzIHBvaW50Lg0KPg0KPiAgICAgICAgIEVudGVy cHJpc2UgcmVwb3J0aW5nIGlzIGFuIGludGVyZXN0aW5nIHN1YmplY3QsIHNpbmNlIFhNTCBhZGRz IA0KPiBzaXplDQo+DQo+ICAgICAgICAgdG8gYW5kIGNvbnRlbnQgdG8gcm9sbCB1cCByZXBvcnRp bmcsIGluIGFueSBlbnRlcnByaXNlIG9mIHNpemUgDQo+IHRoZQ0KPg0KPiAgICAgICAgIHByb2Js ZW0gZ2V0cyBncmVhdGVyLCBJIGxvb2sgZm9yd2FyZCB0byB5b3VyIHRob3VnaHRzIG9uIHRoYXQN Cj4gICAgICAgICBzdWJqZWN0Lg0KPg0KPiAgICAgICAgIEkgYW0gY29uY2VybmVkIHRoYXQgdGhl IGludGVybmF0aW9uYWxpemF0aW9uIGVmZm9ydHMgYXJlIA0KPiBkZXRyYWN0aW5nDQo+DQo+ICAg ICAgICAgZnJvbSBlZmZvcnRzIHRvIG1lZXQgdXNlIGNhc2VzLCB3ZSBoYXZlIHNvbWUgdGhpbmdz IHdlIHdvdWxkIA0KPiBsaWtlDQo+DQo+ICAgICAgICAgY2hhbmdlZCBpbiBYQ0NERiB0byBzdXBw b3J0IG91ciBPQ0lsIHVzZSBjYXNlIGFuZCBJIGhhdmUgYmVlbiANCj4gdG9sZA0KPg0KPiAgICAg ICAgIHRoYXQgSSBuZWVkIHRvIHdhaXQuIEkgZGlkbid0IHRoaW5rIHRoYXQgYSBtb3ZlIHRvDQo+ DQo+ICAgICAgICAgaW50ZXJuYXRpb25hbGl6YXRpb24gc2hvdWxkIGltcGVkZSBlZmZvcnRzIHRv IG1vdmUgZm9yd2FyZCANCj4gd2l0aCB1c2UNCj4NCj4gICAgICAgICBjYXNlcy4NCj4NCj4gICAg ICAgICBJIGxvb2sgZm9yd2FyZCB0byB0YWxraW5nIHdpdGggeW91IGF0IHRoZSBjb25mZXJlbmNl Lg0KPg0KPiAgICAgICAgIHYvcg0KPg0KPiAgICAgICAgIE1pa2UgS2lubmV5DQo+DQo+ICAgICAg ICAgUHJvamVjdCBEaXJlY3Rvcg0KPg0KPiAgICAgICAgIENvbXB1dGVyIE5ldHdvcmsgRGVmZW5z ZSBSZXNlYXJjaCBhbmQgVGVjaG5vbG9neSAoQ05EIFImVCkgDQo+IE9mZmljZQ0KPg0KPiAgICAg ICAgIDk4MDAgU2F2YWdlIFJvYWQgU3RlIDY3NjcNCj4NCj4gICAgICAgICBGdCBNZWFkZSwgTUQg MjA3NTUtNjc2Nw0KPg0KPiAgICAgICAgIFBob25lOiA0MTAtODU0LTQ0MjINCj4NCj4gICAgICAg ICBOU1RTOiA5NjgtODg4Ng0KPg0KPiAgICAgICAgIEZheCA0MTAtODU0LTQ2ODENCj4NCj4gICAg ICAgICBtYWtpbm4yQG5zYS5nb3YgPG1haWx0bzptYWtpbm4yQG5zYS5nb3Y+DQo+ICAgICAgICAg PG1haWx0bzpNLmtpbm5lQHJhZGl1bS5uY3NjLm1pbD4NCj4NCj4gICAgICAgICAqRnJvbToqc2Nh cC1kZXZAbmlzdC5nb3YgPG1haWx0bzoqc2NhcC1kZXZAbmlzdC5nb3Y+DQo+ICAgICAgICAgPG1h aWx0bzpzY2FwLWRldkBuaXN0Lmdvdj4NCj4NCj4gICAgICAgICBbbWFpbHRvOnNjYXAtZGV2QG5p c3QuZ292XSA8bWFpbHRvOlttYWlsdG86c2NhcC1kZXZAbmlzdC5nb3ZdPiANCj4gKk9uDQo+DQo+ ICAgICAgICAgQmVoYWxmIE9mICpXYWx0ZXJtaXJlLCBEYXZpZCBBLg0KPg0KPiAgICAgICAgICpT ZW50OiogTW9uZGF5LCBNYXkgMDcsIDIwMTIgNzowOSBQTQ0KPg0KPiAgICAgICAgICpUbzoqIE11 bHRpcGxlIHJlY2lwaWVudHMgb2YgbGlzdA0KPg0KPiAgICAgICAgICpTdWJqZWN0OiogUkU6IFtP VkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBBdXRvbWF0aW9uIA0KPiBEZXZlbG9wZXINCj4N Cj4gICAgICAgICBEYXlzOiBTdW1tZXIgMjAxMiBhdCBNSVRSRSBpbiBCZWRmb3JkLCBNQQ0KPg0K PiAgICAgICAgIEtlbnQsDQo+DQo+ICAgICAgICAgSSBsaWtlIHdoYXQgeW91IGFyZSBzYXlpbmcg aGVyZS4gV2UgYXJlIGFsc28gaW4gc3VwcG9ydCBvZiANCj4gdGhpcyB0eXBlDQo+DQo+ICAgICAg ICAgb2YgYXBwcm9hY2guIFdlIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUgY29tbXVuaXR5IGRpc2N1 c3Npb24gDQo+IGFyb3VuZA0KPg0KPiAgICAgICAgIHdoYXQgYXJlIHRoZSBrZXkgYXJlYXMvcHJp b3JpdGllcyB0aGF0IHRoZSBjb21tdW5pdHkgd291bGQgDQo+IGxpa2UgdG8NCj4NCj4gICAgICAg ICBzZWUgZGlzY3Vzc2VkIGF0IERldiBEYXlzLiBZb3VyIHRvcGljcyBiZWxvdyBsb29rIGxpa2Ug YSBnb29kIHN0YXJ0Lg0KPg0KPiAgICAgICAgIFRoZSBTQUNNIGxpc3QgbWlnaHQgYmUgYSBiZXR0 ZXIgdmVudWUgdGhhbiB0aGUgT1ZBTCBsaXN0IGZvciANCj4gdGhpcw0KPg0KPiAgICAgICAgIGRp c2N1c3Npb24uIEZvciBlYWNoIGFyZWEgd2Ugc2hvdWxkIGZvY3VzIHRoZSBkaXNjdXNzaW9uIA0K PiBhcm91bmQNCj4NCj4gICAgICAgICBkZXZlbG9waW5nIG9iamVjdGl2ZXMgZm9yIGVhY2ggc2Vz c2lvbi4gVGhlIHNlc3Npb25zIGNhbiBiZSANCj4gdGltZQ0KPg0KPiAgICAgICAgIGJveGVkIGJh c2VkIG9uIHdoYXQgd291bGQgYmUgYSByZWFzb25hYmxlIGFtb3VudCBvZiB0aW1lIHRvDQo+DQo+ ICAgICAgICAgYWNjb21wbGlzaCBlYWNoIG9iamVjdGl2ZS4gRm9yIGV4YW1wbGUgaWYgY29udGlu dW91cyANCj4gbW9uaXRvcmluZyBpcyBhDQo+DQo+ICAgICAgICAgcHJpb3JpdHkgYW5kIGNvbGxl Y3RpdmVseSBpdCB0YWtlcyAzIGRheXMgdG8gd29yayB0aHJvdWdoIGFsbCANCj4gdGhlDQo+DQo+ ICAgICAgICAgb2JqZWN0aXZlcywgSSBzZWUgbm8gcHJvYmxlbSB3aXRoIHRoYXQuIFdlIGNhbiBh bHNvIGtlZXAgYSBmZXcNCj4NCj4gICAgICAgICBzZXNzaW9ucyAib24gZGVjayIgaWYgYWxsIHRo ZSBvYmplY3RpdmVzIGFyZSByZWFjaGVkIGFuZCB3ZSANCj4gY29tcGxldGUNCj4NCj4gICAgICAg ICBhbGwgdGhlIHNjaGVkdWxlZCBzZXNzaW9ucyBlYXJseS4NCj4NCj4gICAgICAgICBUaG91Z2h0 cz8NCj4NCj4gICAgICAgICBTaW5jZXJlbHksDQo+DQo+ICAgICAgICAgRGF2aWQgV2FsdGVybWly ZQ0KPg0KPiAgICAgICAgIFNDQVAgQXJjaGl0ZWN0DQo+DQo+ICAgICAgICAgTmF0aW9uYWwgSW5z dGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KPg0KPiAgICAgICAgICgzMDEpIDk3 NS0zMzkwDQo+DQo+ICAgICAgICAgZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiA8bWFpbHRvOmRh dmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+DQo+ICAgICAgICAgPG1haWx0bzpkYXZpZC53YWx0ZXJt aXJlQG5pc3QuZ292Pg0KPg0KPiAgICAgICAgICpGcm9tOipzY2FwLWRldkBuaXN0LmdvdiA8bWFp bHRvOipzY2FwLWRldkBuaXN0Lmdvdj4NCj4gICAgICAgICA8bWFpbHRvOnNjYXAtZGV2QG5pc3Qu Z292Pg0KPg0KPiAgICAgICAgIFttYWlsdG86c2NhcC1kZXZAbmlzdC5nb3ZdIDxtYWlsdG86W21h aWx0bzpzY2FwLWRldkBuaXN0Lmdvdl0+IA0KPiAqT24NCj4NCj4gICAgICAgICBCZWhhbGYgT2Yg KktlbnRfTGFuZGZpZWxkQG1jYWZlZS5jb20NCj4gICAgICAgICA8bWFpbHRvOipLZW50X0xhbmRm aWVsZEBtY2FmZWUuY29tPg0KPg0KPiAgICAgPG1haWx0bzpLZW50X0xhbmRmaWVsZEBtY2FmZWUu Y29tPg0KPg0KPiAgICAgICAgICpTZW50OiogTW9uZGF5LCBNYXkgMDcsIDIwMTIgNDoyNSBQTQ0K Pg0KPiAgICAgICAgICpUbzoqIFNDQVAtREVWDQo+DQo+ICAgICAgICAgKlN1YmplY3Q6KiBSZTog W09WQUwtREVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gDQo+IERldmVsb3Blcg0K Pg0KPiAgICAgICAgIERheXM6IFN1bW1lciAyMDEyIGF0IE1JVFJFIGluIEJlZGZvcmQsIE1BDQo+ DQo+ICAgICAgICAgQWxsLA0KPg0KPiAgICAgICAgIEkgd291bGQgbGlrZSB0byBkaXNjdXNzIHRo ZSBmb3JtYXQgZm9yIHRoZSBTQ0FQIERldmVsb3BlciBEYXlzIA0KPiB0aGF0DQo+DQo+ICAgICAg ICAgc2VlbXMgdG8gYmUgbGlzdGVkIGJlbG93Lg0KPg0KPiAgICAgICAgIEkgc2VlIHRoaXMgYXBw ZWFycyB0byBmb2xsb3cgYSBwYXRoIHdlIGhhdmUgZGlzY3Vzc2VkIGluIHRoZSANCj4gcGFzdCBh cw0KPg0KPiAgICAgICAgIHRoZSB3YXkgbm90IHRvIGhvbGQgYSBEZXYgRGF5cyBldmVudC4gV2Ug aGF2ZSBiZWVuIHRyeWluZyB0byANCj4gZ2V0DQo+DQo+ICAgICAgICAgYXdheSBmcm9tICdEZWF0 aCBieSBQb3dlcnBvaW50JyBhbmQgYmFjayB0byB0aGUgdHlwZSBvZiBldmVudCANCj4gd2UNCj4N Cj4gICAgICAgICBoZWxkIHllYXJzIGFnbyB3aGVuIHdlIHdlcmUgaGlnaGx5IHByb2R1Y3RpdmUu IEluIHRoZSBwYXN0IHdlIA0KPiBoYWQgYQ0KPg0KPiAgICAgICAgIHRvcGljIHRvIGJlIGRpc2N1 c3NlZCBhbmQgYSB0aW1lIGJveCB0byB3b3JrIHdpdGhpbi4gVGhhdCANCj4gYWxsb3dlZCB1cw0K Pg0KPiAgICAgICAgIHRvIGhhdmUgdmVyeSBhY3RpdmUgYnJhaW5zdG9ybWluZyBzZXNzaW9ucyBp biBhIGhpZ2ggYmFuZHdpZHRoDQo+DQo+ICAgICAgICAgZW52aXJvbm1lbnQuDQo+DQo+ICAgICAg ICAgQXQgcGFzdCBTdW1tZXIgZXZlbnRzIHdlIGhhdmUgZ290IGludG8gYSBwYXR0ZXJuIG9mIGxv dHMgb2YNCj4NCj4gICAgICAgICBwb3dlcnBvaW50LCBsb3RzIG9mIHN0YXR1cyBvZiB0aGUgZWZm b3J0cyBhbmQgdmVyeSBsaXR0bGUgDQo+IGRpc2N1c3Npb24NCj4NCj4gICAgICAgICBhYm91dCB0 aGluZ3MgdGhhdCBuZWVkIGFjdGl2ZSBkaXNjdXNzaW9ucy4gV2UgbmVlZCB0byBrZWVwIA0KPiBt b3ZpbmcNCj4NCj4gICAgICAgICBmb3J3YXJkIGFuZCBtYWtpbmcgcHJvZ3Jlc3MgYXMgYW4gZWZm b3J0LiBXZSBjYW4gZ2V0IHN0YXR1cyANCj4gZnJvbQ0KPg0KPiAgICAgICAgIHZhcmlvdXMgcGxh Y2VzIHN1Y2ggYXMgdGhlIGxpc3RzLCBhIHByZXNlbnRhdGlvbiBiZWluZyBzZW50IA0KPiBvdXQg aW4NCj4NCj4gICAgICAgICBhZHZhbmNlLCBhIHdlYmluYXIgaWYgaXQgaXMgZmVsdCB0aGVyZSB3 aWxsIGJlIHF1ZXN0aW9ucyBhbmQgDQo+IGFuc3dlcnMNCj4NCj4gICAgICAgICBmcm9tIHRob3Nl IHRoYXQgYXJlIG5ldyB0byB0aGUgZWZmb3J0cy4gV2UgaGF2ZSBhIGxpbWl0ZWQgDQo+IGFtb3Vu dCBvZg0KPg0KPiAgICAgICAgIHRpbWUgYW5kIGFsbCB3aG8gYXJlIGF0dGVuZGluZyBhcmUgaW52 ZXN0aW5nIGEgZ3JlYXQgZGVhbCBvZiANCj4gdGltZQ0KPg0KPiAgICAgICAgIGFuZCBtb25leSB0 byBiZSB0aGVyZS4gV2Ugc2hvdWxkIG5vdCBiZSBzcGVuZGluZyBhIGdyZWF0IGRlYWwgDQo+IG9m DQo+DQo+ICAgICAgICAgdGltZSByZWVkdWNhdGluZyBldmVyeW9uZSB3aGVuIHdlIGNvdWxkIGJl IGZvY3VzZWQgb24gDQo+IGFkdmFuY2luZw0KPg0KPiAgICAgICAgIG5lZWRlZCBlZmZvcnRzLg0K Pg0KPiAgICAgICAgIFRoZSB0eXBlIG9mIGFwcHJvYWNoIHRvIGEgRGV2IERheXMgZXZlbnQgd2Fz IGRpc2N1c3NlZCBhdCB0aGUgDQo+IGxhc3QNCj4NCj4gICAgICAgICBTdW1tZXIgRGV2IERheXMu IEkgaGF2ZSBzZWVuIHRoZSBmb2xsb3dpbmcgd29yayBxdWl0ZSB3ZWxsIGluIA0KPiBvdGhlcg0K Pg0KPiAgICAgICAgIGVmZm9ydHMuDQo+DQo+ICAgICAgICAgMS4gUHJlc2VudGF0aW9ucyBhcmUg c2VudCBvdXQgdG8gdGhlIGF0dGVuZGVlcyBhbmQgdGhlIGxpc3RzIGEgDQo+IHdlZWsNCj4NCj4g ICAgICAgICBpbiBhZHZhbmNlLg0KPg0KPiAgICAgICAgIDIuIFN0YXR1cyBmb3IgYW55IGVmZm9y dCBpcyBsaW1pdGVkIHRvIDMwIG1pbnV0ZXMNCj4NCj4gICAgICAgICAzLiBGb2N1c2VkIGJyYWlu c3Rvcm1pbmcgdGltZSBzaG91bGQgYmUgZXN0YWJsaXNoZWQgZm9yIA0KPiBjZXJ0YWluDQo+DQo+ ICAgICAgICAgYXJlYXMgdGhhdCBuZWVkIHJlYWwgd29yayBieSB0aGUgY29tbXVuaXR5DQo+DQo+ ICAgICAgICAgNC4gRWZmb3J0cyB0byBiZSBkaXNjdXNzZWQgc2hvdWxkIGJlIGJhc2VkIG9uIG5l ZWRzIG9mIHRoZSANCj4gc2VjdXJpdHkNCj4NCj4gICAgICAgICBhdXRvbWF0aW9uIHNwYWNlIHRv IG1vdmUgZXhpc3RpbmcgZWZmb3J0cyB0byBjb21wbGV0aW9uLg0KPg0KPiAgICAgICAgIEZvciBl eGFtcGxlOg0KPg0KPiAgICAgICAgIENvbnRpbnVvdXMgbW9uaXRvcmluZyBpcyBhIG1ham9yIGRp cmVjdGlvbiB0aGUgZWZmb3J0cyBhcmUgDQo+IGJlY29taW5nDQo+DQo+ICAgICAgICAgaW52b2x2 ZWQgd2l0aC4gVGhlcmUgYXJlIGdvaW5nIHRvIGJlIHRoaW5ncyB3ZSBuZWVkIHRvIGRvIGFzIGEN Cj4NCj4gICAgICAgICBzZWN1cml0eSBhdXRvbWF0aW9uIGNvbW11bml0eSB0byBiZSBhYmxlIHRv IGFjY29tcGxpc2ggd2hhdCBpcw0KPg0KPiAgICAgICAgIGxpc3RlZCBpbiB0aGUgQ0FFU0FSUyBG RS4gVGhlcmUgYXJlIGludGVyZmFjZXMgdGhhdCBuZWVkIHRvIGJlDQo+DQo+ICAgICAgICAgd29y a2VkIGFuZCBlc3RhYmxpc2hlZC4gVGhhdCBpcyBvbmUgYXJlYSB0aGF0IGlzIG5vdCBsaXN0ZWQg YmVsb3cuDQo+DQo+ICAgICAgICAgQ00gd2lsbCBoYXZlIGEgbWFqb3IgaW1wYWN0IG9uIGFsbCBv ZiB1cyBpbiB0aGUgbmV4dCBjb3VwbGUgDQo+IHllYXJzDQo+DQo+ICAgICAgICAgYW5kIGl0IGlz IGJlaW5nIGlnbm9yZWQuIFdlIGNhbid0IGtlZXAgdHJ5aW5nIHRvIHNvbHZlIHdoYXQgDQo+IGhh cw0KPg0KPiAgICAgICAgIGFscmVhZHkgYmVlbiBzb2x2ZWQuIFdlIG5lZWQgdG8gYWRkcmVzcyB0 aGUgbmVlZGVkIGludGVyZmFjZQ0KPg0KPiAgICAgICAgIGRldmVsb3BtZW50IG5vdy4gVGhpcyBp cyBhbiBlZmZvcnQgdGhhdCBjb3VsZCB0YWtlIG5lYXJseSBhIA0KPiB3aG9sZQ0KPg0KPiAgICAg ICAgIGRheSBieSBpdHNlbGYuDQo+DQo+ICAgICAgICAgT3BlcmF0aW9uYWxseSB3ZSBoYXZlIGEg cmVhbCBuZWVkIHRvIGJlIGFibGUgdG8gZGVsaXZlciBTQ0FQIA0KPiBjb250ZW50DQo+DQo+ICAg ICAgICAgaW50ZXJuYWxseSB3aXRoaW4gYW4gb3JnYW5pemF0aW9uLiBUb2RheSB0aGUgU0NBUCB2 ZW5kb3JzIA0KPiBjYW5ub3QNCj4NCj4gICAgICAgICBzaGFyZSBhIHNpbmdsZSBsb2NhbCBzaXRl IHNlY3VyaXR5IHBvbGljeSAoWENDREYgKyBPVkFMICsgQ1BFIA0KPiArLikNCj4NCj4gICAgICAg ICB3aXRob3V0IHRoZSBzaXRlIHN0YWZmIGhhdmluZyB0byBnbyB0byBlYWNoIG9mIHRoZSBpbmRp dmlkdWFsDQo+DQo+ICAgICAgICAgcHJvZHVjdHMgYW5kIGZpZ3VyaW5nIG91dCBob3cgdG8gaW5q ZWN0IHRoYXQgbmV3IG9yIHVwZGF0ZWQgDQo+IHBvbGljeQ0KPg0KPiAgICAgICAgIGludG8gdGhh dCBwcm9kdWN0cyBkZWxpdmVyeSBtZWNoYW5pc21zLiBUaGF0IGlzIGxpbWl0aW5nIHNpdGVzIA0K PiBmcm9tDQo+DQo+ICAgICAgICAgd2FudGluZyB0byBidXkgbXVsdGlwbGUgZm9jdXNlZCBTQ0FQ IHByb2R1Y3RzIHNpbmNlIHRoZXkgYXJlIA0KPiBzdWNoIGENCj4NCj4gICAgICAgICBwYWluIHRv IG1hbmFnZSBmcm9tIGEgY29udGVudCBwZXJzcGVjdGl2ZS4gSXQgaXMgZWFzaWVyIHRvIGJ1eSAN Cj4gZnJvbQ0KPg0KPiAgICAgICAgIG9uZSB2ZW5kb3IgdGhhdCBoYXMgYSBzaW5nbGUgbWVhbnMg Zm9yIGRpc3RyaWJ1dGluZyBjb250ZW50IA0KPiB0aGFuIGl0DQo+DQo+ICAgICAgICAgaXMgdG8g ZGVhbCB3aXRoIHRoZSBtYW5hZ2VtZW50IGlzc3VlcyB0aGF0IGhhdmluZyBtdWx0aXBsZSANCj4g U0NBUA0KPg0KPiAgICAgICAgIHByb2R1Y3RzIHByZXNlbnRzLiBXZSBuZWVkIHRvIGhhdmUgYXQg bGVhc3QgYW4gZW50aXJlIDEvMiBhIA0KPiBkYXkgb24NCj4NCj4gICAgICAgICB0aGUgZGV2ZWxv cG1lbnQgb2YgYSBDb250ZW50IFJlcG9zaXRvcnkgc3BlY2lmaWNhdGlvbi4NCj4NCj4gICAgICAg ICBPQ0lMIGlzIGEgcG9zaXRpdmUgYW5kIGEgbmVnYXRpdmUgYXQgdGhlIHNhbWUgdGltZS4gSXQg aGFzIA0KPiByZWFsDQo+DQo+ICAgICAgICAgdmFsdWUgdGhhdCBpcyBiZWluZyB1bmRlcnV0aWxp emVkIGFuZCB1bmRlciBpbXBsZW1lbnRlZCANCj4gYmVjYXVzZSBvZg0KPg0KPiAgICAgICAgIHRo ZSBsaW1pdGF0aW9ucyBvZiBob3cgaXQgYWRkcmVzc2VzIHVzZXMgaW4gYW4gZW50ZXJwcmlzZQ0K Pg0KPiAgICAgICAgIGVudmlyb25tZW50LiBQZW9wbGUgZG9uJ3QgbmVlZCBzZWN1cml0eSBhdXRv bWF0aW9uIHRvIGRvIA0KPiB0aGluZ3MNCj4NCj4gICAgICAgICBvbi9mb3IgYSBzaW5nbGUgaG9z dC4gVGhleSBuZWVkIHNlY3VyaXR5IGF1dG9tYXRpb24gdG8gZm9jdXMgDQo+IG9uIHRoZQ0KPg0K PiAgICAgICAgIGVudGVycHJpc2UgaXNzdWVzIHRoYXQgcmVkdWNlIHRoZWlyIGNvc3RzIGFuZCBp bXByb3ZlIHRoZWlyDQo+DQo+ICAgICAgICAgZWZmaWNpZW5jaWVzLiBPQ0lMIGlzIGZhaWxpbmcg aW4gdGhlIGVudGVycHJpc2UgYW5kIHdlIGFsbA0KPg0KPiAgICAgICAgIHVuZGVyc3RhbmQgdGhh dC4gV2UgbmVlZCB0byBhZGRyZXNzIGRldmVsb3BpbmcgYSBkZWZpbml0aXZlIA0KPiBzb2x1dGlv bg0KPg0KPiAgICAgICAgIGZvciBpbmNvcnBvcmF0aW5nIE9DSUwgaW50byB0aGUgZW50ZXJwcmlz ZSBhbmQgdGhhdCBtZWFucyBpbnRvIA0KPiB0aGUNCj4NCj4gICAgICAgICBleGlzdGluZyBzcGVj aWZpY2F0aW9ucy4gU2NoZWR1bGluZyBhbmQgdHJhY2tpbmcgYXJlIGtleSB0byANCj4gaXQncw0K Pg0KPiAgICAgICAgIHN1Y2Nlc3MuIFdlIG5lZWQgdG8gbWFrZSB0aGF0IGhhcHBlbi4gVGhpcyB0 b28gbmVlZHMgYSBmb2N1c2VkDQo+DQo+ICAgICAgICAgYnJhaW5zdG9ybWluZyB0aW1lIGJveCB0 byBkaXNjdXNzIG9wdGlvbnMuDQo+DQo+ICAgICAgICAgSSBhbSByZWFsbHkgZGlzYXBwb2ludGVk IHRoYXQgUmVtZWRpYXRpb24gaXMgbm90IG9uIHRoZSBsaXN0IGJlbG93Lg0KPg0KPiAgICAgICAg IFllcywgbGFzdCBTdW1tZXIgRGV2IERheXMsIHRoZSB0aW1lIHNwZW50IG9uIFJlbWVkaWF0aW9u IHdhcyANCj4gd2FzdGVkDQo+DQo+ICAgICAgICAgdGltZSBidXQgdGhhdCBkb2VzIG5vdCBtZWFu IHdlIHNob3VsZCBpZ25vcmUgaXQgYW5kIG5vdCB0cnkgdG8gDQo+IG1ha2UNCj4NCj4gICAgICAg ICBzb21lIHJlYWwgcHJvZ3Jlc3MuIEFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCB3ZSBuZWVkIHRv IHJlYm9vdCANCj4gdGhlDQo+DQo+ICAgICAgICAgcmVtZWRpYXRpb24gZWZmb3J0LiBXZSBjYW5u b3Qga2VlcCBiZWluZyB0aGUgc2V0IG9mIA0KPiBzcGVjaWZpY2F0aW9ucyAvDQo+DQo+ICAgICAg ICAgdG9vbHMgdGhhdCBhY3QgYXMgdGhlIGxpdHRsZSBib3kgY3J5aW5nICJXb2xmIiBpbiB0aGUg bmlnaHQuIA0KPiBXZSBuZWVkDQo+DQo+ICAgICAgICAgdG8gYmUgYWJsZSB0byBmaW5kIGFuZCBm aXggaXNzdWVzIGlmIHdlIGFyZSBnb2luZyB0byByZWFsbHkgDQo+IG1ha2UgYQ0KPg0KPiAgICAg ICAgIGRpZmZlcmVuY2UgaW4gb3JnYW5pemF0aW9uYWwgc2VjdXJpdHkgcG9zdHVyZXMuIEJ1dCB0 b2RheSB3ZSANCj4gdGhpbmsNCj4NCj4gICAgICAgICBpdCBpcyB0b28gaGFyZCBzbyB3ZSBkb24n dCB0cnkgPyBJIHRoaW5rIHdlIG5lZWQgYSBjb3VwbGUgDQo+IGhvdXJzIHRvDQo+DQo+ICAgICAg ICAgZGlzY3VzcyB0aGUgcmVib290IG9mIHRoZSBlZmZvcnQgZXZlbiBpZiB0aGF0IG1lYW5zIG1p bmltaXppbmcgDQo+IHdvcmsNCj4NCj4gICAgICAgICBhbHJlYWR5IGRvbmUuDQo+DQo+ICAgICAg ICAgQSBmb2N1c2VkIGRpc2N1c3Npb24gb24gZW50ZXJwcmlzZSByZXBvcnRpbmcgaXMgYWxzbyAN Cj4gY3JpdGljYWxseQ0KPg0KPiAgICAgICAgIG5lZWRlZC4gRm9yIHRoZSB2ZW5kb3JzIGhlcmUs IHdlIGhhdmUgYWxsIGdvbmUgdGhyb3VnaCB0aGUNCj4NCj4gICAgICAgICBDeWJlcnNjb3BlIGdv YXQgcm9wZSwgZGVsaXZlcmluZyBsaW1pdGVkIGNhcGFiaWxpdGllcyB0byANCj4gc3BlY2lmaWMN Cj4NCj4gICAgICAgICBkYXRhIGNhbGwgcmVxdWlyZW1lbnRzIG9mIHRoZSBGZWRlcmFsIEFnZW5j aWVzLiBUaGUgaW5pdGlhbCANCj4gZWZmb3J0DQo+DQo+ICAgICAgICAgd2FzIGEgbWVzcywgZGlk IGxpdHRsZSBtb3JlIHRoYW4gcHJvdmUgaXQgd2FzIHBvc3NpYmxlIGFuZCANCj4gY2F1c2UgdGhl DQo+DQo+ICAgICAgICAgdmVuZG9yIGNvbW11bml0eSBhIGdyZWF0IGRlYWwgb2YgdGhyYXNoaW5n IHRvIHB1dCBhIGtsdWRnZXkNCj4NCj4gICAgICAgICAnc29sdXRpb24nIGluIHBsYWNlLiBSZWFs aXR5IGlzIGFsbCBvdXIgY3VzdG9tZXJzIG5lZWQgcm9sbCB1cA0KPg0KPiAgICAgICAgIHJlcG9y dGluZyBhbmQgYW4gaW5mcmFzdHJ1Y3R1cmUgdGhhdCBzdXBwb3J0cyBpdC4gQSBkYXRhIGNhbGwg DQo+IHNob3VsZA0KPg0KPiAgICAgICAgIG5vdCBiZSBzcGVjaWFsIHRvIGFueW9uZSBvdGhlciB0 aGFuIHRoZSBhZ2VuY2llcyByZXNwb25kaW5nLiANCj4gVGhlDQo+DQo+ICAgICAgICAgdG9vbHMg c2hvdWxkIGJlIGFibGUgdG8gc2VsZWN0IHRoZSB0eXBlcyBvZiBkYXRhIG5lZWRlZCBhbmQgDQo+ IGRlbGl2ZXINCj4NCj4gICAgICAgICB0aGF0IG9uIGEgc2NoZWR1bGVkIGJhc2lzIGF1dG9tYXRp Y2FsbHkuIEVudGVycHJpc2UgUmVwb3J0aW5nDQo+DQo+ICAgICAgICAgcGVydGFpbnMgdG8gY29t bWVyY2lhbCBhcyB3ZWxsIGFzIEZlZGVyYWwgY3VzdG9tZXJzLiBXZSBuZWVkIA0KPiB0bw0KPg0K PiAgICAgICAgIGZvY3VzIHNvbWUgdGltZSBvbiB3aGF0IHRoYXQgd291bGQgbG9vayBsaWtlIHVz aW5nIHRoZSBBUkYgYW5kIA0KPiBBU1INCj4NCj4gICAgICAgICBhcyB0aGUgZm91bmRhdGlvbmFs IHBpZWNlcy4gQnV0IHRoZXJlIGFyZSBtaXNzaW5nIHBpZWNlcy4uIFdlIA0KPiBuZWVkDQo+DQo+ ICAgICAgICAgdGhpcyBkaXNjdXNzZWQuDQo+DQo+ICAgICAgICAgSSB3b3VsZCBob3BlIHdlIGNh biBtYWtlIHRoaXMgc3VtbWVyJ3MgU0NBUCBEZXYgRGF5cyB1c2VmdWwgaW4NCj4NCj4gICAgICAg ICBhZHZhbmNpbmcgdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gZWZmb3J0cyBieSBhZGRyZXNzaW5n IHNvbWUgDQo+IG9mIHRoZQ0KPg0KPiAgICAgICAgIG1vcmUgY3JpdGljYWwgaXNzdWVzIG91ciBj dXN0b21lcnMgYXJlIGZhY2luZyBub3cgb3Igd2lsbCBiZSANCj4gZmFjaW5nDQo+DQo+ICAgICAg ICAgaW4gdGhlIHZlcnkgc2hvcnQgdGVybS4gU3RhdHVzIHByZXNlbnRhdGlvbnMgYXJlIG5vdCAN Cj4gaW50ZXJlc3RpbmcgdG8NCj4NCj4gICAgICAgICB0aG9zZSBhY3RpdmUgaW4gdGhlIGVmZm9y dHMuIExldCdzIHRyeSB0byBkbyB0aG9zZSBiZWZvcmUgd2UgDQo+IGdldCB0bw0KPg0KPiAgICAg ICAgIEJlZGZvcmQgc28gd2UgY2FuIHJlYWwgbWFrZSBzb21lIHByb2dyZXNzIHdoaWxlIHdlIGFy ZSBhbGwgaW4gDQo+IHRoZQ0KPg0KPiAgICAgICAgIHNhbWUgcm9vbS4gVGhpcyBpcyBhbHdheXMg YSBiaWcgZXZlbnQgZm9yIHRoZSAnY29uc2Vuc3VzIG9mIA0KPiB0aGUNCj4NCj4gICAgICAgICB3 aWxsaW5nJyB0aGF0IGFzc2VtYmxlIGFuZCBkcml2ZW4gdG8gc2VlIHNlY3VyaXR5IGF1dG9tYXRp b24gDQo+IG1ha2UgYQ0KPg0KPiAgICAgICAgIGRpZmZlcmVuY2UuIExldCdzIHNlZSBpZiB3ZSBj YW4gaGF2ZSBhbiBldmVudCB0aGF0LCB3aGVuIHdlIA0KPiBhbGwgd2Fsaw0KPg0KPiAgICAgICAg IG91dCB0aGUgbGFzdCBkYXksIHdlIGFsbCBmZWVsIHRoYXQgZXZlcnkgbWludXRlIHdhcyB3ZWxs IHNwZW50IA0KPiBhbmQNCj4NCj4gICAgICAgICBtb3ZlcyB1cyBmb3J3YXJkLg0KPg0KPiAgICAg ICAgIFRoYW5rcy4NCj4NCj4gICAgICAgICAqS2VudCBMYW5kZmllbGQqDQo+DQo+ICAgICAgICAg RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJlIGFuZCBTdGFuZGFyZHMNCj4N Cj4gICAgICAgICAqTWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueSoNCj4NCj4gICAgICAgICA1MDAw IEhlYWRxdWFydGVycyBEci4NCj4NCj4gICAgICAgICBQbGFubywgVGV4YXMgNzUwMjQNCj4NCj4g ICAgICAgICBEaXJlY3Q6ICsxLjk3Mi45NjMuNzA5Ng0KPg0KPiAgICAgICAgIE1vYmlsZTogKzEu ODE3LjYzNy44MDI2DQo+DQo+ICAgICAgICAgKldlYjogKnd3dy5tY2FmZWUuY29tIDxodHRwOi8v d3d3Lm1jYWZlZS5jb20vPg0KPg0KPiAgICAgICAgICpGcm9tOiAqPEJvY3plbm93c2tpPiwgU3Rl dmUgPHNib2N6ZW5vQE1JVFJFLk9SRw0KPiAgICAgICAgIDxtYWlsdG86c2JvY3plbm9ATUlUUkUu T1JHPg0KPg0KPiAgICAgICAgIDxtYWlsdG86c2JvY3plbm9ATUlUUkUuT1JHPiA8bWFpbHRvOnNi b2N6ZW5vQE1JVFJFLk9SRyUzZT4+DQo+DQo+ICAgICAgICAgKlJlcGx5LVRvOiAqIk9WQUwgRGV2 ZWxvcGVyIExpc3QgKENsb3NlZCBQdWJsaWMgRGlzY3Vzc2lvbikiDQo+DQo+ICAgICAgICAgPE9W QUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHDQo+ICAgICAgICAgPG1haWx0bzpPVkFM LURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRz4NCj4NCj4gICAgICAgICA8bWFpbHRvOk9W QUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPg0KPiAgICAgICAgIDxtYWlsdG86T1ZB TC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkclM2U+Pg0KPg0KPiAgICAgICAgICpUbzog KiJPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRw0KPiAgICAgICAgIDxtYWlsdG86 T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc+DQo+DQo+ICAgICAgICAgPG1haWx0 bzpPVkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRz4NCj4gICAgICAgICA8bWFpbHRv Ok9WQUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHJTNlPiINCj4NCj4gICAgICAgICA8 T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkcNCj4gICAgICAgICA8bWFpbHRvOk9W QUwtREVWRUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPg0KPg0KPiAgICAgICAgIDxtYWlsdG86 T1ZBTC1ERVZFTE9QRVItTElTVEBMSVNUUy5NSVRSRS5PUkc+DQo+ICAgICAgICAgPG1haWx0bzpP VkFMLURFVkVMT1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRyUzZT4+DQo+DQo+ICAgICAgICAgKlN1 YmplY3Q6ICpSZTogW09WQUwtREVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gDQo+ IERldmVsb3Blcg0KPg0KPiAgICAgICAgIERheXM6IFN1bW1lciAyMDEyIGF0IE1JVFJFIGluIEJl ZGZvcmQsIE1BDQo+DQo+ICAgICAgICAgRnJhbms7DQo+DQo+ICAgICAgICAgV2UgaG9wZSB0byBo YXZlIHRoZSByZWdpc3RyYXRpb24gc2l0ZSB1cCBuZXh0IHdlZWsuIFRoZSBldmVudA0KPg0KPiAg ICAgICAgIHdpbGwgYmUgZHVyaW5nIHRoZSB3ZWVrIG9mIEp1bHkgOSAtIHN0YXJ0aW5nIE1vbmRh eSBhdCAxMDowMCANCj4gQU0NCj4NCj4gICAgICAgICBhbmQgZW5kaW5nIG9uIEZyaWRheSBhdCAx MjowMC4NCj4NCj4gICAgICAgICBNZWFud2hpbGUsIHdlIGFyZSB3b3JraW5nIG9uIHRoZSBhZ2Vu ZGEgYW5kIGFyZSBjdXJyZW50bHkNCj4NCj4gICAgICAgICBjb25zaWRlcmluZyB0aGlzIGxpc3Qg b2YgdG9waWNzOg0KPg0KPiAgICAgICAgIENDRQ0KPg0KPiAgICAgICAgIENQRS9TV0lEDQo+DQo+ ICAgICAgICAgQ0VFDQo+DQo+ICAgICAgICAgWENDREYNCj4NCj4gICAgICAgICBPVkFMDQo+DQo+ ICAgICAgICAgQVNSDQo+DQo+ICAgICAgICAgRW50ZXJwcmlzZSBPQ0lMDQo+DQo+ICAgICAgICAg Q3liT1gvTUFFQw0KPg0KPiAgICAgICAgIEZlZGVyYXRlZCBDb250ZW50IFJlcG9zaXRvcnkgU3Bl Yw0KPg0KPiAgICAgICAgIEVuZHBvaW50IFJlcG9ydGluZyBmb3IgQ29udGludW91cyBNb25pdG9y aW5nIGFuZCBDb21wbGlhbmNlDQo+DQo+ICAgICAgICAgKEVSQ0MpDQo+DQo+ICAgICAgICAgTUlM RQ0KPg0KPiAgICAgICAgIFRBWElJDQo+DQo+ICAgICAgICAgSUYtTSBmb3IgU0NBUA0KPg0KPiAg ICAgICAgIElGLU1BUA0KPg0KPiAgICAgICAgIFNDQVAgUmVsZWFzZXMNCj4NCj4gICAgICAgICBT Q0FQIGFuZCBJRVRGDQo+DQo+ICAgICAgICAgTkVUQ09ORiBhbmQgU0NBUA0KPg0KPiAgICAgICAg IFN0ZXZlDQo+DQo+ICAgICAgICAgKkZyb206KkZyYW5rIExpbmRzYXkgQWNrZXIgW21haWx0bzph ZnJhbmtATk9WQS5FRFVdDQo+DQo+ICAgICAgICAgKlNlbnQ6KiBUdWVzZGF5LCBNYXkgMDEsIDIw MTIgOTozMiBBTQ0KPg0KPiAgICAgICAgICpUbzoqIG92YWwtZGV2ZWxvcGVyLWxpc3QgT1ZBTCBE ZXZlbG9wZXIgTGlzdC9DbG9zZWQgUHVibGljDQo+DQo+ICAgICAgICAgRGlzY3Vzc2lvbg0KPg0K PiAgICAgICAgICpTdWJqZWN0OiogUmU6IFtPVkFMLURFVkVMT1BFUi1MSVNUXSBTZWN1cml0eSBB dXRvbWF0aW9uDQo+DQo+ICAgICAgICAgRGV2ZWxvcGVyIERheXM6IFN1bW1lciAyMDEyIGF0IE1J VFJFIGluIEJlZGZvcmQsIE1BDQo+DQo+ICAgICAgICAgU3RldmUuLi4uDQo+DQo+ICAgICAgICAg SGFzIHRoZXJlIGJlZW4gYW55IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoaXMg ZXZlbnQ/DQo+DQo+ICAgICAgICAgVGhhbmtzLA0KPg0KPiAgICAgICAgIEZyYW5rIEFja2VyDQo+ DQo+ICAgICANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPg0KPiAgICAgICAgICpGcm9tOipCb2N6 ZW5vd3NraSwgU3RldmUgW3Nib2N6ZW5vQE1JVFJFLk9SRw0KPiAgICAgICAgIDxtYWlsdG86c2Jv Y3plbm9ATUlUUkUuT1JHPg0KPg0KPiAgICAgICAgIDxtYWlsdG86c2JvY3plbm9ATUlUUkUuT1JH PiA8bWFpbHRvOnNib2N6ZW5vQE1JVFJFLk9SRyUzZT5dDQo+DQo+ICAgICAgICAgKlNlbnQ6KiBU dWVzZGF5LCBNYXJjaCAyMCwgMjAxMiAxNjozOA0KPg0KPiAgICAgICAgICpUbzoqIE9WQUwtREVW RUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHDQo+ICAgICAgICAgPG1haWx0bzpPVkFMLURFVkVM T1BFUi1MSVNUQExJU1RTLk1JVFJFLk9SRz4NCj4NCj4gICAgICAgICA8bWFpbHRvOk9WQUwtREVW RUxPUEVSLUxJU1RATElTVFMuTUlUUkUuT1JHPg0KPg0KPiAgICAgICAgICpTdWJqZWN0OiogW09W QUwtREVWRUxPUEVSLUxJU1RdIFNlY3VyaXR5IEF1dG9tYXRpb24gRGV2ZWxvcGVyDQo+DQo+ICAg ICAgICAgRGF5czogU3VtbWVyIDIwMTIgYXQgTUlUUkUgaW4gQmVkZm9yZCwgTUENCj4NCj4gICAg ICAgICBTYXZlIHRoZSBEYXRlOiB3ZWVrIG9mIEp1bHkgOSwgMjAxMg0KPg0KPiAgICAgICAgIFRo aXMgeWVhcidzIE1JVFJFLWhvc3RlZCBTZWN1cml0eSBBdXRvbWF0aW9uIERldmVsb3BlciBEYXlz DQo+DQo+ICAgICAgICAgZXZlbnQgd2lsbCBiZSBoZWxkIGR1cmluZyB0aGUgd2VlayBvZiBKdWx5 IDksIDIwMTIgYXQgTUlUUkUncw0KPg0KPiAgICAgICAgIGZhY2lsaXR5IGluIEJlZGZvcmQsIE1B Lg0KPg0KPiAgICAgICAgIERldGFpbHMgdG8gZm9sbG93Lg0KPg0KPiAgICAgICAgIFJlZ2FyZHMs DQo+DQo+ICAgICAgICAgU3RldmUNCj4NCj4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+ICAgICAgICAgL1N0ZXBoZW4gUC4gQm9jemVu b3dza2kvDQo+DQo+ICAgICAgICAgVGhlIE1JVFJFQ29ycG9yYXRpb24NCj4NCj4gICAgICAgICBP ZmZpY2U6ICg3ODEpIDI3MS03NjgyDQo+DQo+ICAgICAgICAgQ2VsbDogKDk3OCkgMzAyLTM4NDkN Cj4NCj4gICAgICAgICBzYm9jemVub0BtaXRyZS5vcmcgPG1haWx0bzpzYm9jemVub0BtaXRyZS5v cmc+DQo+ICAgICAgICAgPG1haWx0bzpzYm9jemVub0BtaXRyZS5vcmc+DQo+DQo+ICAgICAgICAg VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwgbWVzc2FnZSB0bw0KPg0KPiAgICAgICAgIExJ U1RTRVJWQExJU1RTLk1JVFJFLk9SRyA8bWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRz4N Cj4gICAgICAgICA8bWFpbHRvOkxJU1RTRVJWQExJU1RTLk1JVFJFLk9SRz4gd2l0aA0KPg0KPiAg ICAgICAgIFNJR05PRkYgT1ZBTC1ERVZFTE9QRVItTElTVCBpbiB0aGUgQk9EWSBvZiB0aGUgbWVz c2FnZS4gSWYgeW91DQo+DQo+ICAgICAgICAgaGF2ZSBkaWZmaWN1bHRpZXMsIHdyaXRlIHRvDQo+ DQo+ICAgICAgICAgT1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJFLk9SRw0K PiAgICAgICAgIDxtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1ZXN0QExJU1RTLk1JVFJF Lk9SRz4NCj4NCj4gICAgICAgICA8bWFpbHRvOk9WQUwtREVWRUxPUEVSLUxJU1QtcmVxdWVzdEBM SVNUUy5NSVRSRS5PUkc+Lg0KPg0KPiAgICAgICAgIFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFuIGVt YWlsIG1lc3NhZ2UgdG8NCj4NCj4gICAgICAgICBMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkcgPG1h aWx0bzpMSVNUU0VSVkBMSVNUUy5NSVRSRS5PUkc+DQo+ICAgICAgICAgPG1haWx0bzpMSVNUU0VS VkBMSVNUUy5NSVRSRS5PUkc+IHdpdGgNCj4NCj4gICAgICAgICBTSUdOT0ZGIE9WQUwtREVWRUxP UEVSLUxJU1QgaW4gdGhlIEJPRFkgb2YgdGhlIG1lc3NhZ2UuIElmIHlvdQ0KPg0KPiAgICAgICAg IGhhdmUgZGlmZmljdWx0aWVzLCB3cml0ZSB0bw0KPg0KPiAgICAgICAgIE9WQUwtREVWRUxPUEVS LUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkcNCj4gICAgICAgICA8bWFpbHRvOk9WQUwtREVW RUxPUEVSLUxJU1QtcmVxdWVzdEBMSVNUUy5NSVRSRS5PUkc+DQo+DQo+ICAgICAgICAgPG1haWx0 bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUuT1JHPi4NCj4NCj4gICAg ICAgICBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCBtZXNzYWdlIHRvDQo+DQo+ICAgICAg ICAgTElTVFNFUlZATElTVFMuTUlUUkUuT1JHIDxtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUu T1JHPg0KPiAgICAgICAgIDxtYWlsdG86TElTVFNFUlZATElTVFMuTUlUUkUuT1JHPiB3aXRoDQo+ DQo+ICAgICAgICAgU0lHTk9GRiBPVkFMLURFVkVMT1BFUi1MSVNUIGluIHRoZSBCT0RZIG9mIHRo ZSBtZXNzYWdlLiBJZiB5b3UNCj4NCj4gICAgICAgICBoYXZlIGRpZmZpY3VsdGllcywgd3JpdGUg dG8NCj4NCj4gICAgICAgICBPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMuTUlUUkUu T1JHDQo+ICAgICAgICAgPG1haWx0bzpPVkFMLURFVkVMT1BFUi1MSVNULXJlcXVlc3RATElTVFMu TUlUUkUuT1JHPg0KPg0KPiAgICAgICAgIDxtYWlsdG86T1ZBTC1ERVZFTE9QRVItTElTVC1yZXF1 ZXN0QExJU1RTLk1JVFJFLk9SRz4uDQo+DQo+ICAgICAgICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gICAgICAgICBzYWNtIG1haWxpbmcgbGlz dA0KPg0KPiAgICAgICAgIHNhY21AaWV0Zi5vcmcgPG1haWx0bzpzYWNtQGlldGYub3JnPg0KPg0K PiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KPg0K PiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4N Cj4gICAgIHNhY20gbWFpbGluZyBsaXN0DQo+DQo+ICAgICBzYWNtQGlldGYub3JnIDxtYWlsdG86 c2FjbUBpZXRmLm9yZz4NCj4NCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FjbQ0KPg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4NCj4gICAgIHNhY20gbWFpbGluZyBsaXN0DQo+DQo+ICAgICBzYWNtQGll dGYub3JnIDxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCj4NCj4gICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KPg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gICAgIHNhY20gbWFpbGluZyBsaXN0DQo+ DQo+ICAgICBzYWNtQGlldGYub3JnIDxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCj4NCj4gICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjYXAtZGV2IG1haWxpbmcgbGlz dA0Kc2NhcC1kZXZAbmlzdC5nb3YNClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFuIGVtYWlsIG1lc3Nh Z2UgdG8gc2NhcC1kZXYtdW5zdWJzY3JpYmVAbmlzdC5nb3YuDQo= From prvs=489a8a45a=halbardier_adam@bah.com Tue May 29 08:55: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 9F3EA21F8713 for ; Tue, 29 May 2012 08:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.059 X-Spam-Level: X-Spam-Status: No, score=-4.059 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwBxG4+5gX3Y for ; Tue, 29 May 2012 08:55:32 -0700 (PDT) Received: from mclniron01-ext.bah.com (mclniron01-ext.bah.com [128.229.5.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6198D21F8712 for ; Tue, 29 May 2012 08:55:31 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 10.12.10.57 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=HWDFEOfULDN/aY2QFgAJGALh24J7Irc/MZZMnXEzz/Q= c=1 sm=2 a=dfkcHyh1kukA:10 a=9Kw0LW-7Wd8A:10 a=VSl--tYzzWsA:10 a=BLceEmwcHowA:10 a=-CRmgG0JhlAA:10 a=48vgC7mUAAAA:8 a=SyYMxH9GAAAA:8 a=PYnjg3YJAAAA:8 a=sMBj6sIwAAAA:8 a=S6j4fOIdY3NpwFX1SHUA:9 a=jiObf9B0YAUA:10 a=FueNqtlB6AsA:10 a=1QQx0cDIF3AA:10 a=cjL59tRlRLsA:10 a=gELb6KLQ9YUA:10 a=W56bpO8I1H8A:10 a=XT4B79g8RrEA:10 a=hz29XmwHSwYA:10 a=HoppX_JdNxgA:10 a=AS2GB_Yci6YA:10 a=RNPrVPU4Xz8A:10 a=zlqjOcb3pwsA:10 a=fvCSaKYq87sA:10 a=7Mp4iTy_7NIA:10 a=Z8xhO9XkECYA:10 a=lZB815dzVvQA:10 a=YbOTLnh8yesA:10 a=3iK1i4ecmUoA:10 a=mymLgUzsIp4IDpvE:21 a=j-jOhBsxeDbX7E6h:21 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAETwxE8KDAo5/2dsb2JhbAA6BwO2PIIXAQEBBAECFy8FBhQLEgICAgEIBwYEAQIBAQELHQcWBQ0JARQDBggBAQQBBwsIAQsHAgSHdbhaBIp/EASCAoI7YAOScoM0hGKMYIFWCQ X-IronPort-AV: E=Sophos;i="4.75,677,1330923600"; d="scan'208";a="154788429" Received: from unknown (HELO ASHBCSHB03.resource.ds.bah.com) ([10.12.10.57]) by mclniron01-int.bah.com with ESMTP; 29 May 2012 11:55:26 -0400 Received: from ASHBDAG1M3.resource.ds.bah.com ([169.254.4.143]) by ASHBCSHB03.resource.ds.bah.com ([10.12.10.57]) with mapi id 14.01.0355.002; Tue, 29 May 2012 11:55:15 -0400 From: "Halbardier, Adam [USA]" To: SCAP-DEV , "sacm@ietf.org" Thread-Topic: [scap-dev] [sacm] Request for participants - Content RepositorySpecification Development Thread-Index: Ac0vlAFxw3bnrjTVRA6a23ojGCQzFQAArCrAAQEd+jAAN3anYAAgjpeAAi3DtKA= Date: Tue, 29 May 2012 15:55:14 +0000 Message-ID: <2578EC0197492A4384C669854F185EAB13AE7D@ASHBDAG1M3.resource.ds.bah.com> References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov><66930F41F45C954AA119D59EE69C06E90C69E6098D@MBCLUSTER.xchange.nist.gov> <015d01cd347c$921ebf10$b65c3d30$@com> <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> In-Reply-To: <0C700A7ED1FE57488BB17782F397264B05F78E91@DUMFDPEXMB01.disanet.disa-u.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.230.74] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development 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, 29 May 2012 15:55:36 -0000 I agree with this. There's lots of ways to communicate information, with va= rying trade-offs, but we're already pretty entrenched in XML in the securit= y automation space, so unless there's going to be massive shift to JSON, we= 're probably not going to benefit from having a one-off spec that uses it. As for specifying the transport protocol: while it's alluring to leave the = transport mechanism open, and allow anyone to implement anything, with any = authentication mechanism, because different organizations have different ne= eds, that won't foster interoperability of tools. We need to specify the fu= nction of a repository, the vision for federation, and concrete requirement= s on how those repositories are to communicate. At least then we have a fig= hting chance of interoperability in the future. Best, -Adam -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behal= f Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA Sent: Friday, May 18, 2012 6:42 AM To: Panos Kampanakis; Waltermire, David A.; SCAP-DEV; sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repositor= ySpecification Development If we're trying for interoperability, it seems like we'll need to specify t= he transport and security. I'd hate to end up with something where every c= onsumer must be able to consume any combination of JSON, XML, CSV over REST= or SOAP because we didn't pick a standard configuration. I like using REST if possible because the DoD in the Web Services STIG has = made SOAP-based web services difficult and expensive. I like XML because w= e already have to do XML parsing for OVAL and XCCDF, so I don't really see = the allure of having to parse JSON for the service then having to parse XML= for the content. Joseph L. Wolfkiel Engineering Group Lead DISA PEO MA/IA52 (301) 225-8820 Joseph.Wolfkiel@DISA.mil -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behal= f Of Panos Kampanakis Sent: Thursday, May 17, 2012 6:30 PM To: 'Waltermire, David A.'; SCAP-DEV; sacm@ietf.org Subject: Re: [scap-dev] [sacm] Request for participants - Content Repositor= ySpecification Development Good starting point Dave. =20 2 thoughts:=20 =20 - Integrity and Confidentiality can certainly be addressed in this spec. Bu= t XML has its own mechanisms to provide them. Thus the content itself can p= rovide Integrity and Confidentiality. I am not sure if the spec should have= Integrity and Confidentiality as required features. =20 - Also, should the data Exchange mechanism be part of this draft? For examp= le HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP, REST as were= suggested in SACM's alias before? =20 Rgs, Panos =20 =20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Wednesday, May 16, 2012 3:39 PM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development =20 I just posted a skeleton I/D on this topic. I have included an initial sec= tion that focuses on identifying the overall problem space relating to cont= ent repositories. I'd appreciate any comments. =20 Here is the draft: http://www.ietf.org/id/draft-waltermire-content-repository-00.txt =20 Sincerely, Dave =20 From: Waltermire, David A.=20 Sent: Friday, May 11, 2012 1:13 PM To: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV; sacm@ie= tf.org Subject: RE: Request for participants - Content Repository Specification De= velopment =20 Kent, =20 I have already started work on a draft specification in this area. My hope= is that this work could be used as an initial draft within SACM at the app= ropriate time. Count me in. =20 I mostly agree with what you are describing below. The only area I disagre= e with is in regards to federation. If we do not implement the specificati= on for an organizational repository in the right way, we may need to make m= ajor changes to support federation. This is not good for anyone. In my mi= nd these two concepts cannot be decoupled. We need to insure that any work= towards supporting an organizational repository provides a foundation for = supporting a federated repository network. Imagine if DNS was designed wit= h a single organization mindset first without thinking about federation. T= op Level Domains (TLDs) and subdomains would not likely exist as concepts. = An individual DNS server would likely not support caching, time-to-live an= d delegating capabilities that are necessary for federation to happen. All= of these things would need to be retrofitted. To prevent this, we need to= address the building blocks of federation in the basic design. =20 Sincerely, Dave =20 From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]=20 Sent: Friday, May 11, 2012 12:36 PM To: m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV; sacm@ietf.org Subject: Request for participants - Content Repository Specification Develo= pment =20 Mike I love it when you tee something up like that.. ;-) Thank you. ;) =20 Mike wrote:=20 I still think that any specification for a repository is wishful thinking u= ntil someone builds one and learns the lessons it will just be another whit= epaper spec. I believe the DoD needs to incorporate a metadata repository = as part of it and other customizations that may not be useful for everyone. We need to talk more. =20 If you are talking about a holistic, complete federated approach to a conte= nt repository, I some what agree. If you are talking about an organization= al repository, I totally disagree. But you knew I would. ;) =20 Here is how I see the problem. There is an immediate need for SCAP and oth= er related content to be served up inside an organization. Today we have s= ituation where the standards allow us to provide sites the capability to ha= ve a single SCAP implemented policy they call official for their environmen= t. Yes this is a rather simplistic since there are things such as targeting= specific platforms, specific operational use needs, but for now lets agree= SCAP is a massive improvement over the proprietary situations of the past.= While we have created this standard content so that sites can implement th= eir local site security once and then assure they are measuring all appropr= iately targeted devices the same way, we have failed to support the operati= onal needs of the sites. We have a situation where no two vendors distribu= te content the same way. This causes massive problems for the administrati= on staff when they need to incorporate a new SCAP enabled product into thei= r architecture. They need to discover how the new product supports distrib= uting SCAP content to it's various components. If they have one product th= en they do this one and they are done. If they have multiple products they= will have to figure out how to minimize the impact by incorporating the up= date process for the new product into the existing SCAP security content pr= ocesses. Now when the inevitable happens and the site staff needs to make a= change to their security policy, they have to make the modifications to th= e benchmark or checks or both and then distribute those updates across thei= r network. For each SCAP enabled product they have in place, they have dou= bled, tripled or more the work needed to make those updates available.=20 =20 There is another content repository problem and that is the Federated Conte= nt Distribution. If you think global DNS you have a general frame of refer= ence. The guidance authors need to be able to publish content in an author= itative manner so their content is updated in a timely fashion. This is a = much harder problem to solve if there is no local organizational infrastruc= ture to support it. ;) =20 So here is what I am thinking. We should consider addressing these as two = separate but integrated efforts. I believe the Organizational Content Repo= sitory is the more critical piece that is actually easier to address. The = Federated Content Distribution should be a subsequent effort integrating / = augmenting the Organizational repository specification.=20 =20 Mike, to your point that we need someone to build one first. That has happe= ned already. I have one as do other vendors but what we don't have is the = access specification. Ours are focused on our specific product needs. Add= itionally there is a company that has developed a commercial SCAP content r= epository that will be announced later this month. I won't steal their thun= der but I was recently given a sneak peek at it and I must admit I was very= impressed. Again, to your point, it has been done. What is needed to addr= ess the initial operational problem is to develop a specification that prov= ides a consistent means for all SCAP products to retrieve the appropriate c= ontent as configured and managed but the site. =20 =20 TO THAT END.. =20 I am requesting participation from those in the community that see the need= and want to put in the work to make this specification happen. I have tal= ked to a couple of you but I do not want to assume your participation. If = you are interested please contact me so we can get this started.=20 =20 Thanks! =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Michael A To: David Waltermire , SCAP-DEV , "sacm@ietf.org" Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA =20 Dave, I have no problem with webinars, I do want to keep developer days actionab= le and use it to make decisions, and vote and accomplish things good or bad= . I do not want this to be an informational briefing conference. Thanks for the links. =20 I still think that any specification for a repository is wishful thinking = until someone builds one and learns the lessons it will just be another whi= tepaper spec. I believe the DoD needs to incorporate a metadata repository= as part of it and other customizations that may not be useful for everyone= . We need to talk more. =20 -Mike =20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, May 08, 2012 10:44 AM To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 Regarding content management, we are building the prototype content reposi= tory for use in a production environment. As an open source project, it wi= ll be free for use by anyone interested. My thinking is that this project = can bridge the gap until commercial solutions are available to augment it. = This is a similar path that was followed with DNS (bind) and HTTP (apache)= . When it is ready for use, I am hoping to use it to host USGCB content. = You would be welcome to use it for your needs. =20 It is good that OCIL is moving forward. This is an important piece of sup= porting risk management and aspects of continuous monitoring. I would also= like to see some discussion on OCIL at Developer Days. With the proposals= we will likely have a sense of what needs to be discussed and what we can = achieve consensus on outside the meeting. =20 Remediation is a topic near and dear to my heart. I too would like to see= it move forward. =20 We just published the draft ASR specification for public comment. This sp= ecification supports enterprise aggregate reporting which greatly reduces t= he data volumes needed verses detailed host-based reports. This specificati= on has been designed as a more robust replacement for LASR. It can be used= in continuous monitoring applications to support aggregate data reporting = needs (e.g. FISMA reporting, CyberScope). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 The primary reason we have suggested waiting on XCCDF is not the internati= onalization issue. Many vendors have commented that they are still working = on implementing the XCCDF 1.2.1 specification. We will be in a better place= in a few months once more development around XCCDF has occurred. As we co= nsider changes to the SCAP stack to address OCIL and other issues, we will = identify areas that need improvement in XCCDF. These are good and necessar= y discussions to have now, but we have a good deal of work to do before we = are ready to open up XCCDF. My suggestion is to work on these related area= s and then work up change proposals for XCCDF as needed. By that time we s= hould be ready to work on a new revision of XCCDF. =20 I am also looking forward to the discussions at the conference. It has be= en too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]=20 Sent: Tuesday, May 08, 2012 7:09 AM To: SCAP-DEV Cc: Waltermire, David A. Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA =20 Kent, =20 It's good to read your thoughts, and a realistic actionable approach is in= deed needed. Since all the activity hasn't been on the lists a brief 1=AE2= hour recap may be in order to bring everyone up to speed since there has b= een a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. =20 We could write a content repository specification, but without someone wil= ling to stand one up it will be as valuable as the CCSS specification is to= day. I've been trying for two years to get my management to get a coordina= ted effort together for the DoD to stand up a repository, it is a tough pro= blem and will require funding with a tail, I'm not sure a specification wil= l solve that problem. =20 We (DoD) have been putting a lot of effort into OCIL over the last year tr= ying to make it useful in an enterprise environment and will be posting our= ideas to the list before developer days it should have already started, we= need to get consensus and a vote on how the community wishes to proceed. =20 Remediation is stalled but I'm making every effort to get it kick started = from our perspective. I hope to assist in getting the draft ERI finished th= is year. We are writing some new STIG content and intend to used the draft= CRE specification to insert CRE into the content so we (DoD) can do some a= utomatic configuration fixes, part of a self healing network concept. It is= just a start but the best we can do at this point. =20 Enterprise reporting is an interesting subject, since XML adds size to and= content to roll up reporting, in any enterprise of size the problem gets g= reater, I look forward to your thoughts on that subject. =20 I am concerned that the internationalization efforts are detracting from e= fforts to meet use cases, we have some things we would like changed in XCCD= F to support our OCIl use case and I have been told that I need to wait. I = didn't think that a move to internationalization should impede efforts to m= ove forward with use cases. =20 I look forward to talking with you at the conference. =20 v/r =20 Mike Kinney Project Director Computer Network Defense Research and Technology (CND R&T) Office 9800 Savage Road Ste 6767 Ft Meade, MD 20755-6767 Phone: 410-854-4422 NSTS: 968-8886 Fax 410-854-4681 makinn2@nsa.gov =20 =20 =20 =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Waltermire,= David A. Sent: Monday, May 07, 2012 7:09 PM To: Multiple recipients of list Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA =20 Kent, =20 I like what you are saying here. We are also in support of this type of a= pproach. We would like to see some community discussion around what are th= e key areas/priorities that the community would like to see discussed at De= v Days. Your topics below look like a good start. The SACM list might be a= better venue than the OVAL list for this discussion. For each area we sho= uld focus the discussion around developing objectives for each session. Th= e sessions can be time boxed based on what would be a reasonable amount of = time to accomplish each objective. For example if continuous monitoring is= a priority and collectively it takes 3 days to work through all the object= ives, I see no problem with that. We can also keep a few sessions "on deck= " if all the objectives are reached and we complete all the scheduled sessi= ons early. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfi= eld@mcafee.com Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA =20 All, =20 I would like to discuss the format for the SCAP Developer Days that seems = to be listed below. =20 I see this appears to follow a path we have discussed in the past as the w= ay not to hold a Dev Days event. We have been trying to get away from 'Dea= th by Powerpoint' and back to the type of event we held years ago when we w= ere highly productive. In the past we had a topic to be discussed and a ti= me box to work within. That allowed us to have very active brainstorming s= essions in a high bandwidth environment. =20 At past Summer events we have got into a pattern of lots of powerpoint, lo= ts of status of the efforts and very little discussion about things that ne= ed active discussions. We need to keep moving forward and making progress = as an effort. We can get status from various places such as the lists, a pr= esentation being sent out in advance, a webinar if it is felt there will be= questions and answers from those that are new to the efforts. We have a l= imited amount of time and all who are attending are investing a great deal = of time and money to be there. We should not be spending a great deal of = time reeducating everyone when we could be focused on advancing needed effo= rts. =20 The type of approach to a Dev Days event was discussed at the last Summer = Dev Days. I have seen the following work quite well in other efforts. 1. Presentations are sent out to the attendees and the lists a week in adv= ance. 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas that= need real work by the community 4. Efforts to be discussed should be based on needs of the security automa= tion space to move existing efforts to completion. For example: =20 Continuous monitoring is a major direction the efforts are becoming involv= ed with. There are going to be things we need to do as a security automatio= n community to be able to accomplish what is listed in the CAESARS FE. The= re are interfaces that need to be worked and established. That is one area= that is not listed below. CM will have a major impact on all of us in the= next couple years and it is being ignored. We can't keep trying to solve = what has already been solved. We need to address the needed interface deve= lopment now. This is an effort that could take nearly a whole day by itself= . =20 Operationally we have a real need to be able to deliver SCAP content inter= nally within an organization. Today the SCAP vendors cannot share a single = local site security policy (XCCDF + OVAL + CPE +.) without the site staff h= aving to go to each of the individual products and figuring out how to inje= ct that new or updated policy into that products delivery mechanisms. That= is limiting sites from wanting to buy multiple focused SCAP products since= they are such a pain to manage from a content perspective. It is easier t= o buy from one vendor that has a single means for distributing content than= it is to deal with the management issues that having multiple SCAP product= s presents. We need to have at least an entire 1/2 a day on the developmen= t of a Content Repository specification. =20 OCIL is a positive and a negative at the same time. It has real value that= is being underutilized and under implemented because of the limitations of= how it addresses uses in an enterprise environment. People don't need sec= urity automation to do things on/for a single host. They need security aut= omation to focus on the enterprise issues that reduce their costs and impro= ve their efficiencies. OCIL is failing in the enterprise and we all unders= tand that. We need to address developing a definitive solution for incorpo= rating OCIL into the enterprise and that means into the existing specificat= ions. Scheduling and tracking are key to it's success. We need to make tha= t happen. This too needs a focused brainstorming time box to discuss optio= ns. =20 I am really disappointed that Remediation is not on the list below. Yes, = last Summer Dev Days, the time spent on Remediation was wasted time but tha= t does not mean we should ignore it and not try to make some real progress.= As far as I am concerned we need to reboot the remediation effort. We ca= nnot keep being the set of specifications / tools that act as the little bo= y crying "Wolf" in the night. We need to be able to find and fix issues if= we are going to really make a difference in organizational security postur= es. But today we think it is too hard so we don't try ? I think we need a= couple hours to discuss the reboot of the effort even if that means minimi= zing work already done. =20 A focused discussion on enterprise reporting is also critically needed. F= or the vendors here, we have all gone through the Cyberscope goat rope, del= ivering limited capabilities to specific data call requirements of the Fede= ral Agencies. The initial effort was a mess, did little more than prove it= was possible and cause the vendor community a great deal of thrashing to p= ut a kludgey 'solution' in place. Reality is all our customers need roll u= p reporting and an infrastructure that supports it. A data call should not= be special to anyone other than the agencies responding. The tools should = be able to select the types of data needed and deliver that on a scheduled = basis automatically. Enterprise Reporting pertains to commercial as well= as Federal customers. We need to focus some time on what that would look = like using the ARF and ASR as the foundational pieces. But there are missi= ng pieces.. We need this discussed. =20 I would hope we can make this summer's SCAP Dev Days useful in advancing t= he security automation efforts by addressing some of the more critical issu= es our customers are facing now or will be facing in the very short term. = Status presentations are not interesting to those active in the efforts. L= et's try to do those before we get to Bedford so we can real make some prog= ress while we are all in the same room. This is always a big event for the= 'consensus of the willing' that assemble and driven to see security automa= tion make a difference. Let's see if we can have an event that, when we al= l walk out the last day, we all feel that every minute was well spent and m= oves us forward. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards =09 McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 =09 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA =20 Frank; =20 We hope to have the registration site up next week. The event will be du= ring the week of July 9 - starting Monday at 10:00 AM and ending on Friday = at 12:00. =20 Meanwhile, we are working on the agenda and are currently considering thi= s list of topics: =20 CCE CPE/SWID CEE XCCDF OVAL ASR Enterprise OCIL CybOX/MAEC Federated Content Repository Spec Endpoint Reporting for Continuous Monitoring and Compliance (ERCC) MILE TAXII IF-M for SCAP IF-MAP SCAP Releases SCAP and IETF NETCONF and SCAP =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 Sent: Tuesday, May 01, 2012 9:32 AM To: oval-developer-list OVAL Developer List/Closed Public Discussion Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Su= mmer 2012 at MITRE in Bedford, MA =20 Steve.... =09 Has there been any additional information regarding this event? =09 Thanks, Frank Acker =09 ________________________________ From: Boczenowski, Steve [sboczeno@MITRE.ORG] Sent: Tuesday, March 20, 2012 16:38 To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer= 2012 at MITRE in Bedford, MA Save the Date: week of July 9, 2012 =20 This year's MITRE-hosted Security Automation Developer Days event will be= held during the week of July 9, 2012 at MITRE's facility in Bedford, MA. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SI= GNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficult= ies, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SI= GNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficult= ies, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20 To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SI= GNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficult= ies, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.=20