From adam@stoicsecurity.com Sun Jun 2 08:57:37 2013 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 480AE21F8FF3 for ; Sun, 2 Jun 2013 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4vnm+OOlNkI for ; Sun, 2 Jun 2013 08:57:32 -0700 (PDT) Received: from m1plsmtpa01-01.prod.mesa1.secureserver.net (m1plsmtpa01-01.prod.mesa1.secureserver.net [64.202.165.173]) by ietfa.amsl.com (Postfix) with ESMTP id 695A921F8FEC for ; Sun, 2 Jun 2013 08:57:31 -0700 (PDT) Received: from [192.168.1.4] ([71.59.203.52]) by m1plsmtpa01-01.prod.mesa1.secureserver.net with id jTxV1l00918LdGv01TxVwt; Sun, 02 Jun 2013 08:57:30 -0700 From: "Adam W. Montville" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Priority: 1 Date: Sun, 2 Jun 2013 08:57:29 -0700 To: "sacm@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 15:57:37 -0000 All: I've taken the charter = (http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments = submitted in a variety of threads = (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put = the following together. =20 I would love to see a dramatic increase in SACM participation throughout = this month - especially relating to the charter, which should be our = primary focus at this point, and then limited to the first several = milestones. My concern is that SACM momentum is trailing off at a point when it = needs to be maintaining, if not increasing, from that level we saw at = IETF 86. The following is the modified charter text: Securing information and the systems that store, process, and transmit = that information is a challenging task for organizations of all sizes, = and many security practitioners spend much of their time on manual = processes. Standardized processes to collect, verify, and update = security system configurations would allow easier automation of the = processes. Automating these routine tasks would free security = practitioners to focus on high priority tasks, and should improve = operators' ability to prioritize risk based on timely information about = threats and vulnerabilities. This working group will define security = automation protocols and data format standards in support of information = security processes and practices. These standards will help security = practitioners to be more effective by automating routine tasks related = to client and server security, freeing them to focus on more advanced = tasks. The initial focus of this work is to address enterprise use cases = pertaining to the assessment of endpoint posture (using the definitions = of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing = protocols, mechanisms, information and data models. Of particular = interest to this working group are existing industry standards, = preferably IETF standards, that could support automation of asset, = change, configuration, and vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This = area of focus provides for necessary language and data format = specifications. 2. A set of standards for interacting with repositories of content = related to assessment of endpoint posture. Assessment of endpoint posture assessment entails the following general = steps: 1. Relevant endpoints are identified and classified based on the targets = of the policy/policies to be evaluated 2. For each endpoint, determine what elements of posture information to = collect based on the policy/policies to be evaluated 3. For each element of the endpoint posture data, identify the mechanism = for data collection and what content is needed, if any, to support data = collection 4. Retrieve any content needed for data collection. Configuration = checks pertaining to a particular posture element may be used to support = data collection. 5. Harvest the actual values pertaining to posture elements identified = in step 3 from the endpoint. 6. Report collected endpoint posture as identified in step 2. This will = likely be done on an individual basis for each identified endpoint, = requiring aggregation of data collected from multiple endpoints as = needed based on the identified policy. This approach to endpoint posture collection enables multiple policies = to be evaluated based on a single data collection activity. Policies = will be evaluated by comparing available endpoint posture data according = to rules expressed in the policy. Typically, these rules will compare = the actual value against an expected value or range for specific posture = elements. In some cases, the posture element may pertain to software = installation state, in which case the actual and expected values may be = "installed" or "not installed." Evaluation of multiple posture elements = may be combined using Boolean logic. Repository protocols are needed to store, update, and retrieve = configuration checks and other types of content required for posture = assessment (see step 2 above). A content repository is expected to = house specific versions of checklists (i.e. benchmarks), may be required = to satisfy different use cases (i.e. a NEA-specific use vs. a generally = applicable assessment used during continuous monitoring). In addition, = content repositories are expected to store up-to-date dictionary of = specific enumerations, such as those used for configuration element = identifiers, asset classifications, vulnerability identifiers, and so = on. This working group will achieve the following deliverables: - An Informational document on Use Cases - An Informational document on Requirements - An Informational document on SACM Architecture - A standards-track document specifying a protocol and data format for = retrieving configuration and policy information for driving data = collection and analysis - A standards-track document specifying a protocol and data format for = collecting actual endpoint posture=20 The working group will create an overview of related standards work = Internet-Draft which will document existing work in the IETF or in other = SDOs which can be used as-is or as a starting point for developing = solutions to the SACM requirements. The working group may decide to make = of this document an Informational RFC, but this is not a mandatory = deliverable. =20 The working group will work in close coordination with other WGs in the = IETF (including, but not limited to MILE and NEA) in order to create = solutions that do not overlap (for example for the repository access = protocol) and can be used or re-used to meet the goals of more than one = working group.=20 In accordance with existing IETF processes, the group will communicate = with and invite participation from other relevant standards bodies and = regulatory organizations, and if necessary reuse existing liaison = relationships or request the establishment of new liaison relationships. SACM-related efforts are largely aligned, and may overlap, with other = IETF (and non-IETF) standardization efforts. There are common = "problems" found in SACM, that may be addressed by the work done in = SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of = particular interest to SACM is understanding and respecting the = distinctions between itself and NEA and MILE. One way the NEA protocols can be used is as the transport for data = collected on the endpoint to an external service or data repository for = further analysis and action. NEA may also serve the purpose of carrying = data-collection instructions. The MILE data formats provide a format to describe incident, = threat-related incident, and indicator information. SACM data formats = provide ways to understand what endpoints are in your environment, = whether they meet policy requirements, and their current configuration = state. The data exchanged in MILE, supplementing the SACM data, creates = enhanced situational awareness, thus enabling increased understanding of = current threats and mitigations. The combined SACM and MILE data sets = become a powerful tool to automate security with descriptions of = endpoints, known vulnerabilities to those endpoints, and thier = configurations along with an understanding of layered defenses. Then, = injecting known threat information with mitigation options assists the = organization in turning detailed security decisions into = business-relevant decisions. The MILE protocols, RID and ROLIE, enable = the exchange of structured data and are designed to carry any structured = format. While RID may be used in multiple sharing models and provides = multiple communication flows (report, query, etc.) with the ability to = enable peer-to-peer object level security, ROLIE provides a RESTful = repository transport option with only the need for a browser on the = client end, removing deployment barriers. After the work items in the current charter have been submitted to and = approved by the IESG, the WG will recharter or close. =20 Goals and Milestones Sep. 2013 - Initial submission of an Internet-Draft on Use Cases=20 Oct. 2013 - Initial submission of an Internet-Draft on Requirements = taking into consideration RFC5706 and RFC3535 Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture=20= Nov. 2013 - Initial submission of an Internet-Draft on overview of = related standards work=20 Jan. 2014 - Initial submission of an Internet-Draft for a protocol and = data format for retrieving configuration and policy information for = driving data collection and analysis Jan. 2014 - Initial submission of an Internet-Draft for a protocol and = data format for collecting actual endpoint posture=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases = for consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements = for consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM = Architecture for consideration as Informational RFC=20 Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol = and data format for retrieving configuration and policy information for = driving data collection and analysis for consideration as = standards-track RFC=20 Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and = data format for collecting actual endpoint posture for consideration as = standards-track RFC From dromasca@avaya.com Mon Jun 3 05:44:40 2013 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 F00F021F96D9 for ; Mon, 3 Jun 2013 05:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVE78WMOHPRQ for ; Mon, 3 Jun 2013 05:44:34 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 50E4A21F965A for ; Mon, 3 Jun 2013 05:44:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAEyPrFGHCzI1/2dsb2JhbABPCoJoITC/A4EAFnSCIwEBAQEDAQEBDyg0BBMEAgEIDQQBAwEBCxQJBycLFAMGCAIEARIIARIHh2sBC55um3YXjWsEBoEBMwUGgnFhA5NthHqFGIp/gw+BaAkXHw X-IronPort-AV: E=Sophos;i="4.87,792,1363147200"; d="scan'208";a="14439082" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Jun 2013 08:44:28 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Jun 2013 08:39:56 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 14:44:26 +0200 From: "Romascanu, Dan (Dan)" To: "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6nvQLc+l7pAnUKQTep8PIA24Zkj72EQ Date: Mon, 3 Jun 2013 12:44:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17F243@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 12:44:40 -0000 Hi,=20 Thanks to Adam for this revision.=20 Can we have a show of hands about this version of the charter text:=20 - does it clarify in a satisfactory manner the questions asked on the list = and especially the ones asked by our AD?=20 - does it reflect the consensus of the mail list on the scope of the first = phase of the proposed WG?=20 - is it good enough to be submitted to the IESG for discussions on the form= ation of the WG? All answers welcome. Any answer different than 'yes' should be accompanied = by concrete comments on issues that still need clarification, and items we = still need to work for consensus.=20 Thanks and Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam W. Montville > Sent: Sunday, June 02, 2013 6:57 PM > To: sacm@ietf.org > Subject: [sacm] Updated Candidate Charter Text > Importance: High >=20 > All: >=20 > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf- > sacm/) and comments submitted in a variety of threads > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put > the following together. >=20 > I would love to see a dramatic increase in SACM participation throughout > this month - especially relating to the charter, which should be our > primary focus at this point, and then limited to the first several > milestones. >=20 > My concern is that SACM momentum is trailing off at a point when it > needs to be maintaining, if not increasing, from that level we saw at > IETF 86. >=20 > The following is the modified charter text: >=20 > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual > processes. Standardized processes to collect, verify, and update > security system configurations would allow easier automation of the > processes. Automating these routine tasks would free security > practitioners to focus on high priority tasks, and should improve > operators' ability to prioritize risk based on timely information about > threats and vulnerabilities. This working group will define security > automation protocols and data format standards in support of information > security processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use cases > pertaining to the asses sment of endpoint posture (using the > definitions of Endpoint and Posture from RFC 5209). >=20 > The working group will, whenever reasonable and possible, reuse existing > protocols, mechanisms, information and data models. Of particular > interest to this working group are existing industry standards, > preferably IETF standards, that could support automation of asset, > change, configuration, and vulnerability management. >=20 > The working group will define: >=20 > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format > specifications. >=20 > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. >=20 > Assessment of endpoint posture assessment entails the following general > steps: >=20 > 1. Relevant endpoints are identified and classified based on the targets > of the policy/policies to be evaluated >=20 > 2. For each endpoint, determine what elements of posture information to > collect based on the policy/policies to be evaluated >=20 > 3. For each element of the endpoint posture data, identify the mechanism > for data collection and what content is needed, if any, to support data > collection >=20 > 4. Retrieve any content needed for data collection. Configuration > checks pertaining to a particular posture element may be used to support > data collection. >=20 > 5. Harvest the actual values pertaining to posture elements identified > in step 3 from the endpoint. >=20 > 6. Report collected endpoint posture as identified in step 2. This will > likely be done on an individual basis for each identified endpoint, > requiring aggregation of data collected from multiple endpoints as > needed based on the identified policy. >=20 > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data according > to rules expressed in the policy. Typically, these rules will compare > the actual value against an expected value or range for specific posture > elements. In some cases, the posture element may pertain to software > installation state, in which case the actual and expected values may be > "installed" or "not installed." Evaluation of multiple posture elements > may be combined using Boolean logic. >=20 > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be required > to satisfy different use cases (i.e. a NEA-specific use vs. a generally > applicable assessment used during continuous monitoring). In addition, > content repositories are expected to store up-to-date dictionary of > specific enumerations, such as those used for configuration element > identifiers, asset classifications, vulnerability identifiers, and so > on. >=20 > This working group will achieve the following deliverables: >=20 > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture >=20 > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in other > SDOs which can be used as-is or as a starting point for developing > solutions to the SACM requirements. The working group may decide to make > of this document an Informational RFC, but this is not a mandatory > deliverable. >=20 > The working group will work in close coordination with other WGs in the > IETF (including, but not limited to MILE and NEA) in order to create > solutions that do not overlap (for example for the repository access > protocol) and can be used or re-used to meet the goals of more than one > working group. >=20 > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. >=20 > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common > "problems" found in SACM, that may be addressed by the work done in > SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > particular interest to SACM is understanding and respecting the > distinctions between itself and NEA and MILE. >=20 > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository for > further analysis and action. NEA may also serve the purpose of carrying > data-collection instructions. >=20 > The MILE data formats provide a format to describe incident, threat- > related incident, and indicator information. SACM data formats provide > ways to understand what endpoints are in your environment, whether they > meet policy requirements, and their current configuration state. The > data exchanged in MILE, supplementing the SACM data, creates enhanced > situational awareness, thus enabling increased understanding of current > threats and mitigations. The combined SACM and MILE data sets become a > powerful tool to automate security with descriptions of endpoints, known > vulnerabilities to those endpoints, and thier configurations along with > an understanding of layered defenses. Then, injecting known threat > information with mitigation options assists the organization in turning > detailed security decisions into business-relevant decisions. The MILE > protocols, RID and ROLIE, enable the exchange of structured data and are > designed to carry any structured format. While RID may be used in > multiple sharing models and provides multiple communication flows > (report, query, etc.) with the ability to enable peer-to-peer object > level security, ROLIE provides a RESTful repository transport option > with only the need for a browser on the client end, removing deployment > barriers. >=20 > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. >=20 > Goals and Milestones >=20 > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >=20 > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 >=20 > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture >=20 > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work >=20 > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis >=20 > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture >=20 > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC >=20 > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements > for consideration as Informational RFC >=20 > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC >=20 > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol > and data format for retrieving configuration and policy information for > driving data collection and analysis for consideration as standards- > track RFC >=20 > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and > data format for collecting actual endpoint posture for consideration as > standards-track RFC >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dromasca@avaya.com Mon Jun 3 06:00:48 2013 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 4C83421F8DBC for ; Mon, 3 Jun 2013 06:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.74 X-Spam-Level: X-Spam-Status: No, score=-102.74 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn8T0hQjtJzD for ; Mon, 3 Jun 2013 06:00:38 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1CB21F86CB for ; Mon, 3 Jun 2013 06:00:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAN2SrFGHCzI1/2dsb2JhbABPCoJoITC/A4EAFnSCIwEBAQEDAQEBDwsdNAQTBAIBCA0EAQMBAQsUCQcnCxQDBggCBAESCAELBweHawELnxibeheNZQYEBoEBMwUGgnFhA5NthHqFGIp/gw+BaAkXHw X-IronPort-AV: E=Sophos;i="4.87,792,1363147200"; d="scan'208";a="14441461" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Jun 2013 09:00:37 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Jun 2013 08:56:05 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 15:00:35 +0200 From: "Romascanu, Dan (Dan)" To: Michael Hammer , "adam@stoicsecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6nvQLc+l7pAnUKQTep8PIA24Zkj72EQgABH8gD//70qoA== Date: Mon, 3 Jun 2013 13:00:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17F2A1@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17F243@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3A03D7C03@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03D7C03@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 13:00:48 -0000 Hi Mike,=20 Thanks for your response and support.=20 Concerning the email participation - this community needs to confirm now to= the IESG that 1. It stays committed to do the SACM work, as discussed in t= he two BOF sessions 2. It acknowledges consensus on the scope as expressed = in the charter text.=20 This is the reason for doing this call for feedback now.=20 Regards, Dan > -----Original Message----- > From: Michael Hammer [mailto:michael.hammer@yaanatech.com] > Sent: Monday, June 03, 2013 3:57 PM > To: Romascanu, Dan (Dan); adam@stoicsecurity.com; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text >=20 > Dan, >=20 > I think it read very well. >=20 > As for email participation, sometimes the runners are lined up > at the start line and just waiting for the starting gun to go off. > So, lack of movement does not mean lack of interest. >=20 > Mike >=20 >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Monday, June 03, 2013 8:44 AM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > Hi, >=20 > Thanks to Adam for this revision. >=20 > Can we have a show of hands about this version of the charter text: >=20 >=20 > - does it clarify in a satisfactory manner the questions asked on the > list > and especially the ones asked by our AD? > - does it reflect the consensus of the mail list on the scope of the > first > phase of the proposed WG? > - is it good enough to be submitted to the IESG for discussions on the > formation of the WG? >=20 > All answers welcome. Any answer different than 'yes' should be > accompanied > by concrete comments on issues that still need clarification, and items > we > still need to work for consensus. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam W. Montville > > Sent: Sunday, June 02, 2013 6:57 PM > > To: sacm@ietf.org > > Subject: [sacm] Updated Candidate Charter Text > > Importance: High > > > > All: > > > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf- > > sacm/) and comments submitted in a variety of threads > > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and > > put the following together. > > > > I would love to see a dramatic increase in SACM participation > > throughout this month - especially relating to the charter, which > > should be our primary focus at this point, and then limited to the > > first several milestones. > > > > My concern is that SACM momentum is trailing off at a point when it > > needs to be maintaining, if not increasing, from that level we saw at > > IETF 86. > > > > The following is the modified charter text: > > > > Securing information and the systems that store, process, and transmit > > that information is a challenging task for organizations of all sizes, > > and many security practitioners spend much of their time on manual > > processes. Standardized processes to collect, verify, and update > > security system configurations would allow easier automation of the > > processes. Automating these routine tasks would free security > > practitioners to focus on high priority tasks, and should improve > > operators' ability to prioritize risk based on timely information > > about threats and vulnerabilities. This working group will define > > security automation protocols and data format standards in support of > > information security processes and practices. These standards will > > help security practitioners to be more effective by automating routine > > tasks related to client and server security, freeing them to focus on > > more advanced tasks. The initial focus of this work is to address > > enterprise use cases pertaining to the asses sment of endpoint > > posture (using the definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse > > existing protocols, mechanisms, information and data models. Of > > particular interest to this working group are existing industry > > standards, preferably IETF standards, that could support automation of > > asset, change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area of focus provides for necessary language and data format > > specifications. > > > > 2. A set of standards for interacting with repositories of content > > related to assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following > > general > > steps: > > > > 1. Relevant endpoints are identified and classified based on the > > targets of the policy/policies to be evaluated > > > > 2. For each endpoint, determine what elements of posture information > > to collect based on the policy/policies to be evaluated > > > > 3. For each element of the endpoint posture data, identify the > > mechanism for data collection and what content is needed, if any, to > > support data collection > > > > 4. Retrieve any content needed for data collection. Configuration > > checks pertaining to a particular posture element may be used to > > support data collection. > > > > 5. Harvest the actual values pertaining to posture elements identified > > in step 3 from the endpoint. > > > > 6. Report collected endpoint posture as identified in step 2. This > > will likely be done on an individual basis for each identified > > endpoint, requiring aggregation of data collected from multiple > > endpoints as needed based on the identified policy. > > > > This approach to endpoint posture collection enables multiple policies > > to be evaluated based on a single data collection activity. Policies > > will be evaluated by comparing available endpoint posture data > > according to rules expressed in the policy. Typically, these rules > > will compare the actual value against an expected value or range for > > specific posture elements. In some cases, the posture element may > > pertain to software installation state, in which case the actual and > > expected values may be "installed" or "not installed." Evaluation of > > multiple posture elements may be combined using Boolean logic. > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. a NEA-specific use vs. a > > generally applicable assessment used during continuous monitoring). > > In addition, content repositories are expected to store up-to-date > > dictionary of specific enumerations, such as those used for > > configuration element identifiers, asset classifications, > > vulnerability identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format for > > retrieving configuration and policy information for driving data > > collection and analysis > > - A standards-track document specifying a protocol and data format for > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > > other SDOs which can be used as-is or as a starting point for > > developing solutions to the SACM requirements. The working group may > > decide to make of this document an Informational RFC, but this is not > > a mandatory deliverable. > > > > The working group will work in close coordination with other WGs in > > the IETF (including, but not limited to MILE and NEA) in order to > > create solutions that do not overlap (for example for the repository > > access > > protocol) and can be used or re-used to meet the goals of more than > > one working group. > > > > In accordance with existing IETF processes, the group will communicate > > with and invite participation from other relevant standards bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > > > SACM-related efforts are largely aligned, and may overlap, with other > > IETF (and non-IETF) standardization efforts. There are common > > "problems" found in SACM, that may be addressed by the work done in > > SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > > particular interest to SACM is understanding and respecting the > > distinctions between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data-collection instructions. > > > > The MILE data formats provide a format to describe incident, threat- > > related incident, and indicator information. SACM data formats > > provide ways to understand what endpoints are in your environment, > > whether they meet policy requirements, and their current configuration > > state. The data exchanged in MILE, supplementing the SACM data, > > creates enhanced situational awareness, thus enabling increased > > understanding of current threats and mitigations. The combined SACM > > and MILE data sets become a powerful tool to automate security with > > descriptions of endpoints, known vulnerabilities to those endpoints, > > and thier configurations along with an understanding of layered > > defenses. Then, injecting known threat information with mitigation > > options assists the organization in turning detailed security > > decisions into business-relevant decisions. The MILE protocols, RID > > and ROLIE, enable the exchange of structured data and are designed to > > carry any structured format. While RID may be used in multiple > > sharing models and provides multiple communication flows (report, > > query, etc.) with the ability to enable peer-to-peer object level > > security, ROLIE provides a RESTful repository transport option with > > only the need for a browser on the client end, removing deployment > barriers. > > > > After the work items in the current charter have been submitted to and > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > taking into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > related standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > > data format for retrieving configuration and policy information for > > driving data collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > > data format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > Requirements for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > protocol and data format for retrieving configuration and policy > > information for driving data collection and analysis for consideration > > as standards- track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > and data format for collecting actual endpoint posture for > > consideration as standards-track RFC > > > > _______________________________________________ > > 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 shanna@juniper.net Mon Jun 3 06:04:52 2013 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 0075F21F96D9 for ; Mon, 3 Jun 2013 06:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 xo3aLIJj9yJC for ; Mon, 3 Jun 2013 06:04:45 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4325021F8DBC for ; Mon, 3 Jun 2013 06:04:45 -0700 (PDT) Received: from mail10-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Jun 2013 13:04:44 +0000 Received: from mail10-am1 (localhost [127.0.0.1]) by mail10-am1-R.bigfish.com (Postfix) with ESMTP id 3CB362203B2 for ; Mon, 3 Jun 2013 13:04:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz9371Ie6eI542I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1155h) Received-SPF: softfail (mail10-am1: transitioning domain of juniper.net does not designate 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=shanna@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail10-am1 (localhost.localdomain [127.0.0.1]) by mail10-am1 (MessageSwitch) id 1370264647715731_24833; Mon, 3 Jun 2013 13:04:07 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.249]) by mail10-am1.bigfish.com (Postfix) with ESMTP id 9CB8B1C01BB for ; Mon, 3 Jun 2013 13:04:07 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 3 Jun 2013 13:04:06 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 3 Jun 2013 06:03:46 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 3 Jun 2013 06:03:46 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.251) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 3 Jun 2013 06:06:57 -0700 Received: from mail17-db9-R.bigfish.com (10.174.16.230) by DB9EHSOBE004.bigfish.com (10.174.14.67) with Microsoft SMTP Server id 14.1.225.23; Mon, 3 Jun 2013 13:03:44 +0000 Received: from mail17-db9 (localhost [127.0.0.1]) by mail17-db9-R.bigfish.com (Postfix) with ESMTP id 67E2EC00FB for ; Mon, 3 Jun 2013 13:03:44 +0000 (UTC) Received: from mail17-db9 (localhost.localdomain [127.0.0.1]) by mail17-db9 (MessageSwitch) id 137026459978082_14272; Mon, 3 Jun 2013 13:03:19 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.244]) by mail17-db9.bigfish.com (Postfix) with ESMTP id 03EB82C0046; Mon, 3 Jun 2013 13:03:19 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Jun 2013 13:03:18 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.13]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0311.000; Mon, 3 Jun 2013 13:03:10 +0000 From: Stephen Hanna To: "Romascanu, Dan (Dan)" , "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n1sTB6NtW1w0unBSJfMGLGYpkj8NSAgAADXYA= Date: Mon, 3 Jun 2013 13:03:09 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA17F243@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17F243@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%AVAYA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%STOICSECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 13:04:52 -0000 Yes, I believe this text addresses the questions asked and is ready for submission to the IESG. I did notice what I believe are two typos: * In this sentence, I think "may be" should be "which may be": > A content repository is expected to house specific versions > of checklists (i.e. benchmarks), may be required to satisfy > different use cases (i.e. a NEA-specific use vs. a generally > applicable assessment used during continuous monitoring). * In this sentence, I think the word "an" should appear before "up-to-date": > In addition, content repositories are expected to store up-to-date > dictionary of specific enumerations, such as those used for > configuration element identifiers, asset classifications, > vulnerability identifiers, and so on. With those two fixes (or without them, even!), I think this charter is ready to go. I apologize for being quiet recently. As Mike said, things seemed to be going so smoothly here. I didn't realize that a nudge of support was needed. I am happy to confirm that I'm still committed to doing the SACM work, as agreed in the BOF sessions. And I agree with this charter and scope. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Monday, June 03, 2013 8:44 AM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > Hi, >=20 > Thanks to Adam for this revision. >=20 > Can we have a show of hands about this version of the charter text: >=20 >=20 > - does it clarify in a satisfactory manner the questions asked on the > list and especially the ones asked by our AD? > - does it reflect the consensus of the mail list on the scope of the > first phase of the proposed WG? > - is it good enough to be submitted to the IESG for discussions on the > formation of the WG? >=20 > All answers welcome. Any answer different than 'yes' should be > accompanied by concrete comments on issues that still need > clarification, and items we still need to work for consensus. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Adam W. Montville > > Sent: Sunday, June 02, 2013 6:57 PM > > To: sacm@ietf.org > > Subject: [sacm] Updated Candidate Charter Text > > Importance: High > > > > All: > > > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf- > > sacm/) and comments submitted in a variety of threads > > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and > put > > the following together. > > > > I would love to see a dramatic increase in SACM participation > throughout > > this month - especially relating to the charter, which should be our > > primary focus at this point, and then limited to the first several > > milestones. > > > > My concern is that SACM momentum is trailing off at a point when it > > needs to be maintaining, if not increasing, from that level we saw at > > IETF 86. > > > > The following is the modified charter text: > > > > Securing information and the systems that store, process, and > transmit > > that information is a challenging task for organizations of all > sizes, > > and many security practitioners spend much of their time on manual > > processes. Standardized processes to collect, verify, and update > > security system configurations would allow easier automation of the > > processes. Automating these routine tasks would free security > > practitioners to focus on high priority tasks, and should improve > > operators' ability to prioritize risk based on timely information > about > > threats and vulnerabilities. This working group will define security > > automation protocols and data format standards in support of > information > > security processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks > related > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > cases > > pertaining to the asses sment of endpoint posture (using the > > definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse > existing > > protocols, mechanisms, information and data models. Of particular > > interest to this working group are existing industry standards, > > preferably IETF standards, that could support automation of asset, > > change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area of focus provides for necessary language and data format > > specifications. > > > > 2. A set of standards for interacting with repositories of content > > related to assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following > general > > steps: > > > > 1. Relevant endpoints are identified and classified based on the > targets > > of the policy/policies to be evaluated > > > > 2. For each endpoint, determine what elements of posture information > to > > collect based on the policy/policies to be evaluated > > > > 3. For each element of the endpoint posture data, identify the > mechanism > > for data collection and what content is needed, if any, to support > data > > collection > > > > 4. Retrieve any content needed for data collection. Configuration > > checks pertaining to a particular posture element may be used to > support > > data collection. > > > > 5. Harvest the actual values pertaining to posture elements > identified > > in step 3 from the endpoint. > > > > 6. Report collected endpoint posture as identified in step 2. This > will > > likely be done on an individual basis for each identified endpoint, > > requiring aggregation of data collected from multiple endpoints as > > needed based on the identified policy. > > > > This approach to endpoint posture collection enables multiple > policies > > to be evaluated based on a single data collection activity. Policies > > will be evaluated by comparing available endpoint posture data > according > > to rules expressed in the policy. Typically, these rules will compare > > the actual value against an expected value or range for specific > posture > > elements. In some cases, the posture element may pertain to software > > installation state, in which case the actual and expected values may > be > > "installed" or "not installed." Evaluation of multiple posture > elements > > may be combined using Boolean logic. > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > required > > to satisfy different use cases (i.e. a NEA-specific use vs. a > generally > > applicable assessment used during continuous monitoring). In > addition, > > content repositories are expected to store up-to-date dictionary of > > specific enumerations, such as those used for configuration element > > identifiers, asset classifications, vulnerability identifiers, and so > > on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format > for > > retrieving configuration and policy information for driving data > > collection and analysis > > - A standards-track document specifying a protocol and data format > for > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > other > > SDOs which can be used as-is or as a starting point for developing > > solutions to the SACM requirements. The working group may decide to > make > > of this document an Informational RFC, but this is not a mandatory > > deliverable. > > > > The working group will work in close coordination with other WGs in > the > > IETF (including, but not limited to MILE and NEA) in order to create > > solutions that do not overlap (for example for the repository access > > protocol) and can be used or re-used to meet the goals of more than > one > > working group. > > > > In accordance with existing IETF processes, the group will > communicate > > with and invite participation from other relevant standards bodies > and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > > > SACM-related efforts are largely aligned, and may overlap, with other > > IETF (and non-IETF) standardization efforts. There are common > > "problems" found in SACM, that may be addressed by the work done in > > SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > > particular interest to SACM is understanding and respecting the > > distinctions between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > for > > further analysis and action. NEA may also serve the purpose of > carrying > > data-collection instructions. > > > > The MILE data formats provide a format to describe incident, threat- > > related incident, and indicator information. SACM data formats > provide > > ways to understand what endpoints are in your environment, whether > they > > meet policy requirements, and their current configuration state. The > > data exchanged in MILE, supplementing the SACM data, creates enhanced > > situational awareness, thus enabling increased understanding of > current > > threats and mitigations. The combined SACM and MILE data sets become > a > > powerful tool to automate security with descriptions of endpoints, > known > > vulnerabilities to those endpoints, and thier configurations along > with > > an understanding of layered defenses. Then, injecting known threat > > information with mitigation options assists the organization in > turning > > detailed security decisions into business-relevant decisions. The > MILE > > protocols, RID and ROLIE, enable the exchange of structured data and > are > > designed to carry any structured format. While RID may be used in > > multiple sharing models and provides multiple communication flows > > (report, query, etc.) with the ability to enable peer-to-peer object > > level security, ROLIE provides a RESTful repository transport option > > with only the need for a browser on the client end, removing > deployment > > barriers. > > > > After the work items in the current charter have been submitted to > and > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > taking into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > related standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > and > > data format for retrieving configuration and policy information for > > driving data collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > and > > data format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol > > and data format for retrieving configuration and policy information > for > > driving data collection and analysis for consideration as standards- > > track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and > > data format for collecting actual endpoint posture for consideration > as > > standards-track RFC > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From dromasca@avaya.com Mon Jun 3 06:06:10 2013 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 9EE4A21F8F2F for ; Mon, 3 Jun 2013 06:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHTXuPOdmErX for ; Mon, 3 Jun 2013 06:06:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D930721F8DBC for ; Mon, 3 Jun 2013 06:06:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAPGTrFGHCzI1/2dsb2JhbABPCoJoITC/A4EAFnSCIwEBAQECAQEBAQ8oNAQTBAIBCA0BAwEDAQELFAkHJwsUAwYIAgQBEggBEgeHZQYBC58Um3sXjWsEBoEBMwUGgnFhA5NthHqFGIp/gw+BaAkXHw X-IronPort-AV: E=Sophos;i="4.87,792,1363147200"; d="scan'208";a="14442511" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Jun 2013 09:06:03 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Jun 2013 09:01:32 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 09:06:02 -0400 From: "Romascanu, Dan (Dan)" To: Stephen Hanna , "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6nvQLc+l7pAnUKQTep8PIA24Zkj72EQ///lKICAACId8A== Date: Mon, 3 Jun 2013 13:06:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17F2BD@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17F243@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 13:06:10 -0000 Actually if we are talking typos I found one more:=20 s/ asses sment/ assessment/ Regards, Dan > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Monday, June 03, 2013 4:03 PM > To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text >=20 > Yes, I believe this text addresses the questions asked and is ready for > submission to the IESG. >=20 > I did notice what I believe are two typos: >=20 > * In this sentence, I think "may be" should be "which > may be": >=20 > > A content repository is expected to house specific versions of > > checklists (i.e. benchmarks), may be required to satisfy different use > > cases (i.e. a NEA-specific use vs. a generally applicable assessment > > used during continuous monitoring). >=20 > * In this sentence, I think the word "an" should appear > before "up-to-date": >=20 > > In addition, content repositories are expected to store up-to-date > > dictionary of specific enumerations, such as those used for > > configuration element identifiers, asset classifications, > > vulnerability identifiers, and so on. >=20 > With those two fixes (or without them, even!), I think this charter is > ready to go. >=20 > I apologize for being quiet recently. As Mike said, things seemed to be > going so smoothly here. I didn't realize that a nudge of support was > needed. >=20 > I am happy to confirm that I'm still committed to doing the SACM work, > as agreed in the BOF sessions. > And I agree with this charter and scope. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Romascanu, Dan (Dan) > > Sent: Monday, June 03, 2013 8:44 AM > > To: Adam W. Montville; sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > Hi, > > > > Thanks to Adam for this revision. > > > > Can we have a show of hands about this version of the charter text: > > > > > > - does it clarify in a satisfactory manner the questions asked on the > > list and especially the ones asked by our AD? > > - does it reflect the consensus of the mail list on the scope of the > > first phase of the proposed WG? > > - is it good enough to be submitted to the IESG for discussions on the > > formation of the WG? > > > > All answers welcome. Any answer different than 'yes' should be > > accompanied by concrete comments on issues that still need > > clarification, and items we still need to work for consensus. > > > > Thanks and Regards, > > > > Dan > > > > > > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of > > > Adam W. Montville > > > Sent: Sunday, June 02, 2013 6:57 PM > > > To: sacm@ietf.org > > > Subject: [sacm] Updated Candidate Charter Text > > > Importance: High > > > > > > All: > > > > > > I've taken the charter > > > (http://datatracker.ietf.org/doc/charter-ietf- > > > sacm/) and comments submitted in a variety of threads > > > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and > > put > > > the following together. > > > > > > I would love to see a dramatic increase in SACM participation > > throughout > > > this month - especially relating to the charter, which should be our > > > primary focus at this point, and then limited to the first several > > > milestones. > > > > > > My concern is that SACM momentum is trailing off at a point when it > > > needs to be maintaining, if not increasing, from that level we saw > > > at IETF 86. > > > > > > The following is the modified charter text: > > > > > > Securing information and the systems that store, process, and > > transmit > > > that information is a challenging task for organizations of all > > sizes, > > > and many security practitioners spend much of their time on manual > > > processes. Standardized processes to collect, verify, and update > > > security system configurations would allow easier automation of the > > > processes. Automating these routine tasks would free security > > > practitioners to focus on high priority tasks, and should improve > > > operators' ability to prioritize risk based on timely information > > about > > > threats and vulnerabilities. This working group will define security > > > automation protocols and data format standards in support of > > information > > > security processes and practices. These standards will help security > > > practitioners to be more effective by automating routine tasks > > related > > > to client and server security, freeing them to focus on more > > > advanced tasks. The initial focus of this work is to address > > > enterprise use > > cases > > > pertaining to the asses sment of endpoint posture (using the > > > definitions of Endpoint and Posture from RFC 5209). > > > > > > The working group will, whenever reasonable and possible, reuse > > existing > > > protocols, mechanisms, information and data models. Of particular > > > interest to this working group are existing industry standards, > > > preferably IETF standards, that could support automation of asset, > > > change, configuration, and vulnerability management. > > > > > > The working group will define: > > > > > > 1. A set of standards to enable assessment of endpoint posture. This > > > area of focus provides for necessary language and data format > > > specifications. > > > > > > 2. A set of standards for interacting with repositories of content > > > related to assessment of endpoint posture. > > > > > > Assessment of endpoint posture assessment entails the following > > general > > > steps: > > > > > > 1. Relevant endpoints are identified and classified based on the > > targets > > > of the policy/policies to be evaluated > > > > > > 2. For each endpoint, determine what elements of posture information > > to > > > collect based on the policy/policies to be evaluated > > > > > > 3. For each element of the endpoint posture data, identify the > > mechanism > > > for data collection and what content is needed, if any, to support > > data > > > collection > > > > > > 4. Retrieve any content needed for data collection. Configuration > > > checks pertaining to a particular posture element may be used to > > support > > > data collection. > > > > > > 5. Harvest the actual values pertaining to posture elements > > identified > > > in step 3 from the endpoint. > > > > > > 6. Report collected endpoint posture as identified in step 2. This > > will > > > likely be done on an individual basis for each identified endpoint, > > > requiring aggregation of data collected from multiple endpoints as > > > needed based on the identified policy. > > > > > > This approach to endpoint posture collection enables multiple > > policies > > > to be evaluated based on a single data collection activity. Policies > > > will be evaluated by comparing available endpoint posture data > > according > > > to rules expressed in the policy. Typically, these rules will > > > compare the actual value against an expected value or range for > > > specific > > posture > > > elements. In some cases, the posture element may pertain to software > > > installation state, in which case the actual and expected values may > > be > > > "installed" or "not installed." Evaluation of multiple posture > > elements > > > may be combined using Boolean logic. > > > > > > Repository protocols are needed to store, update, and retrieve > > > configuration checks and other types of content required for posture > > > assessment (see step 2 above). A content repository is expected to > > > house specific versions of checklists (i.e. benchmarks), may be > > required > > > to satisfy different use cases (i.e. a NEA-specific use vs. a > > generally > > > applicable assessment used during continuous monitoring). In > > addition, > > > content repositories are expected to store up-to-date dictionary of > > > specific enumerations, such as those used for configuration element > > > identifiers, asset classifications, vulnerability identifiers, and > > > so on. > > > > > > This working group will achieve the following deliverables: > > > > > > - An Informational document on Use Cases > > > - An Informational document on Requirements > > > - An Informational document on SACM Architecture > > > - A standards-track document specifying a protocol and data format > > for > > > retrieving configuration and policy information for driving data > > > collection and analysis > > > - A standards-track document specifying a protocol and data format > > for > > > collecting actual endpoint posture > > > > > > The working group will create an overview of related standards work > > > Internet-Draft which will document existing work in the IETF or in > > other > > > SDOs which can be used as-is or as a starting point for developing > > > solutions to the SACM requirements. The working group may decide to > > make > > > of this document an Informational RFC, but this is not a mandatory > > > deliverable. > > > > > > The working group will work in close coordination with other WGs in > > the > > > IETF (including, but not limited to MILE and NEA) in order to create > > > solutions that do not overlap (for example for the repository access > > > protocol) and can be used or re-used to meet the goals of more than > > one > > > working group. > > > > > > In accordance with existing IETF processes, the group will > > communicate > > > with and invite participation from other relevant standards bodies > > and > > > regulatory organizations, and if necessary reuse existing liaison > > > relationships or request the establishment of new liaison > > relationships. > > > > > > SACM-related efforts are largely aligned, and may overlap, with > > > other IETF (and non-IETF) standardization efforts. There are common > > > "problems" found in SACM, that may be addressed by the work done in > > > SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > > > particular interest to SACM is understanding and respecting the > > > distinctions between itself and NEA and MILE. > > > > > > One way the NEA protocols can be used is as the transport for data > > > collected on the endpoint to an external service or data repository > > for > > > further analysis and action. NEA may also serve the purpose of > > carrying > > > data-collection instructions. > > > > > > The MILE data formats provide a format to describe incident, threat- > > > related incident, and indicator information. SACM data formats > > provide > > > ways to understand what endpoints are in your environment, whether > > they > > > meet policy requirements, and their current configuration state. > > > The data exchanged in MILE, supplementing the SACM data, creates > > > enhanced situational awareness, thus enabling increased > > > understanding of > > current > > > threats and mitigations. The combined SACM and MILE data sets > > > become > > a > > > powerful tool to automate security with descriptions of endpoints, > > known > > > vulnerabilities to those endpoints, and thier configurations along > > with > > > an understanding of layered defenses. Then, injecting known threat > > > information with mitigation options assists the organization in > > turning > > > detailed security decisions into business-relevant decisions. The > > MILE > > > protocols, RID and ROLIE, enable the exchange of structured data and > > are > > > designed to carry any structured format. While RID may be used in > > > multiple sharing models and provides multiple communication flows > > > (report, query, etc.) with the ability to enable peer-to-peer object > > > level security, ROLIE provides a RESTful repository transport option > > > with only the need for a browser on the client end, removing > > deployment > > > barriers. > > > > > > After the work items in the current charter have been submitted to > > and > > > approved by the IESG, the WG will recharter or close. > > > > > > Goals and Milestones > > > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > > taking into consideration RFC5706 and RFC3535 > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > Architecture > > > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > > related standards work > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > and > > > data format for retrieving configuration and policy information for > > > driving data collection and analysis > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > and > > > data format for collecting actual endpoint posture > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > > > Cases for consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > Requirements > > > for consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > > Architecture for consideration as Informational RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > protocol > > > and data format for retrieving configuration and policy information > > for > > > driving data collection and analysis for consideration as standards- > > > track RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > and > > > data format for collecting actual endpoint posture for consideration > > as > > > standards-track RFC > > > > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 >=20 From dbharrington@comcast.net Mon Jun 3 10:25:47 2013 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 378A821F8616 for ; Mon, 3 Jun 2013 10:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.44 X-Spam-Level: X-Spam-Status: No, score=0.44 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 r+hG7C5BeZTG for ; Mon, 3 Jun 2013 10:25:31 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 2311121F8551 for ; Mon, 3 Jun 2013 10:20:46 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id jmpb1l0041HzFnQ59tLme9; Mon, 03 Jun 2013 17:20:46 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta14.westchester.pa.mail.comcast.net with comcast id jtLm1l00D2yZEBF3atLmbA; Mon, 03 Jun 2013 17:20:46 +0000 From: "David Harrington" To: Date: Mon, 3 Jun 2013 13:20:25 -0400 Message-ID: <009701ce607e$a3274a50$e975def0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5gfiXGmRzO8GHaRlCNV4DkFY3EPg== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370280046; bh=EDFf0JCv+iKZ8uMdD5UYzy2QdEs5fiwsBsgV8StRb6Y=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Ywzlf8kDCtWMp41t12A7i+ywj3EtOPX5RCAlReFJTEQ9Qs41YNlpirO1KmjoShNen qv4KclFrVesM1RdKeMP9mP/s8LiOEAozgiR/nYA1K22TU9iFQFOG+8jvg4PfmaxuRh 6rXKDcsHH7Lq/123hZGQUuKy8oxotPnHd3lnZycm3Lbbns0HwWHHfptRbBYPfqPI7G bcJsAxYmmXF2GXJK6a6KwJ5I/52GW52tq6lzrK2iSc4N9Sr+a7/Pl9KpA2ZdLFsNnu eKvzDiX/Xpuztlt9QWh/vNlcTCX/XA9ypIe9YyieF5Ns2d5gTH2/pm4T5tAD5zGtBX UoiM/btSW1D+w== Subject: [sacm] sacm participation and scope 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, 03 Jun 2013 17:25:47 -0000 Hi, There appear to be about 6 people active on the ML: 2 authors discussing their drafts, 2 chairs acting administratively (but not much technical discussion), one contributor who chairs a related WG, and myself. That wouldn't pass my AD test that there needs to be a significant community that believes there is a problem that needs solving. Where are the representatives from the Security area? Where are the IPsec and TLS and SSH and Kerberos and PKI WG experts? Where are the representatives from the Security products industry? Where are the firewall and IDS and DPI vendor experts? Where are the representatives from the OPS(NM) area? Where are the Netconf, ipfix, syslog, snmp guys? (well, I guess you can count me but that's not many). Where are the representatives from the AAA community? Radius? Diameter? Where are the representatives from the config automation community? DHCP, NACP, homenet, Where are the representatives from the OPS(OPS) area? Where are the operators, and the enterprise/ISP security admins? Opsec? V6ops? Where are the representatives from the OPS(OPS) area? Where are the websec and https guys? Where are the server guys? I am concerned that the work being done so far is 30,000-foot stuff, with no details. I don't know from the charter just what security we plan to automate. I see discussions of the need for protocols and data models, but almost no details of what specific information needs to be modeled, or the properties of the protocols needed to transport that data, or what's going to be done with the data. I think our discussions are so high-level that people from other WGs cannot tell if there is anything relevant to them in this proposed WG. I don't think we're ready for a WG. I think we need a much more narrow and clearly-defined scope in the charter. My $.02 David Harrington dbharrington@comcast.net +1-603-828-1401 From Kent_Landfield@mcafee.com Mon Jun 3 11:02:09 2013 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 F085121F962D for ; Mon, 3 Jun 2013 11:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5Wcbs4vsqbt for ; Mon, 3 Jun 2013 11:01:54 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 31FB521F9473 for ; Mon, 3 Jun 2013 11:00:00 -0700 (PDT) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 0f3b_3756_439f43a0_b66a_43c4_b747_32c5ad6ca81e; Mon, 03 Jun 2013 12:59:53 -0500 Received: from MIVEXAPP2N1.corp.nai.org (10.48.48.71) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 3 Jun 2013 13:58:31 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAPP2N1.corp.nai.org ([169.254.2.228]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 13:58:30 -0400 From: To: , , , Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6npxNalvQ89Okyx82eII/CXtpkkM+KAgAAFPID///6xAA== Date: Mon, 3 Jun 2013 17:58:30 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF27329E@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.241] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF27329EMIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 18:02:09 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF27329EMIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes I too agree that this does seem to answer the questions and I like Stev= e's comments as well. I to am committed to the effort now and going forward. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Monday, June 3, 2013 8:03 AM To: "Romascanu, Dan (Dan)" >,= "Adam W. Montville" = >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text Yes, I believe this text addresses the questions asked and is ready for submission to the IESG. I did notice what I believe are two typos: * In this sentence, I think "may be" should be "which may be": A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring). * In this sentence, I think the word "an" should appear before "up-to-date": In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. With those two fixes (or without them, even!), I think this charter is ready to go. I apologize for being quiet recently. As Mike said, things seemed to be going so smoothly here. I didn't realize that a nudge of support was needed. I am happy to confirm that I'm still committed to doing the SACM work, as agreed in the BOF sessions. And I agree with this charter and scope. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, June 03, 2013 8:44 AM To: Adam W. Montville; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text Hi, Thanks to Adam for this revision. Can we have a show of hands about this version of the charter text: - does it clarify in a satisfactory manner the questions asked on the list and especially the ones asked by our AD? - does it reflect the consensus of the mail list on the scope of the first phase of the proposed WG? - is it good enough to be submitted to the IESG for discussions on the formation of the WG? All answers welcome. Any answer different than 'yes' should be accompanied by concrete comments on issues that still need clarification, and items we still need to work for consensus. Thanks and Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf Of > Adam W. Montville > Sent: Sunday, June 02, 2013 6:57 PM > To: sacm@ietf.org > Subject: [sacm] Updated Candidate Charter Text > Importance: High > > All: > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf- > sacm/) and comments submitted in a variety of threads > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put > the following together. > > I would love to see a dramatic increase in SACM participation throughout > this month - especially relating to the charter, which should be our > primary focus at this point, and then limited to the first several > milestones. > > My concern is that SACM momentum is trailing off at a point when it > needs to be maintaining, if not increasing, from that level we saw at > IETF 86. > > The following is the modified charter text: > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual > processes. Standardized processes to collect, verify, and update > security system configurations would allow easier automation of the > processes. Automating these routine tasks would free security > practitioners to focus on high priority tasks, and should improve > operators' ability to prioritize risk based on timely information about > threats and vulnerabilities. This working group will define security > automation protocols and data format standards in support of information > security processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use cases > pertaining to the asses sment of endpoint posture (using the > definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse existing > protocols, mechanisms, information and data models. Of particular > interest to this working group are existing industry standards, > preferably IETF standards, that could support automation of asset, > change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format > specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following general > steps: > > 1. Relevant endpoints are identified and classified based on the targets > of the policy/policies to be evaluated > > 2. For each endpoint, determine what elements of posture information to > collect based on the policy/policies to be evaluated > > 3. For each element of the endpoint posture data, identify the mechanism > for data collection and what content is needed, if any, to support data > collection > > 4. Retrieve any content needed for data collection. Configuration > checks pertaining to a particular posture element may be used to support > data collection. > > 5. Harvest the actual values pertaining to posture elements identified > in step 3 from the endpoint. > > 6. Report collected endpoint posture as identified in step 2. This will > likely be done on an individual basis for each identified endpoint, > requiring aggregation of data collected from multiple endpoints as > needed based on the identified policy. > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data according > to rules expressed in the policy. Typically, these rules will compare > the actual value against an expected value or range for specific posture > elements. In some cases, the posture element may pertain to software > installation state, in which case the actual and expected values may be > "installed" or "not installed." Evaluation of multiple posture elements > may be combined using Boolean logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be required > to satisfy different use cases (i.e. a NEA-specific use vs. a generally > applicable assessment used during continuous monitoring). In addition, > content repositories are expected to store up-to-date dictionary of > specific enumerations, such as those used for configuration element > identifiers, asset classifications, vulnerability identifiers, and so > on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in other > SDOs which can be used as-is or as a starting point for developing > solutions to the SACM requirements. The working group may decide to make > of this document an Informational RFC, but this is not a mandatory > deliverable. > > The working group will work in close coordination with other WGs in the > IETF (including, but not limited to MILE and NEA) in order to create > solutions that do not overlap (for example for the repository access > protocol) and can be used or re-used to meet the goals of more than one > working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common > "problems" found in SACM, that may be addressed by the work done in > SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > particular interest to SACM is understanding and respecting the > distinctions between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository for > further analysis and action. NEA may also serve the purpose of carrying > data-collection instructions. > > The MILE data formats provide a format to describe incident, threat- > related incident, and indicator information. SACM data formats provide > ways to understand what endpoints are in your environment, whether they > meet policy requirements, and their current configuration state. The > data exchanged in MILE, supplementing the SACM data, creates enhanced > situational awareness, thus enabling increased understanding of current > threats and mitigations. The combined SACM and MILE data sets become a > powerful tool to automate security with descriptions of endpoints, known > vulnerabilities to those endpoints, and thier configurations along with > an understanding of layered defenses. Then, injecting known threat > information with mitigation options assists the organization in turning > detailed security decisions into business-relevant decisions. The MILE > protocols, RID and ROLIE, enable the exchange of structured data and are > designed to carry any structured format. While RID may be used in > multiple sharing models and provides multiple communication flows > (report, query, etc.) with the ability to enable peer-to-peer object > level security, ROLIE provides a RESTful repository transport option > with only the need for a browser on the client end, removing deployment > barriers. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol > and data format for retrieving configuration and policy information for > driving data collection and analysis for consideration as standards- > track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and > data format for collecting actual endpoint posture for consideration as > standards-track RFC > > _______________________________________________ > 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_3CBA099FBA0AB843895D72474092B8CF27329EMIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes I too agree that this does seem to answer the questions and I like= Steve's comments as well.

I to am committed to the effort now and going forward.

Thanks.

Kent Landfield

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

From: Stephen Hanna <shanna@juniper.net>
Date: Monday, June 3, 2013 8:03 AM<= br> To: "Romascanu, Dan (Dan)"= ; <dromasca@avaya.com>, &qu= ot;Adam W. Montville" <ad= am@stoicsecurity.com>, "sacm@i= etf.org" <sacm@ietf.org>
Subject: Re: [sacm] Updated Candida= te Charter Text

Yes, I believe this text addresses the questions asked
and is ready for submission to the IESG.

I did notice what I believe are two typos:

* In this sentence, I think "may be" should be "which
  may be":

A content repository is expected to house specific versions
of checklists (i.e. benchmarks), may be required to satisfy
different use cases (i.e. a NEA-specific use vs. a generally
applicable assessment used during continuous monitoring).

* In this sentence, I think the word "an" should appear
  before "up-to-date":

In addition, content repositories are expected to store up-to-date
dictionary of specific enumerations, such as those used for
configuration element identifiers, asset classifications,
vulnerability identifiers, and so on.

With those two fixes (or without them, even!),
I think this charter is ready to go.

I apologize for being quiet recently. As Mike said,
things seemed to be going so smoothly here. I didn't
realize that a nudge of support was needed.

I am happy to confirm that I'm still committed to
doing the SACM work, as agreed in the BOF sessions.
And I agree with this charter and scope.

Thanks,

Steve

-----Original Message-----
Romascanu, Dan (Dan)
Sent: Monday, June 03, 2013 8:44 AM
Subject: Re: [sacm] Updated Candidate Charter Text
Hi,
Thanks to Adam for this revision.
Can we have a show of hands about this version of the charter text:
- does it clarify in a satisfactory manner the questions asked on the<= /div>
list and especially the ones asked by our AD?
- does it reflect the consensus of the mail list on the scope of the
first phase of the proposed WG?
- is it good enough to be submitted to the IESG for discussions on the=
formation of the WG?
All answers welcome. Any answer different than 'yes' should be
accompanied by concrete comments on issues that still need
clarification, and items we still need to work for consensus.
Thanks and Regards,
Dan
> -----Original Message-----
Of
> Adam W. Montville
> Sent: Sunday, June 02, 2013 6:57 PM
> Subject: [sacm] Updated Candidate Charter Text
> Importance: High
>
> All:
>
> sacm/) and comments submitted in a variety of threads
put
> the following together.
>
> I would love to see a dramatic increase in SACM participation
throughout
> this month - especially relating to the charter, which should be = our
> primary focus at this point, and then limited to the first severa= l
> milestones.
>
> My concern is that SACM momentum is trailing off at a point when = it
> needs to be maintaining, if not increasing, from that level we sa= w at
> IETF 86.
>
> The following is the modified charter text:
>
> Securing information and the systems that store, process, and
transmit
> that information is a challenging task for organizations of all
sizes,
> and many security practitioners spend much of their time on manua= l
> processes. Standardized processes to collect, verify, and update<= /div>
> security system configurations would allow easier automation of t= he
> processes. Automating these routine tasks would free security
> practitioners to focus on high priority tasks, and should improve=
> operators' ability to prioritize risk based on timely information=
about
> threats and vulnerabilities. This working group will define secur= ity
> automation protocols and data format standards in support of
information
> security processes and practices. These standards will help secur= ity
> practitioners to be more effective by automating routine tasks
related
> to client and server security, freeing them to focus on more adva= nced
> tasks. The initial focus of this work is to address enterprise us= e
cases
> pertaining to the asses  sment of endpoint posture (usi= ng the
> definitions of Endpoint and Posture from RFC 5209).
>
> The working group will, whenever reasonable and possible, reuse
existing
> protocols, mechanisms, information and data models. Of particular=
> interest to this working group are existing industry standards,
> preferably IETF standards, that could support automation of asset= ,
> change, configuration, and vulnerability management.
>
> The working group will define:
>
> 1. A set of standards to enable assessment of endpoint posture. T= his
> area of focus provides for necessary language and data format
> specifications.
>
> 2. A set of standards for interacting with repositories of conten= t
> related to assessment of endpoint posture.
>
> Assessment of endpoint posture assessment entails the following
general
> steps:
>
> 1. Relevant endpoints are identified and classified based on the<= /div>
targets
> of the policy/policies to be evaluated
>
> 2. For each endpoint, determine what elements of posture informat= ion
to
> collect based on the policy/policies to be evaluated
>
> 3. For each element of the endpoint posture data, identify the
mechanism
> for data collection and what content is needed, if any, to suppor= t
data
> collection
>
> 4. Retrieve any content needed for data collection.  Co= nfiguration
> checks pertaining to a particular posture element may be used to<= /div>
support
> data collection.
>
> 5. Harvest the actual values pertaining to posture elements
identified
> in step 3 from the endpoint.
>
> 6. Report collected endpoint posture as identified in step 2.&nbs= p; This
will
> likely be done on an individual basis for each identified endpoin= t,
> requiring aggregation of data collected from multiple endpoints a= s
> needed based on the identified policy.
>
> This approach to endpoint posture collection enables multiple
policies
> to be evaluated based on a single data collection activity. Polic= ies
> will be evaluated by comparing available endpoint posture data
according
> to rules expressed in the policy. Typically, these rules will com= pare
> the actual value against an expected value or range for specific<= /div>
posture
> elements. In some cases, the posture element may pertain to softw= are
> installation state, in which case the actual and expected values = may
be
> "installed" or "not installed." Evaluation of= multiple posture
elements
> may be combined using Boolean logic.
>
> Repository protocols are needed to store, update, and retrieve
> configuration checks and other types of content required for post= ure
> assessment (see step 2 above).  A content repository is= expected to
> house specific versions of checklists (i.e. benchmarks), may be
required
> to satisfy different use cases (i.e. a NEA-specific use vs. a
generally
> applicable assessment used during continuous monitoring). &n= bsp;In
addition,
> content repositories are expected to store up-to-date dictionary = of
> specific enumerations, such as those used for configuration eleme= nt
> identifiers, asset classifications, vulnerability identifiers, an= d so
> on.
>
> This working group will achieve the following deliverables:
>
> - An Informational document on Use Cases
> - An Informational document on Requirements
> - An Informational document on SACM Architecture
> - A standards-track document specifying a protocol and data forma= t
for
> retrieving configuration and policy information for driving data<= /div>
> collection and analysis
> - A standards-track document specifying a protocol and data forma= t
for
> collecting actual endpoint posture
>
> The working group will create an overview of related standards wo= rk
> Internet-Draft which will document existing work in the IETF or i= n
other
> SDOs which can be used as-is or as a starting point for developin= g
> solutions to the SACM requirements. The working group may decide = to
make
> of this document an Informational RFC, but this is not a mandator= y
> deliverable.
>
> The working group will work in close coordination with other WGs = in
the
> IETF (including, but not limited to MILE and NEA) in order to cre= ate
> solutions that do not overlap (for example for the repository acc= ess
> protocol) and can be used or re-used to meet the goals of more th= an
one
> working group.
>
> In accordance with existing IETF processes, the group will
communicate
> with and invite participation from other relevant standards bodie= s
and
> regulatory organizations, and if necessary reuse existing liaison=
> relationships or request the establishment of new liaison
relationships.
>
> SACM-related efforts are largely aligned, and may overlap, with o= ther
> IETF (and non-IETF) standardization efforts.  There are= common
> "problems" found in SACM, that may be addressed by the = work done in
> SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.&= nbsp; Of
> particular interest to SACM is understanding and respecting the
> distinctions between itself and NEA and MILE.
>
> One way the NEA protocols can be used is as the transport for dat= a
> collected on the endpoint to an external service or data reposito= ry
for
> further analysis and action.  NEA may also serve the pu= rpose of
carrying
> data-collection instructions.
>
> The MILE data formats provide a format to describe incident, thre= at-
> related incident, and indicator information.  SACM data= formats
provide
> ways to understand what endpoints are in your environment, whethe= r
they
> meet policy requirements, and their current configuration state.&= nbsp; The
> data exchanged in MILE, supplementing the SACM data, creates enha= nced
> situational awareness, thus enabling increased understanding of
current
> threats and mitigations.  The combined SACM and MILE da= ta sets become
a
> powerful tool to automate security with descriptions of endpoints= ,
known
> vulnerabilities to those endpoints, and thier configurations alon= g
with
> an understanding of layered defenses.  Then, injecting = known threat
> information with mitigation options assists the organization in
turning
> detailed security decisions into business-relevant decisions.&nbs= p; The
MILE
> protocols, RID and ROLIE, enable the exchange of structured data = and
are
> designed to carry any structured format.  While RID may= be used  in
> multiple sharing models and provides multiple communication flows=
> (report, query, etc.) with the ability to enable peer-to-peer obj= ect
> level security, ROLIE provides a RESTful repository transport opt= ion
> with only the need for a browser on the client end, removing
deployment
> barriers.
>
> After the work items in the current charter have been submitted t= o
and
> approved by the IESG, the WG will recharter or close.
>
> Goals and Milestones
>
> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases<= /div>
>
> Oct. 2013 - Initial submission of an Internet-Draft on Requiremen= ts
> taking into consideration RFC5706 and RFC3535
>
> Oct. 2013 - Initial submission of an Internet-Draft on SACM
Architecture
>
> Nov. 2013 - Initial submission of an Internet-Draft on overview o= f
> related standards work
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protoco= l
and
> data format for retrieving configuration and policy information f= or
> driving data collection and analysis
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protoco= l
and
> data format for collecting actual endpoint posture
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use C= ases
> for consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on
Requirements
> for consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM<= /div>
> Architecture for consideration as Informational RFC
>



_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF27329EMIVEXAMER1N1corpn_-- From blakefrantz@gmail.com Mon Jun 3 11:51:59 2013 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 56B5C11E80C5 for ; Mon, 3 Jun 2013 11:51:59 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4RwynGy36IJ for ; Mon, 3 Jun 2013 11:51:48 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA2421E805E for ; Mon, 3 Jun 2013 11:49:27 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h2so1258385oag.19 for ; Mon, 03 Jun 2013 11:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UceHp6rrh6/RrofVmsM8eqRmz7JRDQMWORxTd9ai+t0=; b=xnPEZ0jKPjUmBhDhK9/f3HntvQxvHNRbsMxP4/20FkN/FQEJMaU0FXKkcLdufrWHg8 bKUU+lKz7RDDtlYLSSWjVyOKk9jv8h9QMNA8Z/kdUgloZYENsVjFq4tsJsaVos/yLWuu RIzk/UAji0bYr6COH7CUSL+ejMsmwkJ9vFGNZ7FxfmgiJAHGGb6rDUWq6mDmbw+iB1GN QL6Fm50blH/Wc1xvXPNyJl1nhtkFkonGkyZzmMMeJkPylfXeP3q5IoKmFoB0oGQZKthU lf2lu1H1/94Ys8G5ceNJomQu9Nv3CNyF5rAVlAR92kW8sVyqwB7n0516FfY80S2TsntY 0QOQ== MIME-Version: 1.0 X-Received: by 10.60.34.135 with SMTP id z7mr10736989oei.68.1370285366611; Mon, 03 Jun 2013 11:49:26 -0700 (PDT) Received: by 10.76.13.162 with HTTP; Mon, 3 Jun 2013 11:49:26 -0700 (PDT) In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF27329E@MIVEXAMER1N1.corp.nai.org> References: <3CBA099FBA0AB843895D72474092B8CF27329E@MIVEXAMER1N1.corp.nai.org> Date: Mon, 3 Jun 2013 11:49:26 -0700 Message-ID: From: Blake Frantz To: Kent_Landfield@mcafee.com Content-Type: multipart/alternative; boundary=089e0122acb48498ec04de446c57 Cc: dromasca@avaya.com, shanna@juniper.net, adam@stoicsecurity.com, "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 18:51:59 -0000 --089e0122acb48498ec04de446c57 Content-Type: text/plain; charset=ISO-8859-1 I remain committed to SACM and support the updated charter and scope. On Mon, Jun 3, 2013 at 10:58 AM, wrote: > Yes I too agree that this does seem to answer the questions and I like > Steve's comments as well. > > I to am committed to the effort now and going forward. > > Thanks. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: Stephen Hanna > Date: Monday, June 3, 2013 8:03 AM > To: "Romascanu, Dan (Dan)" , "Adam W. Montville" < > adam@stoicsecurity.com>, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text > > Yes, I believe this text addresses the questions asked > and is ready for submission to the IESG. > > I did notice what I believe are two typos: > > * In this sentence, I think "may be" should be "which > may be": > > A content repository is expected to house specific versions > of checklists (i.e. benchmarks), may be required to satisfy > different use cases (i.e. a NEA-specific use vs. a generally > applicable assessment used during continuous monitoring). > > > * In this sentence, I think the word "an" should appear > before "up-to-date": > > In addition, content repositories are expected to store up-to-date > dictionary of specific enumerations, such as those used for > configuration element identifiers, asset classifications, > vulnerability identifiers, and so on. > > > With those two fixes (or without them, even!), > I think this charter is ready to go. > > I apologize for being quiet recently. As Mike said, > things seemed to be going so smoothly here. I didn't > realize that a nudge of support was needed. > > I am happy to confirm that I'm still committed to > doing the SACM work, as agreed in the BOF sessions. > And I agree with this charter and scope. > > Thanks, > > Steve > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] > On Behalf Of > Romascanu, Dan (Dan) > Sent: Monday, June 03, 2013 8:44 AM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text > Hi, > Thanks to Adam for this revision. > Can we have a show of hands about this version of the charter text: > - does it clarify in a satisfactory manner the questions asked on the > list and especially the ones asked by our AD? > - does it reflect the consensus of the mail list on the scope of the > first phase of the proposed WG? > - is it good enough to be submitted to the IESG for discussions on the > formation of the WG? > All answers welcome. Any answer different than 'yes' should be > accompanied by concrete comments on issues that still need > clarification, and items we still need to work for consensus. > Thanks and Regards, > Dan > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] > On Behalf > Of > > Adam W. Montville > > Sent: Sunday, June 02, 2013 6:57 PM > > To: sacm@ietf.org > > Subject: [sacm] Updated Candidate Charter Text > > Importance: High > > > > All: > > > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf- > > sacm/) and comments submitted in a variety of threads > > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and > put > > the following together. > > > > I would love to see a dramatic increase in SACM participation > throughout > > this month - especially relating to the charter, which should be our > > primary focus at this point, and then limited to the first several > > milestones. > > > > My concern is that SACM momentum is trailing off at a point when it > > needs to be maintaining, if not increasing, from that level we saw at > > IETF 86. > > > > The following is the modified charter text: > > > > Securing information and the systems that store, process, and > transmit > > that information is a challenging task for organizations of all > sizes, > > and many security practitioners spend much of their time on manual > > processes. Standardized processes to collect, verify, and update > > security system configurations would allow easier automation of the > > processes. Automating these routine tasks would free security > > practitioners to focus on high priority tasks, and should improve > > operators' ability to prioritize risk based on timely information > about > > threats and vulnerabilities. This working group will define security > > automation protocols and data format standards in support of > information > > security processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks > related > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > cases > > pertaining to the asses sment of endpoint posture (using the > > definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse > existing > > protocols, mechanisms, information and data models. Of particular > > interest to this working group are existing industry standards, > > preferably IETF standards, that could support automation of asset, > > change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area of focus provides for necessary language and data format > > specifications. > > > > 2. A set of standards for interacting with repositories of content > > related to assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following > general > > steps: > > > > 1. Relevant endpoints are identified and classified based on the > targets > > of the policy/policies to be evaluated > > > > 2. For each endpoint, determine what elements of posture information > to > > collect based on the policy/policies to be evaluated > > > > 3. For each element of the endpoint posture data, identify the > mechanism > > for data collection and what content is needed, if any, to support > data > > collection > > > > 4. Retrieve any content needed for data collection. Configuration > > checks pertaining to a particular posture element may be used to > support > > data collection. > > > > 5. Harvest the actual values pertaining to posture elements > identified > > in step 3 from the endpoint. > > > > 6. Report collected endpoint posture as identified in step 2. This > will > > likely be done on an individual basis for each identified endpoint, > > requiring aggregation of data collected from multiple endpoints as > > needed based on the identified policy. > > > > This approach to endpoint posture collection enables multiple > policies > > to be evaluated based on a single data collection activity. Policies > > will be evaluated by comparing available endpoint posture data > according > > to rules expressed in the policy. Typically, these rules will compare > > the actual value against an expected value or range for specific > posture > > elements. In some cases, the posture element may pertain to software > > installation state, in which case the actual and expected values may > be > > "installed" or "not installed." Evaluation of multiple posture > elements > > may be combined using Boolean logic. > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > required > > to satisfy different use cases (i.e. a NEA-specific use vs. a > generally > > applicable assessment used during continuous monitoring). In > addition, > > content repositories are expected to store up-to-date dictionary of > > specific enumerations, such as those used for configuration element > > identifiers, asset classifications, vulnerability identifiers, and so > > on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format > for > > retrieving configuration and policy information for driving data > > collection and analysis > > - A standards-track document specifying a protocol and data format > for > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > other > > SDOs which can be used as-is or as a starting point for developing > > solutions to the SACM requirements. The working group may decide to > make > > of this document an Informational RFC, but this is not a mandatory > > deliverable. > > > > The working group will work in close coordination with other WGs in > the > > IETF (including, but not limited to MILE and NEA) in order to create > > solutions that do not overlap (for example for the repository access > > protocol) and can be used or re-used to meet the goals of more than > one > > working group. > > > > In accordance with existing IETF processes, the group will > communicate > > with and invite participation from other relevant standards bodies > and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > > > SACM-related efforts are largely aligned, and may overlap, with other > > IETF (and non-IETF) standardization efforts. There are common > > "problems" found in SACM, that may be addressed by the work done in > > SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > > particular interest to SACM is understanding and respecting the > > distinctions between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > for > > further analysis and action. NEA may also serve the purpose of > carrying > > data-collection instructions. > > > > The MILE data formats provide a format to describe incident, threat- > > related incident, and indicator information. SACM data formats > provide > > ways to understand what endpoints are in your environment, whether > they > > meet policy requirements, and their current configuration state. The > > data exchanged in MILE, supplementing the SACM data, creates enhanced > > situational awareness, thus enabling increased understanding of > current > > threats and mitigations. The combined SACM and MILE data sets become > a > > powerful tool to automate security with descriptions of endpoints, > known > > vulnerabilities to those endpoints, and thier configurations along > with > > an understanding of layered defenses. Then, injecting known threat > > information with mitigation options assists the organization in > turning > > detailed security decisions into business-relevant decisions. The > MILE > > protocols, RID and ROLIE, enable the exchange of structured data and > are > > designed to carry any structured format. While RID may be used in > > multiple sharing models and provides multiple communication flows > > (report, query, etc.) with the ability to enable peer-to-peer object > > level security, ROLIE provides a RESTful repository transport option > > with only the need for a browser on the client end, removing > deployment > > barriers. > > > > After the work items in the current charter have been submitted to > and > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > taking into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > related standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > and > > data format for retrieving configuration and policy information for > > driving data collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > and > > data format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol > > and data format for retrieving configuration and policy information > for > > driving data collection and analysis for consideration as standards- > > track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and > > data format for collecting actual endpoint posture for consideration > as > > standards-track RFC > > > > _______________________________________________ > > 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 > > --089e0122acb48498ec04de446c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I remain committed to SACM and support the update= d charter and scope.



On Mon, Jun 3, 2013 at 10:58 AM, <Kent_Landfield@mcafee.com> wrote:
Yes I too agree that this does seem to answer the questions and I like= Steve's comments as well.

I to am committed to the effort now and going forward.

Thanks.

Kent Landfield
McAfee | An Intel Company
Direct: +1.972.963.7096=A0
Mobile: +1.817.637.8026
Web:=A0www.mcafee.com

From: Stephen Hanna <shanna@juniper.net>
Date: Monday, June 3, 2013 8:03 AM<= br> To: "Romascanu, Dan (Dan)"= ; <dromasca@avay= a.com>, "Adam W. Montville" <adam@stoicsecurity.com>, "sacm@ietf.org" <sacm@ietf.org&g= t;
Subject: Re: [sacm] Updated Candida= te Charter Text

Yes, I believe this text addresses the questions asked
and is ready for submission to the IESG.

I did notice what I believe are two typos:

* In this sentence, I think "may be" should be "which
=A0=A0may be":

A content repository is expected to house specific versions
of checklists (i.e. benchmarks), may be required to satisfy
different use cases (i.e. a NEA-specific use vs. a generally
applicable assessment used during continuous monitoring).

* In this sentence, I think the word "an" should appear
=A0=A0before "up-to-date":

In addition, content repositories are expected to store up-to-date
dictionary of specific enumerations, such as those used for
configuration element identifiers, asset classifications,
vulnerability identifiers, and so on.

With those two fixes (or without them, even!),
I think this charter is ready to go.

I apologize for being quiet recently. As Mike said,
things seemed to be going so smoothly here. I didn't
realize that a nudge of support was needed.

I am happy to confirm that I'm still committed to
doing the SACM work, as agreed in the BOF sessions.
And I agree with this charter and scope.

Thanks,

Steve

-----Original Message-----
Romascanu, Dan (Dan)
Sent: Monday, June 03, 2013 8:44 AM
To: Adam W. Montville; sacm@ietf.org
Subject: Re: [sacm] Updated Candidate Charter Text
Hi,
Thanks to Adam for this revision.
Can we have a show of hands about this version of the charter text:
- does it clarify in a satisfactory manner the questions asked on the<= /div>
list and especially the ones asked by our AD?
- does it reflect the consensus of the mail list on the scope of the
first phase of the proposed WG?
- is it good enough to be submitted to the IESG for discussions on the=
formation of the WG?
All answers welcome. Any answer different than 'yes' should be=
accompanied by concrete comments on issues that still need
clarification, and items we still need to work for consensus.
Thanks and Regards,
Dan
> -----Original Message-----
Of
> Adam W. Montville
> Sent: Sunday, June 02, 2013 6:57 PM
> Subject: [sacm] Updated Candidate Charter Text
> Importance: High
>
> All:
>
> sacm/) and comments submitted in a variety of threads
put
> the following together.
>
> I would love to see a dramatic increase in SACM participation
throughout
> this month - especially relating to the charter, which should be = our
> primary focus at this point, and then limited to the first severa= l
> milestones.
>
> My concern is that SACM momentum is trailing off at a point when = it
> needs to be maintaining, if not increasing, from that level we sa= w at
> IETF 86.
>
> The following is the modified charter text:
>
> Securing information and the systems that store, process, and
transmit
> that information is a challenging task for organizations of all
sizes,
> and many security practitioners spend much of their time on manua= l
> processes. Standardized processes to collect, verify, and update<= /div>
> security system configurations would allow easier automation of t= he
> processes. Automating these routine tasks would free security
> practitioners to focus on high priority tasks, and should improve=
> operators' ability to prioritize risk based on timely informa= tion
about
> threats and vulnerabilities. This working group will define secur= ity
> automation protocols and data format standards in support of
information
> security processes and practices. These standards will help secur= ity
> practitioners to be more effective by automating routine tasks
related
> to client and server security, freeing them to focus on more adva= nced
> tasks. The initial focus of this work is to address enterprise us= e
cases
> pertaining to the asses=A0=A0sment of endpoint posture (using the=
> definitions of Endpoint and Posture from RFC 5209).
>
> The working group will, whenever reasonable and possible, reuse
existing
> protocols, mechanisms, information and data models. Of particular=
> interest to this working group are existing industry standards,
> preferably IETF standards, that could support automation of asset= ,
> change, configuration, and vulnerability management.
>
> The working group will define:
>
> 1. A set of standards to enable assessment of endpoint posture. T= his
> area of focus provides for necessary language and data format
> specifications.
>
> 2. A set of standards for interacting with repositories of conten= t
> related to assessment of endpoint posture.
>
> Assessment of endpoint posture assessment entails the following
general
> steps:
>
> 1. Relevant endpoints are identified and classified based on the<= /div>
targets
> of the policy/policies to be evaluated
>
> 2. For each endpoint, determine what elements of posture informat= ion
to
> collect based on the policy/policies to be evaluated
>
> 3. For each element of the endpoint posture data, identify the
mechanism
> for data collection and what content is needed, if any, to suppor= t
data
> collection
>
> 4. Retrieve any content needed for data collection.=A0=A0Configur= ation
> checks pertaining to a particular posture element may be used to<= /div>
support
> data collection.
>
> 5. Harvest the actual values pertaining to posture elements
identified
> in step 3 from the endpoint.
>
> 6. Report collected endpoint posture as identified in step 2.=A0= =A0This
will
> likely be done on an individual basis for each identified endpoin= t,
> requiring aggregation of data collected from multiple endpoints a= s
> needed based on the identified policy.
>
> This approach to endpoint posture collection enables multiple
policies
> to be evaluated based on a single data collection activity. Polic= ies
> will be evaluated by comparing available endpoint posture data
according
> to rules expressed in the policy. Typically, these rules will com= pare
> the actual value against an expected value or range for specific<= /div>
posture
> elements. In some cases, the posture element may pertain to softw= are
> installation state, in which case the actual and expected values = may
be
> "installed" or "not installed." Evaluation of= multiple posture
elements
> may be combined using Boolean logic.
>
> Repository protocols are needed to store, update, and retrieve
> configuration checks and other types of content required for post= ure
> assessment (see step 2 above).=A0=A0A content repository is expec= ted to
> house specific versions of checklists (i.e. benchmarks), may be
required
> to satisfy different use cases (i.e. a NEA-specific use vs. a
generally
> applicable assessment used during continuous monitoring).=A0=A0In=
addition,
> content repositories are expected to store up-to-date dictionary = of
> specific enumerations, such as those used for configuration eleme= nt
> identifiers, asset classifications, vulnerability identifiers, an= d so
> on.
>
> This working group will achieve the following deliverables:
>
> - An Informational document on Use Cases
> - An Informational document on Requirements
> - An Informational document on SACM Architecture
> - A standards-track document specifying a protocol and data forma= t
for
> retrieving configuration and policy information for driving data<= /div>
> collection and analysis
> - A standards-track document specifying a protocol and data forma= t
for
> collecting actual endpoint posture
>
> The working group will create an overview of related standards wo= rk
> Internet-Draft which will document existing work in the IETF or i= n
other
> SDOs which can be used as-is or as a starting point for developin= g
> solutions to the SACM requirements. The working group may decide = to
make
> of this document an Informational RFC, but this is not a mandator= y
> deliverable.
>
> The working group will work in close coordination with other WGs = in
the
> IETF (including, but not limited to MILE and NEA) in order to cre= ate
> solutions that do not overlap (for example for the repository acc= ess
> protocol) and can be used or re-used to meet the goals of more th= an
one
> working group.
>
> In accordance with existing IETF processes, the group will
communicate
> with and invite participation from other relevant standards bodie= s
and
> regulatory organizations, and if necessary reuse existing liaison=
> relationships or request the establishment of new liaison
relationships.
>
> SACM-related efforts are largely aligned, and may overlap, with o= ther
> IETF (and non-IETF) standardization efforts.=A0=A0There are commo= n
> "problems" found in SACM, that may be addressed by the = work done in
> SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.= =A0=A0Of
> particular interest to SACM is understanding and respecting the
> distinctions between itself and NEA and MILE.
>
> One way the NEA protocols can be used is as the transport for dat= a
> collected on the endpoint to an external service or data reposito= ry
for
> further analysis and action.=A0=A0NEA may also serve the purpose = of
carrying
> data-collection instructions.
>
> The MILE data formats provide a format to describe incident, thre= at-
> related incident, and indicator information.=A0=A0SACM data forma= ts
provide
> ways to understand what endpoints are in your environment, whethe= r
they
> meet policy requirements, and their current configuration state.= =A0=A0The
> data exchanged in MILE, supplementing the SACM data, creates enha= nced
> situational awareness, thus enabling increased understanding of
current
> threats and mitigations.=A0=A0The combined SACM and MILE data set= s become
a
> powerful tool to automate security with descriptions of endpoints= ,
known
> vulnerabilities to those endpoints, and thier configurations alon= g
with
> an understanding of layered defenses.=A0=A0Then, injecting known = threat
> information with mitigation options assists the organization in
turning
> detailed security decisions into business-relevant decisions.=A0= =A0The
MILE
> protocols, RID and ROLIE, enable the exchange of structured data = and
are
> designed to carry any structured format.=A0=A0While RID may be us= ed=A0=A0in
> multiple sharing models and provides multiple communication flows=
> (report, query, etc.) with the ability to enable peer-to-peer obj= ect
> level security, ROLIE provides a RESTful repository transport opt= ion
> with only the need for a browser on the client end, removing
deployment
> barriers.
>
> After the work items in the current charter have been submitted t= o
and
> approved by the IESG, the WG will recharter or close.
>
> Goals and Milestones
>
> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases<= /div>
>
> Oct. 2013 - Initial submission of an Internet-Draft on Requiremen= ts
> taking into consideration RFC5706 and RFC3535
>
> Oct. 2013 - Initial submission of an Internet-Draft on SACM
Architecture
>
> Nov. 2013 - Initial submission of an Internet-Draft on overview o= f
> related standards work
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protoco= l
and
> data format for retrieving configuration and policy information f= or
> driving data collection and analysis
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protoco= l
and
> data format for collecting actual endpoint posture
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use C= ases
> for consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on
Requirements
> for consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM<= /div>
> Architecture for consideration as Informational RFC
>
> Oct. 2014 - Submission to the IESG of the Internet-Draft for a
protocol
> and data format for retrieving configuration and policy informati= on
for
> driving data collection and analysis for consideration as standar= ds-
> track RFC
>
> Oct. 2014 - Submission to the IESG of the Internet-Draft a protoc= ol
and
> data format for collecting actual endpoint posture for considerat= ion
as
> standards-track RFC
>
> _______________________________________________
> sacm mailing list
_______________________________________________
sacm mailing list



_______________________________________________
sacm mailing list

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


--089e0122acb48498ec04de446c57-- From Adam.Montville@cisecurity.org Mon Jun 3 12:13:57 2013 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 3F94021E8086 for ; Mon, 3 Jun 2013 12:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebAhA05kQQbB for ; Mon, 3 Jun 2013 12:13:43 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3362321F8AD5 for ; Mon, 3 Jun 2013 12:05:54 -0700 (PDT) Received: from [216.82.250.19:48326] by server-2.bemta-12.messagelabs.com id 32/55-05756-019ECA15; Mon, 03 Jun 2013 19:05:52 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-87.messagelabs.com!1370286350!17328512!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 18388 invoked from network); 3 Jun 2013 19:05:51 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 3 Jun 2013 19:05:51 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%14]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 15:06:16 -0400 From: Adam Montville To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] sacm participation and scope Thread-Index: Ac5gfiXGmRzO8GHaRlCNV4DkFY3EPgACyyFt Date: Mon, 3 Jun 2013 19:05:28 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66EB0E0@CISEXCHANGE2.msisac.org.local> References: <009701ce607e$a3274a50$e975def0$@comcast.net> In-Reply-To: <009701ce607e$a3274a50$e975def0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] sacm participation and scope 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, 03 Jun 2013 19:13:57 -0000 David, I think you're asking some good, pointed questions. And, I've been= out of the loop until recently with respect to the narrowing of our scope= (but I believe we're down to "basic" configuration assessment. IIRC, the immediate purpose of this working group is to make things work b= etween tools/implementations. Many of the data formats that would be need= ed for this already exist, but, as far as automated configuration assessme= nt is concerned for the security domain, there is little-to-no support for= transporting these data formats from place to place. I expect more of the details (i.e. will we use XCCDF in some way or point = to OVAL or use SWID or leverage NEA, and so on) to be provided in our firs= t four deliverables (use cases, requirements, architecture, and related wo= rk respectively). During one of our BoF sessions (was it the first one?) we had a good, repr= esentative showing of people from other areas - many of those which you've= mentioned. The second BoF seemed to have the same. I believe 16 vendors= have voiced support for continuing security automation and continuous mon= itoring work in the IETF. I can't speak for which other IETF WGs were rep= resented at our BoF sessions, but I do know that there were many unfamilia= r faces - a good thing. Still, I agree with your assessment that the SACM list has not been well-t= raveled lately. I don't believe I've said anything out of turn or that doesn't have some b= asis in truth. I'm sure someone can put me in my place if that's the case= . Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David Har= rington [dbharrington@comcast.net] Sent: Monday, June 03, 2013 10:25 AM To: sacm@ietf.org Subject: [sacm] sacm participation and scope Hi, There appear to be about 6 people active on the ML: 2 authors discussing their drafts, 2 chairs acting administratively (but not much technical discussion), one contributor who chairs a related WG, and myself. That wouldn't pass my AD test that there needs to be a significant communi= ty that believes there is a problem that needs solving. Where are the representatives from the Security area? Where are the IPsec and TLS and SSH and Kerberos and PKI WG experts? Where are the representatives from the Security products industry? Where a= re the firewall and IDS and DPI vendor experts? Where are the representatives from the OPS(NM) area? Where are the Netconf= , ipfix, syslog, snmp guys? (well, I guess you can count me but that's not many). Where are the representatives from the AAA community? Radius? Diameter? Where are the representatives from the config automation community? DHCP, NACP, homenet, Where are the representatives from the OPS(OPS) area? Where are the operators, and the enterprise/ISP security admins? Opsec? V6ops? Where are the representatives from the OPS(OPS) area? Where are the websec= and https guys? Where are the server guys? I am concerned that the work being done so far is 30,000-foot stuff, with = no details. I don't know from the charter just what security=20we plan to automate. I see discussions of the need for protocols and data models, but almost no= details of what specific information needs to be modeled, or the propertie= s of the protocols needed to transport that data, or what's going to be done= with the data. I think our discussions are so high-level that people from other WGs canno= t tell if there is anything relevant to them in this proposed WG. I don't think we're ready for a WG. I think we need a much more narrow and clearly-defined scope in the charte= r. My $.02 David Harrington dbharrington@comcast.net +1-603-828-1401 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... 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 stephen.whitlock@boeing.com Mon Jun 3 12:55:31 2013 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 D470321F8ADF for ; Mon, 3 Jun 2013 12:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 9ysXWQj5RRRc for ; Mon, 3 Jun 2013 12:55:17 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 692811F0D3E for ; Mon, 3 Jun 2013 12:46:32 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r53JkVx1013475 for ; Mon, 3 Jun 2013 12:46:31 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r53JkVnE013444 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 3 Jun 2013 12:46:31 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com (130.247.25.195) by XCH-NWHT-03.nw.nos.boeing.com (130.247.71.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 3 Jun 2013 12:46:30 -0700 Received: from XCH-BLV-401.nw.nos.boeing.com ([169.254.1.3]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.76]) with mapi id 14.02.0328.011; Mon, 3 Jun 2013 12:46:30 -0700 From: "Whitlock, Stephen" To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] sacm participation and scope Thread-Index: Ac5gfiXGmRzO8GHaRlCNV4DkFY3EPgAEZ6GA Date: Mon, 3 Jun 2013 19:46:28 +0000 Message-ID: <69235492DB20AC4EBBED65919EB0A2A601931F@XCH-BLV-401.nw.nos.boeing.com> References: <009701ce607e$a3274a50$e975def0$@comcast.net> In-Reply-To: <009701ce607e$a3274a50$e975def0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [sacm] sacm participation and scope 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, 03 Jun 2013 19:55:32 -0000 David, While I can't answer most of your questions, I can respond a bit to the fir= st one - as to whether or not there's a problem that needs solving. I'm from a large organization that has a pretty complex IT infrastructure. = This is complicated by an extensive supply chain that interacts via the int= ernet. I don't' see any way to balance this complexity and scale against an ever e= volving set of threats without some form of standardization and automation = that will respond in real time. Ideally deviations from standard configurat= ions (whether by accident or intent) would result in a notification and ult= imately an automatic remediation. And ultimately I would like to see this w= ork between enterprises. I don't think SACM is scoped to provide this whole life cycle (nor should i= t be) but it looks like it will provide an important piece that is missing.= At this point it's a little hard for me to tell how much - and I agree wit= h some of your comments below - but maintaining a standard configuration us= ing vendor neutral tools & protocols is an important first step. While I could get some of this capability from specific vendors, I work in = an industry with small numbers of very large customers, a few very large su= ppliers, and thousands of very small suppliers. This means that there is no= leverage to dictate specific IT or security products with these customers = or the larger suppliers. Which means that any specific vendor products need= to be connected with standard protocols and use standard data formats. I'm not a developer and only represent one organization but I have to belie= ve that this issue is not unique to either my industry or company. I have h= ad some conversation with peer companies that indicate some interest althou= gh they aren't involved with the IETF - but by itself that isn't helpful wh= en making the case for a working group. Steve Whitlock The Boeing Company=20 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Dav= id Harrington Sent: Monday, June 03, 2013 10:20 AM To: sacm@ietf.org Subject: [sacm] sacm participation and scope Hi, There appear to be about 6 people active on the ML: 2 authors discussing th= eir drafts, 2 chairs acting administratively (but not much technical discus= sion), one contributor who chairs a related WG, and myself.=20 That wouldn't pass my AD test that there needs to be a significant communit= y that believes there is a problem that needs solving. Where are the representatives from the Security area? Where are the IPsec a= nd TLS and SSH and Kerberos and PKI WG experts? Where are the representatives from the Security products industry? Where ar= e the firewall and IDS and DPI vendor experts? Where are the representatives from the OPS(NM) area? Where are the Netconf,= ipfix, syslog, snmp guys? (well, I guess you can count me but that's not m= any). Where are the representatives from the AAA community? Radius? Diameter? Where are the representatives from the config automation community? DHCP, N= ACP, homenet, Where are the representatives from the OPS(OPS) area? Where a= re the operators, and the enterprise/ISP security admins? Opsec? V6ops? Where are the representatives from the OPS(OPS) area? Where are the websec = and https guys? Where are the server guys? I am concerned that the work being done so far is 30,000-foot stuff, with n= o details.=20 I don't know from the charter just what security we plan to automate. I see discussions of the need for protocols and data models, but almost no = details of what specific information needs to be modeled, or the properties= of the protocols needed to transport that data, or what's going to be done= with the data. I think our discussions are so high-level that people from other WGs cannot= tell if there is anything relevant to them in this proposed WG. I don't think we're ready for a WG. I think we need a much more narrow and clearly-defined scope in the charter= . My $.02 David Harrington dbharrington@comcast.net +1-603-828-1401 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Mon Jun 3 14:04:31 2013 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 31E3821E80B7 for ; Mon, 3 Jun 2013 14:04: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 lynr0ttPwJGh for ; Mon, 3 Jun 2013 14:04:16 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id E668321F96EA for ; Mon, 3 Jun 2013 13:57:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=MpYFYYINPkkMRczvyu9buerG8xwjofxk9R47qTzPGop2S14ZKWlFxYBj5ijIzR1Jr2BcwRTxFz9ff7qJgSmWhiSdES9E/rMkI2Lt4qJGkHMnkizpVZl0UYwXiXJ2EixN; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 3274 invoked from network); 3 Jun 2013 14:08:42 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 Jun 2013 14:08:42 -0700 Message-ID: <51AD032D.5030600@ThreatGuard.com> Date: Mon, 03 Jun 2013 16:57:17 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Adam W. Montville" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 21:04:31 -0000 Adam, thanks for taking the time to put this together and get things rolling again. I do have some specific quibbles in this I'd like to fuss over, but don't have the time right at the moment -- hopefully by tomorrow, though. --gun On 6/2/2013 11:57 AM, Adam W. Montville wrote: > All: > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments submitted in a variety of threads (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put the following together. > > I would love to see a dramatic increase in SACM participation throughout this month - especially relating to the charter, which should be our primary focus at this point, and then limited to the first several milestones. > > My concern is that SACM momentum is trailing off at a point when it needs to be maintaining, if not increasing, from that level we saw at IETF 86. > > The following is the modified charter text: > > Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized processes to collect, verify, and update security system configurations would allow easier automation of the processes. Automating these routine tasks would free security practitioners to focus on high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. This working group will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security, freeing them to focus on more advanced tasks. The initial focus of this work is to address enterprise use cases pertaining to the ass es > sment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following general steps: > > 1. Relevant endpoints are identified and classified based on the targets of the policy/policies to be evaluated > > 2. For each endpoint, determine what elements of posture information to collect based on the policy/policies to be evaluated > > 3. For each element of the endpoint posture data, identify the mechanism for data collection and what content is needed, if any, to support data collection > > 4. Retrieve any content needed for data collection. Configuration checks pertaining to a particular posture element may be used to support data collection. > > 5. Harvest the actual values pertaining to posture elements identified in step 3 from the endpoint. > > 6. Report collected endpoint posture as identified in step 2. This will likely be done on an individual basis for each identified endpoint, requiring aggregation of data collected from multiple endpoints as needed based on the identified policy. > > This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. > > Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis > - A standards-track document specifying a protocol and data format for collecting actual endpoint posture > > The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap (for example for the repository access protocol) and can be used or re-used to meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and thier configurations along with an understanding of layered defenses. Then, injecting known threat information with mitigation options assists the organization in turning detailed security decisions into business-relevant decisions. The MILE protocols, RID and ROLIE, enable the exchange of structured data and are designed to carry any structured format. While RID may be use d > in multiple sharing models and provides multiple communication flows (report, query, etc.) with the ability to enable peer-to-peer object level security, ROLIE provides a RESTful repository transport option with only the need for a browser on the client end, removing deployment barriers. > > After the work items in the current charter have been submitted to and approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis for consideration as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data format for collecting actual endpoint posture for consideration as standards-track RFC > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From Adam.Montville@cisecurity.org Mon Jun 3 14:14:50 2013 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 CE4A711E80F4 for ; Mon, 3 Jun 2013 14:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1RVRf2Fz8sE for ; Mon, 3 Jun 2013 14:14:35 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10]) by ietfa.amsl.com (Postfix) with ESMTP id A2EBD11E80EC for ; Mon, 3 Jun 2013 14:09:31 -0700 (PDT) Received: from [216.82.250.19:32262] by server-10.bemta-12.messagelabs.com id A2/51-24802-A060DA15; Mon, 03 Jun 2013 21:09:30 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-15.tower-87.messagelabs.com!1370293769!9821080!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 15557 invoked from network); 3 Jun 2013 21:09:30 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-15.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 3 Jun 2013 21:09:30 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%14]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 17:09:55 -0400 From: Adam Montville To: Gunnar Engelbach , "Adam W. Montville" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kkvZaA///AAfI= Date: Mon, 3 Jun 2013 21:09:06 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66EB472@CISEXCHANGE2.msisac.org.local> References: , <51AD032D.5030600@ThreatGuard.com> In-Reply-To: <51AD032D.5030600@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 21:14:50 -0000 We can fuss over quibbles any time! Just glad to rekindle the discussions= and keep them moving in a productive direction. ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Gunnar En= gelbach [Gunnar.Engelbach@ThreatGuard.com] Sent: Monday, June 03, 2013 2:04 PM To: Adam W. Montville Cc: sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text Adam, thanks for taking the time to put this together and get things rolling again. I do have some specific quibbles in this I'd like to fuss over, but don't have the time right at the moment -- hopefully by tomorrow, though. --gun On 6/2/2013 11:57 AM, Adam W. Montville wrote: > All: > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-sac= m/) and comments submitted in a variety of threads (http://www.ietf.org/ma= il-archive/web/sacm/current/threads.html) and put the following together. > > I would love to see a dramatic increase in SACM participation throughout= this month - especially relating to the charter, which should be our prim= ary focus at this point, and then limited to the first several milestones.= > > My concern is that SACM momentum is trailing off at a point when it need= s to be maintaining, if not increasing, from that level we saw at IETF 86.= > > The following is the modified charter text: > > Securing information and the systems that store, process, and transmit t= hat information is a challenging task for organizations of all sizes, and = many security practitioners spend much of their time on manual processes. = Standardized processes to collect, verify, and update security system conf= igurations would allow easier automation of the processes. Automating thes= e routine tasks would free security practitioners to focus on high priorit= y tasks, and should improve operators' ability to prioritize risk based on= timely information about threats and vulnerabilities. This working group = will define security automation protocols and data format standards in sup= port of information security processes and practices. These standards will= help security practitioners to be more effective by automating routine ta= sks related to client and server security, freeing them to focus on more a= dvanced tasks. The initial focus of this work is to address enterprise use= cases pertaining to the ass es > sment of endpoint posture (using the definitions of Endpoint and Postu= re from RFC 5209). > > The working group will, whenever reasonable and possible, reuse existing= protocols, mechanisms, information and data models. Of particular interes= t to this working group are existing industry standards, preferably IETF s= tandards, that could support automation of asset, change, configuration, a= nd vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This are= a of focus provides for necessary language and data format specifications.= > > 2. A set of standards for interacting with repositories of content relat= ed to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following general = steps: > > 1. Relevant endpoints are identified and classified based on the targets= of the policy/policies to be evaluated > > 2. For each endpoint, determine what elements of posture information to = collect based on the policy/policies to be evaluated > > 3. For each element of the endpoint posture data, identify the mechanism= for data collection and what content is needed, if any, to support data c= ollection > > 4. Retrieve any content needed for data collection. Configuration check= s pertaining to a particular posture element may be used to support data c= ollection. > > 5. Harvest the actual values pertaining to posture elements identified i= n step 3 from the endpoint. > > 6. Report collected endpoint posture as identified in step 2. This will= likely be done on an individual basis for each identified endpoint, requi= ring aggregation of data collected from multiple endpoints as needed based= on the identified policy. > > This approach to=20endpoint posture collection enables multiple policies= to be evaluated based on a single data collection activity. Policies will= be evaluated by comparing available endpoint posture data according to ru= les expressed in the policy. Typically, these rules will compare the actua= l value against an expected value or range for specific posture elements. = In some cases, the posture element may pertain to software installation st= ate, in which case the actual and expected values may be "installed" or "n= ot installed." Evaluation of multiple posture elements may be combined usi= ng Boolean logic. > > Repository protocols are needed to store, update, and retrieve configura= tion checks and other types of content required for posture assessment (se= e step 2 above). A content repository is expected to house specific versi= ons of checklists (i.e. benchmarks), may be required to satisfy different = use cases (i.e. a NEA-specific use vs. a generally applicable assessment u= sed during continuous monitoring). In addition, content repositories are = expected to store up-to-date dictionary of specific enumerations, such as = those used for configuration element identifiers, asset classifications, v= ulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for r= etrieving configuration and policy information for driving data collection= and analysis > - A standards-track document specifying a protocol and data format for c= ollecting actual endpoint posture > > The working group will create an overview of related standards work Inte= rnet-Draft which will document existing work in the IETF or in other SDOs = which can be used as-is or as a starting point for developing solutions to= the SACM requirements. The working group may decide to make of this docum= ent an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in the = IETF (including, but not limited to MILE and NEA) in order to create solut= ions that do not overlap (for example for the repository access protocol) = and can be used or re-used to meet the goals of more than one working grou= p. > > In accordance with existing IETF processes, the group will communicate w= ith and invite participation from other relevant standards bodies and regu= latory organizations, and if necessary reuse existing liaison relationship= s or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other IE= TF (and non-IETF) standardization efforts. There are common "problems" fo= und in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCON= F, SYSLOG, NEA, MILE, and potentially others. Of particular interest to S= ACM is understanding and respecting the distinctions between itself and NE= A and MILE. > > One way the NEA protocols can be used is as the transport for data colle= cted on the endpoint to an external service or data repository for further= analysis and action. NEA may also serve the purpose of carrying data-col= lection instructions. > > The MILE data formats provide a format to describe incident, threat-rela= ted incident, and indicator information. SACM data formats provide ways t= o understand what endpoints are in your environment, whether they meet pol= icy requirements, and their current configuration state. The data exchang= ed in MILE, supplementing the SACM data, creates enhanced situational awar= eness, thus enabling increased understanding of current threats and mitiga= tions. The combined SACM and MILE data sets become a powerful tool to aut= omate security with descriptions of endpoints, known vulnerabilities to th= ose endpoints, and thier configurations along with an understanding of lay= ered defenses. Then, injecting known threat information with mitigation o= ptions assists the organization in turning detailed security decisions int= o business-relevant decisions. The MILE protocols, RID and ROLIE, enable = the exchange of structured data and are designed to carry any structured f= ormat. While RID may be use d > in multiple sharing models and provides multiple communication flows (= report, query, etc.) with the ability to enable peer-to-peer object level = security, ROLIE provides a RESTful repository transport option with only t= he need for a browser on the client end, removing deployment barriers. > > After the work items in the current charter have been submitted to and a= pproved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements taki= ng into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture= > > Nov. 2013 - Initial submission of an Internet-Draft on overview of relat= ed standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata format for retrieving configuration and policy information for driving= data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases fo= r consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements= for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Archite= cture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol = and data format for retrieving configuration and policy information for dr= iving data collection and analysis for consideration as standards-track RF= C > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and = data format for collecting actual endpoint posture for consideration as st= andards-track RFC > > _______________________________________________ > 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 ... 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 david.waltermire@nist.gov Mon Jun 3 15:52:51 2013 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 09C4021F9635 for ; Mon, 3 Jun 2013 15:52:50 -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 vpOkhJmn7AJq for ; Mon, 3 Jun 2013 15:52:33 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 539D721F96E1 for ; Mon, 3 Jun 2013 15:49:07 -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.3.123.3; Mon, 3 Jun 2013 18:49:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 3 Jun 2013 18:49:06 -0400 From: "Waltermire, David A." To: Stephen Hanna , "Romascanu, Dan (Dan)" , "Adam W. Montville" , "sacm@ietf.org" Date: Mon, 3 Jun 2013 18:49:04 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n1sTB6NtW1w0unBSJfMGLGYpkj8NSAgAADXYCAAKB+cA== Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA17F243@AZ-FFEXMB04.global.avaya.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 Subject: Re: [sacm] Updated Candidate Charter Text 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, 03 Jun 2013 22:52:51 -0000 +1 on Steve's comments. +1 on reaffirming my commitment to this work and going forward. ;-) Some minor concerns with the current draft: "A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring)" The dimension of using content to satisfy different use cases is important, but the examples are not what I would expect. "NEA-specific use" I would interpret as intending to mean network access control. The NEA specifications are not prescriptive in this regard. They can be used for general data collection, continuous monitoring, and for network access control decisions. I recommend either striking the (i.e.) examples, or using (e.g., software inventory, configuration settings, vulnerabilities) or something similar to illustrate different assessment use cases. "in order to create solutions that do not overlap (for example for the repository access protocol)" While the non-parenthetical text is a valid concern that should be addressed in the charter, the example text here assumes a potential solution. It is a reference to MILE's ROLIE which is a profile of the ATOM publishing protocol. The charter should not assume any specific solution. Any decision to reuse ROLIE, to develop a different profile of ATOM publishing, or to pursue a different approach altogether is a decision we need to work out down the road once we have a better handle on the use cases, requirements, and architectural considerations. An example concern we may consider at that time is that ROLIE requires the use of IODEF as mandatory-to-implement (MTI). While this MTI may be good for incident data exchange related implementations, we are not ready at this time to consider if this MTI is a good thing or a barrier to adoption for endpoint assessment or continuous monitoring implementations. IMHO the example should be removed from the charter, since the text outside the parenthetical addresses the general concern anyway. The MILE text later in the charter lays out the use of ROLIE as a consideration which is the better way to address it. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Monday, June 03, 2013 9:03 AM > To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text > > Yes, I believe this text addresses the questions asked and is ready for > submission to the IESG. > > I did notice what I believe are two typos: > > * In this sentence, I think "may be" should be "which > may be": > > > A content repository is expected to house specific versions of > > checklists (i.e. benchmarks), may be required to satisfy different use > > cases (i.e. a NEA-specific use vs. a generally applicable assessment > > used during continuous monitoring). > > * In this sentence, I think the word "an" should appear > before "up-to-date": > > > In addition, content repositories are expected to store up-to-date > > dictionary of specific enumerations, such as those used for > > configuration element identifiers, asset classifications, > > vulnerability identifiers, and so on. > > With those two fixes (or without them, even!), I think this charter is ready to > go. > > I apologize for being quiet recently. As Mike said, things seemed to be going > so smoothly here. I didn't realize that a nudge of support was needed. > > I am happy to confirm that I'm still committed to doing the SACM work, as > agreed in the BOF sessions. > And I agree with this charter and scope. > > Thanks, > > Steve > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Romascanu, Dan (Dan) > > Sent: Monday, June 03, 2013 8:44 AM > > To: Adam W. Montville; sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > Hi, > > > > Thanks to Adam for this revision. > > > > Can we have a show of hands about this version of the charter text: > > > > > > - does it clarify in a satisfactory manner the questions asked on the > > list and especially the ones asked by our AD? > > - does it reflect the consensus of the mail list on the scope of the > > first phase of the proposed WG? > > - is it good enough to be submitted to the IESG for discussions on the > > formation of the WG? > > > > All answers welcome. Any answer different than 'yes' should be > > accompanied by concrete comments on issues that still need > > clarification, and items we still need to work for consensus. > > > > Thanks and Regards, > > > > Dan > > > > > > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > Of > > > Adam W. Montville > > > Sent: Sunday, June 02, 2013 6:57 PM > > > To: sacm@ietf.org > > > Subject: [sacm] Updated Candidate Charter Text > > > Importance: High > > > > > > All: > > > > > > I've taken the charter > > > (http://datatracker.ietf.org/doc/charter-ietf- > > > sacm/) and comments submitted in a variety of threads > > > (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and > > put > > > the following together. > > > > > > I would love to see a dramatic increase in SACM participation > > throughout > > > this month - especially relating to the charter, which should be our > > > primary focus at this point, and then limited to the first several > > > milestones. > > > > > > My concern is that SACM momentum is trailing off at a point when it > > > needs to be maintaining, if not increasing, from that level we saw > > > at IETF 86. > > > > > > The following is the modified charter text: > > > > > > Securing information and the systems that store, process, and > > transmit > > > that information is a challenging task for organizations of all > > sizes, > > > and many security practitioners spend much of their time on manual > > > processes. Standardized processes to collect, verify, and update > > > security system configurations would allow easier automation of the > > > processes. Automating these routine tasks would free security > > > practitioners to focus on high priority tasks, and should improve > > > operators' ability to prioritize risk based on timely information > > about > > > threats and vulnerabilities. This working group will define security > > > automation protocols and data format standards in support of > > information > > > security processes and practices. These standards will help security > > > practitioners to be more effective by automating routine tasks > > related > > > to client and server security, freeing them to focus on more > > > advanced tasks. The initial focus of this work is to address > > > enterprise use > > cases > > > pertaining to the asses sment of endpoint posture (using the > > > definitions of Endpoint and Posture from RFC 5209). > > > > > > The working group will, whenever reasonable and possible, reuse > > existing > > > protocols, mechanisms, information and data models. Of particular > > > interest to this working group are existing industry standards, > > > preferably IETF standards, that could support automation of asset, > > > change, configuration, and vulnerability management. > > > > > > The working group will define: > > > > > > 1. A set of standards to enable assessment of endpoint posture. This > > > area of focus provides for necessary language and data format > > > specifications. > > > > > > 2. A set of standards for interacting with repositories of content > > > related to assessment of endpoint posture. > > > > > > Assessment of endpoint posture assessment entails the following > > general > > > steps: > > > > > > 1. Relevant endpoints are identified and classified based on the > > targets > > > of the policy/policies to be evaluated > > > > > > 2. For each endpoint, determine what elements of posture information > > to > > > collect based on the policy/policies to be evaluated > > > > > > 3. For each element of the endpoint posture data, identify the > > mechanism > > > for data collection and what content is needed, if any, to support > > data > > > collection > > > > > > 4. Retrieve any content needed for data collection. Configuration > > > checks pertaining to a particular posture element may be used to > > support > > > data collection. > > > > > > 5. Harvest the actual values pertaining to posture elements > > identified > > > in step 3 from the endpoint. > > > > > > 6. Report collected endpoint posture as identified in step 2. This > > will > > > likely be done on an individual basis for each identified endpoint, > > > requiring aggregation of data collected from multiple endpoints as > > > needed based on the identified policy. > > > > > > This approach to endpoint posture collection enables multiple > > policies > > > to be evaluated based on a single data collection activity. Policies > > > will be evaluated by comparing available endpoint posture data > > according > > > to rules expressed in the policy. Typically, these rules will > > > compare the actual value against an expected value or range for > > > specific > > posture > > > elements. In some cases, the posture element may pertain to software > > > installation state, in which case the actual and expected values may > > be > > > "installed" or "not installed." Evaluation of multiple posture > > elements > > > may be combined using Boolean logic. > > > > > > Repository protocols are needed to store, update, and retrieve > > > configuration checks and other types of content required for posture > > > assessment (see step 2 above). A content repository is expected to > > > house specific versions of checklists (i.e. benchmarks), may be > > required > > > to satisfy different use cases (i.e. a NEA-specific use vs. a > > generally > > > applicable assessment used during continuous monitoring). In > > addition, > > > content repositories are expected to store up-to-date dictionary of > > > specific enumerations, such as those used for configuration element > > > identifiers, asset classifications, vulnerability identifiers, and > > > so on. > > > > > > This working group will achieve the following deliverables: > > > > > > - An Informational document on Use Cases > > > - An Informational document on Requirements > > > - An Informational document on SACM Architecture > > > - A standards-track document specifying a protocol and data format > > for > > > retrieving configuration and policy information for driving data > > > collection and analysis > > > - A standards-track document specifying a protocol and data format > > for > > > collecting actual endpoint posture > > > > > > The working group will create an overview of related standards work > > > Internet-Draft which will document existing work in the IETF or in > > other > > > SDOs which can be used as-is or as a starting point for developing > > > solutions to the SACM requirements. The working group may decide to > > make > > > of this document an Informational RFC, but this is not a mandatory > > > deliverable. > > > > > > The working group will work in close coordination with other WGs in > > the > > > IETF (including, but not limited to MILE and NEA) in order to create > > > solutions that do not overlap (for example for the repository access > > > protocol) and can be used or re-used to meet the goals of more than > > one > > > working group. > > > > > > In accordance with existing IETF processes, the group will > > communicate > > > with and invite participation from other relevant standards bodies > > and > > > regulatory organizations, and if necessary reuse existing liaison > > > relationships or request the establishment of new liaison > > relationships. > > > > > > SACM-related efforts are largely aligned, and may overlap, with > > > other IETF (and non-IETF) standardization efforts. There are common > > > "problems" found in SACM, that may be addressed by the work done in > > > SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > > > particular interest to SACM is understanding and respecting the > > > distinctions between itself and NEA and MILE. > > > > > > One way the NEA protocols can be used is as the transport for data > > > collected on the endpoint to an external service or data repository > > for > > > further analysis and action. NEA may also serve the purpose of > > carrying > > > data-collection instructions. > > > > > > The MILE data formats provide a format to describe incident, threat- > > > related incident, and indicator information. SACM data formats > > provide > > > ways to understand what endpoints are in your environment, whether > > they > > > meet policy requirements, and their current configuration state. > > > The data exchanged in MILE, supplementing the SACM data, creates > > > enhanced situational awareness, thus enabling increased > > > understanding of > > current > > > threats and mitigations. The combined SACM and MILE data sets > > > become > > a > > > powerful tool to automate security with descriptions of endpoints, > > known > > > vulnerabilities to those endpoints, and thier configurations along > > with > > > an understanding of layered defenses. Then, injecting known threat > > > information with mitigation options assists the organization in > > turning > > > detailed security decisions into business-relevant decisions. The > > MILE > > > protocols, RID and ROLIE, enable the exchange of structured data and > > are > > > designed to carry any structured format. While RID may be used in > > > multiple sharing models and provides multiple communication flows > > > (report, query, etc.) with the ability to enable peer-to-peer object > > > level security, ROLIE provides a RESTful repository transport option > > > with only the need for a browser on the client end, removing > > deployment > > > barriers. > > > > > > After the work items in the current charter have been submitted to > > and > > > approved by the IESG, the WG will recharter or close. > > > > > > Goals and Milestones > > > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > > taking into consideration RFC5706 and RFC3535 > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > Architecture > > > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > > related standards work > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > and > > > data format for retrieving configuration and policy information for > > > driving data collection and analysis > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > and > > > data format for collecting actual endpoint posture > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > > > Cases for consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > Requirements > > > for consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > > Architecture for consideration as Informational RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > protocol > > > and data format for retrieving configuration and policy information > > for > > > driving data collection and analysis for consideration as standards- > > > track RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > and > > > data format for collecting actual endpoint posture for consideration > > as > > > standards-track RFC > > > > > > _______________________________________________ > > > 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 dbharrington@comcast.net Fri May 31 15:49:44 2013 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 B5BCD21F854E for ; Fri, 31 May 2013 15:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.248 X-Spam-Level: * X-Spam-Status: No, score=1.248 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 e+ztX8lT00UY for ; Fri, 31 May 2013 15:49:37 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6021F8FE8 for ; Fri, 31 May 2013 15:32:54 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id ih9R1l0020xGWP855mYWh6; Fri, 31 May 2013 22:32:30 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta12.westchester.pa.mail.comcast.net with comcast id imYW1l00V2yZEBF3YmYWhU; Fri, 31 May 2013 22:32:30 +0000 From: "David Harrington" To: Date: Fri, 31 May 2013 18:32:14 -0400 Message-ID: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5eSUH6AbcnKB9yT0eGS0vpD1wP0A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370039550; bh=kDzrqzSBwOil/+zzt4F/lwup+e/e52zoE+JGWR64+gI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=czN3B2UVyTRIN11Dzi/NjzBrKPT+sOvVEFAcOgh5PobSwljOubUeVW7FEfr2ZLSk/ tIq78E5w5QiUv2xLRQIxqkcCT/87BjfcqoovtBhqIjCMoYcTDZ68QkqX+1WXHgYBCO 9CUhCYXKBK3Ee5WpniBuMgO5rphe+FElnQsJ6eMBeSJWnenKzIA+5CvWY0quQPpVFK d8VFEY/Iomgdw0lQWVPX34BdDD059XoTZ7o1Utg9tt0jsTStzkTrUY3Ox0y4U8iR5q IEEPoHqa/Aag+x7uMLwTXYuAnj5z4g8dHrrRo/CDJhL9p+e+hVIpyYNlhxfhcSOTM6 EtziWvQgILMQw== X-Mailman-Approved-At: Mon, 03 Jun 2013 15:54:28 -0700 Subject: [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: Fri, 31 May 2013 22:49:45 -0000 Hi, I read through the use cases document last night. The current document sounds like pure marketing, with lots of promises of the wonderful world that will exist once we finish defining this new architecture and standards. Lots of people new to IETF make this mistake. This is the Internet ENGINEERING Task Force. We prefer engineering documents to marketing documents. To that end, let me make some comments and suggestions. Some SDOs work top-down; they design a pretty architecture and then try to populate it with protocols and data models, and so on. This is consistent with the way many proprietary engineering departments work. Historically, the IETF works bottom-up. A problem exists in the real world; multiple vendors solve it using proprietary approaches. Then the problem becomes more or less a solved problem that is not solved in a standardized manner. A lack of interoperability becomes the problem. That's when the IETF comes into play - helping the community establish a multi-vendor interoperable standard to help solve the original problem in an interoperable manner. The IETF approach is historically built on field-tested solutions, which then get standardized. Interoperability problems frequently are an aggregation of problems. Typically, the IETF focuses on standardizing details, like specific protocols or specific data models, based on uses that already exist in the real world. Of course, with multiple contributors involved, the final result is usually changed quite a bit form the original because different segments of the community need to USE the technologies in different ways, often to add value to their products or services. The security automation use cases document would greatly benefit from content that describes how security automation is currently being USED in the real world, using proprietary solutions - the "use cases". >From that, we can try to extract the common functionality and work to establish vendor-neutral, interoperable engineered standards, such as protocols and data models. Are there users of security automation subscribed to this list? If so, how are they using their automation? Who is the customer? What technical decisions have worked well; which have been problematic? I think the use cases document should help to identify users (e.g., vendors, services, operators) whose products/services utilize security automation. We should try to get vendors to participate in building these standards, since they are the ones who will use them to build products. We should try to get operators to participate in building these standards, because they are the people who will configure and maintain the networks that use security automation. The use cases document doesn't represent the users of proprietary solutions that we propose to improve through standardization. The use cases document doesn't represent the expected users of the standards we propose to build (our customers). I think it should. David Harrington dbharrington@comcast.net +1-603-828-1401 From ietf-secretariat-reply@ietf.org Mon Jun 3 07:29:11 2013 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 E16A321F99BE for ; Mon, 3 Jun 2013 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZbeQTNH6x600 for ; Mon, 3 Jun 2013 07:29:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEBA21F99CB for ; Mon, 3 Jun 2013 07:29:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: sacm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603142911.384.77326.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 07:29:11 -0700 From: IETF Secretariat X-Mailman-Approved-At: Mon, 03 Jun 2013 15:54:28 -0700 Subject: [sacm] Milestones changed for sacm WG 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, 03 Jun 2013 14:29:12 -0000 Changed milestone "Initial submission of an Internet-Draft on Requirements", set description to "Initial submission of an Internet-Draft on Requirements taking into consideration RFC5706 and RFC3535". URL: http://datatracker.ietf.org/wg/sacm/charter/ From david.waltermire@nist.gov Mon Jun 3 16:00:53 2013 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 B6BD611E80D5 for ; Mon, 3 Jun 2013 16:00:53 -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 R5bepq3dZXiC for ; Mon, 3 Jun 2013 16:00:29 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B1DBB21F90CD for ; Mon, 3 Jun 2013 16:00:08 -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.3.123.3; Mon, 3 Jun 2013 18:59:51 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 3 Jun 2013 19:00:04 -0400 From: "Waltermire, David A." To: David Harrington , "sacm@ietf.org" Date: Mon, 3 Jun 2013 19:00:03 -0400 Thread-Topic: [sacm] use case document Thread-Index: Ac5eSUH6AbcnKB9yT0eGS0vpD1wP0ACZETYg Message-ID: References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> In-Reply-To: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [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: Mon, 03 Jun 2013 23:00:53 -0000 Great points and good questions. Would you be interested in working as an editor of the current use cases draft to drive it forward while addressing your concerns? Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > David Harrington > Sent: Friday, May 31, 2013 6:32 PM > To: sacm@ietf.org > Subject: [sacm] use case document > > Hi, > > I read through the use cases document last night. > The current document sounds like pure marketing, with lots of promises of > the wonderful world that will exist once we finish defining this new > architecture and standards. > Lots of people new to IETF make this mistake. > This is the Internet ENGINEERING Task Force. We prefer engineering > documents to marketing documents. > > To that end, let me make some comments and suggestions. > Some SDOs work top-down; they design a pretty architecture and then try to > populate it with protocols and data models, and so on. > This is consistent with the way many proprietary engineering departments > work. > Historically, the IETF works bottom-up. > A problem exists in the real world; multiple vendors solve it using proprietary > approaches. > Then the problem becomes more or less a solved problem that is not solved > in a standardized manner. > A lack of interoperability becomes the problem. > That's when the IETF comes into play - helping the community establish a > multi-vendor interoperable standard to help solve the original problem in an > interoperable manner. > The IETF approach is historically built on field-tested solutions, which then get > standardized. > Interoperability problems frequently are an aggregation of problems. > Typically, the IETF focuses on standardizing details, like specific protocols or > specific data models, based on uses that already exist in the real world. > Of course, with multiple contributors involved, the final result is usually > changed quite a bit form the original because different segments of the > community need to USE the technologies in different ways, often to add > value to their products or services. > > > The security automation use cases document would greatly benefit from > content that describes how security automation is currently being USED in > the real world, using proprietary solutions - the "use cases". > From that, we can try to extract the common functionality and work to > establish vendor-neutral, interoperable engineered standards, such as > protocols and data models. > > Are there users of security automation subscribed to this list? > If so, how are they using their automation? Who is the customer? > What technical decisions have worked well; which have been problematic? > > I think the use cases document should help to identify users (e.g., vendors, > services, operators) whose products/services utilize security automation. > We should try to get vendors to participate in building these standards, since > they are the ones who will use them to build products. > We should try to get operators to participate in building these standards, > because they are the people who will configure and maintain the networks > that use security automation. > The use cases document doesn't represent the users of proprietary solutions > that we propose to improve through standardization. > The use cases document doesn't represent the expected users of the > standards we propose to build (our customers). > > I think it should. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From ietfdbh@comcast.net Mon Jun 3 17:22:11 2013 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 D66E921E80E0 for ; Mon, 3 Jun 2013 17:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.137 X-Spam-Level: X-Spam-Status: No, score=-99.137 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 nfDq684ZTNgL for ; Mon, 3 Jun 2013 17:21:57 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 9990921F96DE for ; Mon, 3 Jun 2013 17:01:46 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id jzXl1l0010EZKEL5B01mZk; Tue, 04 Jun 2013 00:01:46 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta01.westchester.pa.mail.comcast.net with comcast id k01l1l0152yZEBF3M01lzi; Tue, 04 Jun 2013 00:01:45 +0000 From: "ietfdbh" To: "'Waltermire, David A.'" , "'David Harrington'" , References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> In-Reply-To: Date: Mon, 3 Jun 2013 20:01:25 -0400 Message-ID: <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEMdLuegdeWdCbFCE+YTD19zbEQBQB+8R1tmqSLVAA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370304106; bh=l6wKrgPcll9UvMBxylzh9/R/EPMadhofv9ma7dweUn0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=MxHDZRRKVDEJSF5ZS/GqJPL9jt7725+BsvZxU/NtaKKpMDGFiw/W8FWbRTlaz9U6j uJ5tybCfNwlLvQlJ8PPhgu8LlyyvyEXiruQfvQykr8R8ZFPmFXuo9xl4X4pHW3SDpg CS+QnncDjhFDbBLoJstElSyphV4BHzIB4HUGGA/2N3VxOHRJ17f0Vd4uTsqB6Fmztj 0urKAmSxztyoQA+ZBogCOh/gGyTMK8Vy9kLK8ZF+xGFIxpSgGcUUuIS7lpcLfXTGq5 yFO8vOyYNdT2fBTikx313RJY9ZzbY4ret5WH/7QjfLMwwsI/K22IFiaEtwbCYR+pSW xsbXciktMkaxA== Subject: Re: [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, 04 Jun 2013 00:22:12 -0000 I have no objection to helping edit the draft. However, the main failing of the draft in my eyes is that it doesn't really contain use cases. I am not active in the industry we are targeting, so we would need some input on use cases from operators, security admins, vendors, etc. who are. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, June 03, 2013 7:00 PM To: David Harrington; sacm@ietf.org Subject: Re: [sacm] use case document Great points and good questions. Would you be interested in working as an editor of the current use cases draft to drive it forward while addressing your concerns? Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of David Harrington > Sent: Friday, May 31, 2013 6:32 PM > To: sacm@ietf.org > Subject: [sacm] use case document > > Hi, > > I read through the use cases document last night. > The current document sounds like pure marketing, with lots of promises > of the wonderful world that will exist once we finish defining this > new architecture and standards. > Lots of people new to IETF make this mistake. > This is the Internet ENGINEERING Task Force. We prefer engineering > documents to marketing documents. > > To that end, let me make some comments and suggestions. > Some SDOs work top-down; they design a pretty architecture and then > try to populate it with protocols and data models, and so on. > This is consistent with the way many proprietary engineering > departments work. > Historically, the IETF works bottom-up. > A problem exists in the real world; multiple vendors solve it using > proprietary approaches. > Then the problem becomes more or less a solved problem that is not > solved in a standardized manner. > A lack of interoperability becomes the problem. > That's when the IETF comes into play - helping the community establish > a multi-vendor interoperable standard to help solve the original > problem in an interoperable manner. > The IETF approach is historically built on field-tested solutions, > which then get standardized. > Interoperability problems frequently are an aggregation of problems. > Typically, the IETF focuses on standardizing details, like specific > protocols or specific data models, based on uses that already exist in the real world. > Of course, with multiple contributors involved, the final result is > usually changed quite a bit form the original because different > segments of the community need to USE the technologies in different > ways, often to add value to their products or services. > > > The security automation use cases document would greatly benefit from > content that describes how security automation is currently being USED > in the real world, using proprietary solutions - the "use cases". > From that, we can try to extract the common functionality and work to > establish vendor-neutral, interoperable engineered standards, such as > protocols and data models. > > Are there users of security automation subscribed to this list? > If so, how are they using their automation? Who is the customer? > What technical decisions have worked well; which have been problematic? > > I think the use cases document should help to identify users (e.g., > vendors, services, operators) whose products/services utilize security automation. > We should try to get vendors to participate in building these > standards, since they are the ones who will use them to build products. > We should try to get operators to participate in building these > standards, because they are the people who will configure and maintain > the networks that use security automation. > The use cases document doesn't represent the users of proprietary > solutions that we propose to improve through standardization. > The use cases document doesn't represent the expected users of the > standards we propose to build (our customers). > > I think it should. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > _______________________________________________ > 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 dromasca@avaya.com Tue Jun 4 02:55:22 2013 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 C70CE21F9927 for ; Tue, 4 Jun 2013 02:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Z5+PkdrKNhBK for ; Tue, 4 Jun 2013 02:55:08 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8610521F9B34 for ; Tue, 4 Jun 2013 01:48:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADyprVHGmAcF/2dsb2JhbABWA4JoITC/CYECFnSCIwEBAQECAQEBAQ8oMQMQBwQCAQgNAQMEAQELFAkHJwsUCQgBAQQBEggMDodZAwkGAQugIZNiCIh6EwSNdIEBIRcGC4JmYQOdf4p/gw+BcTY X-IronPort-AV: E=Sophos;i="4.87,798,1363147200"; d="scan'208";a="14594575" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Jun 2013 04:48:02 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jun 2013 04:46:48 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 10:47:30 +0200 From: "Romascanu, Dan (Dan)" To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] sacm participation and scope Thread-Index: Ac5gfiXGmRzO8GHaRlCNV4DkFY3EPgAf9MOQ Date: Tue, 4 Jun 2013 08:47:29 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1810E5@AZ-FFEXMB04.global.avaya.com> References: <009701ce607e$a3274a50$e975def0$@comcast.net> In-Reply-To: <009701ce607e$a3274a50$e975def0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] sacm participation and scope 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, 04 Jun 2013 09:55:22 -0000 Hi David, See in-line.=20 Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > David Harrington > Sent: Monday, June 03, 2013 8:20 PM > To: sacm@ietf.org > Subject: [sacm] sacm participation and scope >=20 > Hi, >=20 > There appear to be about 6 people active on the ML: 2 authors discussing > their drafts, 2 chairs acting administratively (but not much technical > discussion), one contributor who chairs a related WG, and myself. >=20 > That wouldn't pass my AD test that there needs to be a significant > community that believes there is a problem that needs solving. I would say that the participation in the charter discussions is not the on= ly indicator about the willingness of the community to participate in this = work.=20 At the second SACM BOF at IETF-86 we explicitly asked:=20 ------------ B. Indicate your intent to actively contribute to this work in IETF. (yes, no, no opinion) Dan asked for a show of hands on this, explaining that he means to include writing documents, writing code, participating in prototyping, proof of concept, interoperability testing, providing comments and reviews that will help progress the documents, and any combination of those. There were 12 hands for yes and 1 in Jabber. -------------- I would also note that part of the participants in SACM are new to the IETF= , and less experienced with the IETF process and use of the mail list. > Where are the representatives from the Security area? Where are the > IPsec and TLS and SSH and Kerberos and PKI WG experts? > Where are the representatives from the Security products industry? Where > are the firewall and IDS and DPI vendor experts? > Where are the representatives from the OPS(NM) area? Where are the > Netconf, ipfix, syslog, snmp guys? (well, I guess you can count me but > that's not many). > Where are the representatives from the AAA community? Radius? Diameter? > Where are the representatives from the config automation community? > DHCP, NACP, homenet, Where are the representatives from the OPS(OPS) > area? Where are the operators, and the enterprise/ISP security admins? > Opsec? V6ops? > Where are the representatives from the OPS(OPS) area? Where are the > websec and https guys? Where are the server guys? >=20 [[DR]] Some of the config automation community are present and authored I-D= s. There is some participation from the OPS area if we count the two of us.= A few operators attended the BOF meetings. Concerning specific WGs - RADIU= S, Diameter, OPSEC, v6OPS, homenet, etc - do we need their participation? O= r coordination later, if and when the WG is formed.=20 =20 > I am concerned that the work being done so far is 30,000-foot stuff, > with no details. > I don't know from the charter just what security we plan to automate. > I see discussions of the need for protocols and data models, but almost > no details of what specific information needs to be modeled, or the > properties of the protocols needed to transport that data, or what's > going to be done with the data. > I think our discussions are so high-level that people from other WGs > cannot tell if there is anything relevant to them in this proposed WG. >=20 > I don't think we're ready for a WG. > I think we need a much more narrow and clearly-defined scope in the > charter. >=20 [[DR]] better focus is always welcome - do you have proposals?=20 > My $.02 >=20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Tue Jun 4 07:58:43 2013 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 5B5F221F99F3 for ; Tue, 4 Jun 2013 07:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.086 X-Spam-Level: X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=0.179, 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 xneoJL3GnWs1 for ; Tue, 4 Jun 2013 07:58:29 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.206.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8413621F9B92 for ; Tue, 4 Jun 2013 06:11:52 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id C34563F4FD542; Tue, 4 Jun 2013 08:11:28 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id B3E623F4FD515 for ; Tue, 4 Jun 2013 08:11:28 -0500 (CDT) Received: from [173.73.135.101] (port=55012 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ujr1j-0002pj-Oy; Tue, 04 Jun 2013 08:11:51 -0500 Message-ID: <51ADE797.70900@ieca.com> Date: Tue, 04 Jun 2013 09:11:51 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Adam W. Montville" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:55012 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 04 Jun 2013 14:58:43 -0000 Adam, Thanks for driving this forward. This looks a lot better to me. Hopefully Gunnar can get his comments in soon and we we can see where we stand then. spt On 6/2/13 11:57 AM, Adam W. Montville wrote: > All: > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments submitted in a variety of threads (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put the following together. > > I would love to see a dramatic increase in SACM participation throughout this month - especially relating to the charter, which should be our primary focus at this point, and then limited to the first several milestones. > > My concern is that SACM momentum is trailing off at a point when it needs to be maintaining, if not increasing, from that level we saw at IETF 86. > > The following is the modified charter text: > > Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized processes to collect, verify, and update security system configurations would allow easier automation of the processes. Automating these routine tasks would free security practitioners to focus on high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. This working group will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security, freeing them to focus on more advanced tasks. The initial focus of this work is to address enterprise use cases pertaining to the ass es > sment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following general steps: > > 1. Relevant endpoints are identified and classified based on the targets of the policy/policies to be evaluated > > 2. For each endpoint, determine what elements of posture information to collect based on the policy/policies to be evaluated > > 3. For each element of the endpoint posture data, identify the mechanism for data collection and what content is needed, if any, to support data collection > > 4. Retrieve any content needed for data collection. Configuration checks pertaining to a particular posture element may be used to support data collection. > > 5. Harvest the actual values pertaining to posture elements identified in step 3 from the endpoint. > > 6. Report collected endpoint posture as identified in step 2. This will likely be done on an individual basis for each identified endpoint, requiring aggregation of data collected from multiple endpoints as needed based on the identified policy. > > This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. > > Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis > - A standards-track document specifying a protocol and data format for collecting actual endpoint posture > > The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap (for example for the repository access protocol) and can be used or re-used to meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and thier configurations along with an understanding of layered defenses. Then, injecting known threat information with mitigation options assists the organization in turning detailed security decisions into business-relevant decisions. The MILE protocols, RID and ROLIE, enable the exchange of structured data and are designed to carry any structured format. While RID may be use d > in multiple sharing models and provides multiple communication flows (report, query, etc.) with the ability to enable peer-to-peer object level security, ROLIE provides a RESTful repository transport option with only the need for a browser on the client end, removing deployment barriers. > > After the work items in the current charter have been submitted to and approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis for consideration as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data format for collecting actual endpoint posture for consideration as standards-track RFC > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From trutkowski@netmagic.com Tue Jun 4 00:01:37 2013 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 55AD121F9A79 for ; Tue, 4 Jun 2013 00:01:37 -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 hLnZ6OcwjEme for ; Tue, 4 Jun 2013 00:01:22 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5202C21F9A13 for ; Mon, 3 Jun 2013 23:03:44 -0700 (PDT) Received: from [192.168.0.89] ([unknown] [85.13.127.120]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MNU00BW7U5BFF20@vms173017.mailsrvcs.net> for sacm@ietf.org; Tue, 04 Jun 2013 01:03:13 -0500 (CDT) Message-id: <51AD831E.8000100@netmagic.com> Date: Tue, 04 Jun 2013 08:03:10 +0200 From: Tony Rutkowski Organization: NetMagic Associates User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-version: 1.0 To: ietfdbh References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> In-reply-to: <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 04 Jun 2013 08:05:14 -0700 Cc: 'David Harrington' , "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [sacm] use case document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trutkowski@netmagic.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: Tue, 04 Jun 2013 07:01:37 -0000 You can get many at least one set of use cases from the SECAM working group in 3GPP SA3 - which is very active doing much the same things as are occurring in SACM. Ditto for the ISI group in ETSI. SACM can improve its effectiveness by proactively engaging the multiple other similar groups out there. --tony On 2013-06-04 2:01 AM, ietfdbh wrote: > I have no objection to helping edit the draft. > However, the main failing of the draft in my eyes is that it doesn't really > contain use cases. > I am not active in the industry we are targeting, so we would need some > input on use cases from operators, security admins, vendors, etc. who are. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > From gunnar.engelbach@threatguard.com Tue Jun 4 11:07:26 2013 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 7809421F9C31 for ; Tue, 4 Jun 2013 11:07:26 -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 l6tJRnAcUdqM for ; Tue, 4 Jun 2013 11:07:21 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id E36CB21F9A8C for ; Tue, 4 Jun 2013 10:19:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=ZDOi1SLcQeI8QPAf0fVRR8vYutaesX+x0gD8nR/8yzOZgbFUtKyrgYe9vxDbPD/BJ5fi4GmA4qyMeurm+CfBzr1zwCHsAyLna9vhxNt0MdSSF27mFi7sBn++dQXmLqUM; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 17497 invoked from network); 4 Jun 2013 10:31:05 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Jun 2013 10:31:04 -0700 Message-ID: <51AE21AB.4060209@ThreatGuard.com> Date: Tue, 04 Jun 2013 13:19:39 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Adam W. Montville" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 04 Jun 2013 18:07:26 -0000 My primary quibbles are below, but I'd like to start by highlighting something Stephen Whitlock said: "...deviations from standard configurations (whether by accident or intent) would result in a notification..." Going back to Dave Waltermire's proposed architecture, it included change notification originating from endpoints which helps feed Stephen's ideal, and I don't see an allowance for that in this revision. Real time compliance/vulnerability notification originating from endpoint events is a desirable security goal that I think falls within the scope of this WG. There is also a significant lag between the formation of a new WG and the delivery of usable products. So, while top-down assessments, seems to be plenty for this WG to gnaw on at the moment, I'd like to also keep bottom-up in mind so that any work done now doesn't preclude that as a follow-on. And, preferably, makes it possible to quickly add that next. There also seems to be a chicken-and-egg type of thing of selection of policy versus selection of assets as the starting point. I think both are valid so I tried, clumsily, to address that in my revision of the assessment steps, to follow. ---------------------------+++++++++++++--------------------------- The components, protocols, and content documents defined by this working group can be used in multiple ways such as top-down assessment of policy compliance, notification of compliance posture change initiated by a change made on an endpoint, determination of affected assets based on reportage of a new vulnerability, ad-hoc queries of specific asset settings, etc. The initial focus of this working group is the performance of top-down policy assessments using the following steps: A policy-driven assessment: A) The content repository is queried for the content documents that codify the policy/policies of interest. B) Assets are selected that match the criteria of the selected policy/policies. The method of selection can include enumeration from known asset inventories, direct query of known assets, network discovery, etc. Selection of assets may be further refined by other criteria such as ownership, location, role, time of day, etc. (Note: I used the term "asset" instead of "endpoint" because it includes software assets, allowing for assessments of, for example, web servers, virtual machine instance settings, a virtualized database instance running on a cluster, etc) Alternatively, and asset-driven assessment: A) Assets are selected based on a set of criteria (ownership, location, role, time of day, etc.). B) For each asset, determine and retrieve the applicable policy/policies from the content repository. For each asset: 1) Determine what elements of posture information to collect based on the policy/policies to be evaluated. 2) For each element of the asset posture data, identify the mechanism for data collection and what content is needed, if any, to support data collection. (Note: I assume this means if the collection is via direct endpoint query, CMDB retrieval, etc. That means a layer of meta data is needed that we haven't really talked about: authentication information, DB host/port, connection type, etc. Since this is an explicit step in the process, should that data also be part of the standard?) 3) Harvest the actual values pertaining to posture elements identified in step 3 from the targeted asset(s). 4) Report collected asset posture. This will likely be done on an individual basis for each identified asset , requiring aggregation of data collected from multiple asset as needed based on the identified policy. On 6/2/2013 11:57 AM, Adam W. Montville wrote: > All: > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments submitted in a variety of threads (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put the following together. > > I would love to see a dramatic increase in SACM participation throughout this month - especially relating to the charter, which should be our primary focus at this point, and then limited to the first several milestones. > > My concern is that SACM momentum is trailing off at a point when it needs to be maintaining, if not increasing, from that level we saw at IETF 86. > > The following is the modified charter text: > > Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized processes to collect, verify, and update security system configurations would allow easier automation of the processes. Automating these routine tasks would free security practitioners to focus on high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. This working group will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security, freeing them to focus on more advanced tasks. The initial focus of this work is to address enterprise use cases pertaining to the ass es > sment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following general steps: > > 1. Relevant endpoints are identified and classified based on the targets of the policy/policies to be evaluated > > 2. For each endpoint, determine what elements of posture information to collect based on the policy/policies to be evaluated > > 3. For each element of the endpoint posture data, identify the mechanism for data collection and what content is needed, if any, to support data collection > > 4. Retrieve any content needed for data collection. Configuration checks pertaining to a particular posture element may be used to support data collection. > > 5. Harvest the actual values pertaining to posture elements identified in step 3 from the endpoint. > > 6. Report collected endpoint posture as identified in step 2. This will likely be done on an individual basis for each identified endpoint, requiring aggregation of data collected from multiple endpoints as needed based on the identified policy. > > This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. > > Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis > - A standards-track document specifying a protocol and data format for collecting actual endpoint posture > > The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap (for example for the repository access protocol) and can be used or re-used to meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and thier configurations along with an understanding of layered defenses. Then, injecting known threat information with mitigation options assists the organization in turning detailed security decisions into business-relevant decisions. The MILE protocols, RID and ROLIE, enable the exchange of structured data and are designed to carry any structured format. While RID may be use d > in multiple sharing models and provides multiple communication flows (report, query, etc.) with the ability to enable peer-to-peer object level security, ROLIE provides a RESTful repository transport option with only the need for a browser on the client end, removing deployment barriers. > > After the work items in the current charter have been submitted to and approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis for consideration as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data format for collecting actual endpoint posture for consideration as standards-track RFC > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From david.waltermire@nist.gov Wed Jun 5 07:06:03 2013 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 00AF521F9AC8 for ; Wed, 5 Jun 2013 07:06:03 -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 vkVZmx-8av8Q for ; Wed, 5 Jun 2013 07:05:58 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DB22521F9ABB for ; Wed, 5 Jun 2013 07:05:57 -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.3.123.3; Wed, 5 Jun 2013 10:05:41 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 5 Jun 2013 10:05:56 -0400 From: "Waltermire, David A." To: Gunnar Engelbach , "Adam W. Montville" Date: Wed, 5 Jun 2013 10:05:55 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: Ac5hTm8gCC8jkpWnSruYgxLBs1vd0QAnUDPg Message-ID: References: <51AE21AB.4060209@ThreatGuard.com> In-Reply-To: <51AE21AB.4060209@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: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 05 Jun 2013 14:06:03 -0000 Great catch on change notification! The challenge with polling on a periodic basis is that the sample rate needs to be twice the rate of change. Using periodic data collection, there is a potential risk of missing a critical security-related change event that might indicate an attack is underway. If polling is performed outside the attack window, it is possible that the attack won't be noticed. Policy driven assessment, as you have written below, can be used to address this type of detection using most of the same bits and bytes. To support event-driven notification, the endpoint assessment software will need to be told what events to collect and pass on. Most of what is described in steps 1-4 of the draft charter still apply in setting up the event-driven collection environment. What is different is how steps 5 and 6 work. For step 5, the values are not harvested per se; they are generated based on change notifications. For step 6, incremental changes are reported on a continuous basis, until the endpoint is instructed not to collect those events anymore. This is a desirable capability for end-user organizations and I believe it should be reflected in the charter. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Tuesday, June 04, 2013 1:20 PM > To: Adam W. Montville > Cc: sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text > > > My primary quibbles are below, but I'd like to start by highlighting something > Stephen Whitlock said: "...deviations from standard configurations (whether > by accident or intent) would result in a notification..." > > Going back to Dave Waltermire's proposed architecture, it included change > notification originating from endpoints which helps feed Stephen's ideal, and > I don't see an allowance for that in this revision. > > Real time compliance/vulnerability notification originating from endpoint > events is a desirable security goal that I think falls within the scope of this > WG. > > There is also a significant lag between the formation of a new WG and the > delivery of usable products. > > So, while top-down assessments, seems to be plenty for this WG to gnaw on > at the moment, I'd like to also keep bottom-up in mind so that any work > done now doesn't preclude that as a follow-on. And, preferably, makes it > possible to quickly add that next. > > > There also seems to be a chicken-and-egg type of thing of selection of policy > versus selection of assets as the starting point. I think both are valid so I > tried, clumsily, to address that in my revision of the assessment steps, to > follow. > > ---------------------------+++++++++++++--------------------------- > > > > The components, protocols, and content documents defined by this working > group can be used in multiple ways such as top-down assessment of policy > compliance, notification of compliance posture change initiated by a change > made on an endpoint, determination of affected assets based on reportage > of a new vulnerability, ad-hoc queries of specific asset settings, etc. > > The initial focus of this working group is the performance of top-down policy > assessments using the following steps: > > > A policy-driven assessment: > > A) The content repository is queried for the content documents that > codify the policy/policies of interest. > > B) Assets are selected that match the criteria of the selected > policy/policies. The method of selection can include enumeration from > known asset inventories, direct query of known assets, network > discovery, etc. Selection of assets may be further refined by other > criteria such as ownership, location, role, time of day, etc. > > (Note: I used the term "asset" instead of "endpoint" because it > includes software assets, allowing for assessments of, for example, web > servers, virtual machine instance settings, a virtualized database > instance running on a cluster, etc) > > > Alternatively, and asset-driven assessment: > > A) Assets are selected based on a set of criteria (ownership, location, > role, time of day, etc.). > > B) For each asset, determine and retrieve the applicable policy/policies > from the content repository. > > > For each asset: > > 1) Determine what elements of posture information to collect based on > the policy/policies to be evaluated. > > > 2) For each element of the asset posture data, identify the mechanism > for data collection and what content is needed, if any, to support data > collection. > > (Note: I assume this means if the collection is via direct endpoint > query, CMDB retrieval, etc. That means a layer of meta data is needed > that we haven't really talked about: authentication information, DB > host/port, connection type, etc. Since this is an explicit step in the > process, should that data also be part of the standard?) > > > 3) Harvest the actual values pertaining to posture elements identified > in step 3 from the targeted asset(s). > > 4) Report collected asset posture. This will likely be done on an > individual basis for each identified asset , requiring aggregation of > data collected from multiple asset as needed based on the identified policy. > > > > > > > On 6/2/2013 11:57 AM, Adam W. Montville wrote: > > All: > > > > I've taken the charter (http://datatracker.ietf.org/doc/charter-ietf-sacm/) > and comments submitted in a variety of threads (http://www.ietf.org/mail- > archive/web/sacm/current/threads.html) and put the following together. > > > > I would love to see a dramatic increase in SACM participation throughout > this month - especially relating to the charter, which should be our primary > focus at this point, and then limited to the first several milestones. > > > > My concern is that SACM momentum is trailing off at a point when it needs > to be maintaining, if not increasing, from that level we saw at IETF 86. > > > > The following is the modified charter text: > > > > Securing information and the systems that store, process, and transmit that > information is a challenging task for organizations of all sizes, and many > security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. Automating > these routine tasks would free security practitioners to focus on high priority > tasks, and should improve operators' ability to prioritize risk based on timely > information about threats and vulnerabilities. This working group will define > security automation protocols and data format standards in support of > information security processes and practices. These standards will help > security practitioners to be more effective by automating routine tasks > related to client and server security, freeing them to focus on more > advanced tasks. The initial focus of this work is to address enterprise use > cases pertaining to the ass > es > > sment of endpoint posture (using the definitions of Endpoint and Posture > from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse existing > protocols, mechanisms, information and data models. Of particular interest > to this working group are existing industry standards, preferably IETF > standards, that could support automation of asset, change, configuration, > and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This area > of focus provides for necessary language and data format specifications. > > > > 2. A set of standards for interacting with repositories of content related to > assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following general > steps: > > > > 1. Relevant endpoints are identified and classified based on the targets of > the policy/policies to be evaluated > > > > 2. For each endpoint, determine what elements of posture information to > collect based on the policy/policies to be evaluated > > > > 3. For each element of the endpoint posture data, identify the mechanism > for data collection and what content is needed, if any, to support data > collection > > > > 4. Retrieve any content needed for data collection. Configuration checks > pertaining to a particular posture element may be used to support data > collection. > > > > 5. Harvest the actual values pertaining to posture elements identified in > step 3 from the endpoint. > > > > 6. Report collected endpoint posture as identified in step 2. This will likely > be done on an individual basis for each identified endpoint, requiring > aggregation of data collected from multiple endpoints as needed based on > the identified policy. > > > > This approach to endpoint posture collection enables multiple policies to be > evaluated based on a single data collection activity. Policies will be evaluated > by comparing available endpoint posture data according to rules expressed in > the policy. Typically, these rules will compare the actual value against an > expected value or range for specific posture elements. In some cases, the > posture element may pertain to software installation state, in which case the > actual and expected values may be "installed" or "not installed." Evaluation > of multiple posture elements may be combined using Boolean logic. > > > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to house > specific versions of checklists (i.e. benchmarks), may be required to satisfy > different use cases (i.e. a NEA-specific use vs. a generally applicable > assessment used during continuous monitoring). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, > asset classifications, vulnerability identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data collection and > analysis > > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in other SDOs > which can be used as-is or as a starting point for developing solutions to the > SACM requirements. The working group may decide to make of this > document an Informational RFC, but this is not a mandatory deliverable. > > > > The working group will work in close coordination with other WGs in the > IETF (including, but not limited to MILE and NEA) in order to create solutions > that do not overlap (for example for the repository access protocol) and can > be used or re-used to meet the goals of more than one working group. > > > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison relationships > or request the establishment of new liaison relationships. > > > > SACM-related efforts are largely aligned, and may overlap, with other IETF > (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest > to SACM is understanding and respecting the distinctions between itself and > NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository for > further analysis and action. NEA may also serve the purpose of carrying data- > collection instructions. > > > > The MILE data formats provide a format to describe incident, threat-related > incident, and indicator information. SACM data formats provide ways to > understand what endpoints are in your environment, whether they meet > policy requirements, and their current configuration state. The data > exchanged in MILE, supplementing the SACM data, creates enhanced > situational awareness, thus enabling increased understanding of current > threats and mitigations. The combined SACM and MILE data sets become a > powerful tool to automate security with descriptions of endpoints, known > vulnerabilities to those endpoints, and thier configurations along with an > understanding of layered defenses. Then, injecting known threat > information with mitigation options assists the organization in turning > detailed security decisions into business-relevant decisions. The MILE > protocols, RID and ROLIE, enable the exchange of structured data and are > designed to carry any structured format. While RID may be use > d > > in multiple sharing models and provides multiple communication flows > (report, query, etc.) with the ability to enable peer-to-peer object level > security, ROLIE provides a RESTful repository transport option with only the > need for a browser on the client end, removing deployment barriers. > > > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking > into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of related > standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data > format for retrieving configuration and policy information for driving data > collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data > format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for > consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol and > data format for retrieving configuration and policy information for driving > data collection and analysis for consideration as standards-track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data > format for collecting actual endpoint posture for consideration as standards- > track RFC > > > > _______________________________________________ > > 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 Wed Jun 5 07:30:03 2013 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 DDA9721F894E for ; Wed, 5 Jun 2013 07:30:03 -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 tdHXsOObBjJl for ; Wed, 5 Jun 2013 07:29:59 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id AE23421F8C38 for ; Wed, 5 Jun 2013 07:29:55 -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.3.123.3; Wed, 5 Jun 2013 10:29:48 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 5 Jun 2013 10:29:54 -0400 From: "Waltermire, David A." To: Michael Hammer , "Gunnar.Engelbach@ThreatGuard.com" , "adam@stoicsecurity.com" Date: Wed, 5 Jun 2013 10:29:53 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6npoH9PEWl1EkSYtYhfLQUR/JkmRWiAgAFcM4D//48nUIAAAYYA Message-ID: References: <51AE21AB.4060209@ThreatGuard.com> <00C069FD01E0324C9FFCADF539701DB3A03D8DE0@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03D8DE0@ex2k10mb2.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: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 05 Jun 2013 14:30:04 -0000 Are you suggesting that the steps should be made less prescriptive? Do you have any wording in mind to avoid this concern? Dave > -----Original Message----- > From: Michael Hammer [mailto:michael.hammer@yaanatech.com] > Sent: Wednesday, June 05, 2013 10:25 AM > To: Waltermire, David A.; Gunnar.Engelbach@ThreatGuard.com; > adam@stoicsecurity.com > Cc: sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > And if we later discover that the procedure needs to change again, do we > have to go through a re-charter? > I believe this should be characterized as an example, not prescriptive. > > Mike > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Wednesday, June 05, 2013 10:06 AM > To: Gunnar Engelbach; Adam W. Montville > Cc: sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text > > Great catch on change notification! The challenge with polling on a periodic > basis is that the sample rate needs to be twice the rate of change. Using > periodic data collection, there is a potential risk of missing a critical > security-related change event that might indicate an attack is underway. If > polling is performed outside the attack window, it is possible that the > attack won't be noticed. > > Policy driven assessment, as you have written below, can be used to address > this type of detection using most of the same bits and bytes. To support > event-driven notification, the endpoint assessment software will need to be > told what events to collect and pass on. Most of what is described in steps > 1-4 of the draft charter still apply in setting up the event-driven > collection environment. What is different is how steps 5 and 6 work. For > step 5, the values are not harvested per se; they are generated based on > change notifications. For step 6, incremental changes are reported on a > continuous basis, until the endpoint is instructed not to collect those > events anymore. > > This is a desirable capability for end-user organizations and I believe it > should be reflected in the charter. > > Sincerely, > Dave > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Gunnar Engelbach > > Sent: Tuesday, June 04, 2013 1:20 PM > > To: Adam W. Montville > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > My primary quibbles are below, but I'd like to start by highlighting > > something Stephen Whitlock said: "...deviations from standard > > configurations (whether by accident or intent) would result in a > notification..." > > > > Going back to Dave Waltermire's proposed architecture, it included > > change notification originating from endpoints which helps feed > > Stephen's ideal, and I don't see an allowance for that in this revision. > > > > Real time compliance/vulnerability notification originating from > > endpoint events is a desirable security goal that I think falls within > > the scope of this WG. > > > > There is also a significant lag between the formation of a new WG and > > the delivery of usable products. > > > > So, while top-down assessments, seems to be plenty for this WG to gnaw > > on at the moment, I'd like to also keep bottom-up in mind so that any > > work done now doesn't preclude that as a follow-on. And, preferably, > > makes it possible to quickly add that next. > > > > > > There also seems to be a chicken-and-egg type of thing of selection of > > policy versus selection of assets as the starting point. I think both > > are valid so I tried, clumsily, to address that in my revision of the > > assessment steps, to follow. > > > > ---------------------------+++++++++++++--------------------------- > > > > > > > > The components, protocols, and content documents defined by this > > working group can be used in multiple ways such as top-down assessment > > of policy compliance, notification of compliance posture change > > initiated by a change made on an endpoint, determination of affected > > assets based on reportage of a new vulnerability, ad-hoc queries of > specific asset settings, etc. > > > > The initial focus of this working group is the performance of top-down > > policy assessments using the following steps: > > > > > > A policy-driven assessment: > > > > A) The content repository is queried for the content documents that > > codify the policy/policies of interest. > > > > B) Assets are selected that match the criteria of the selected > > policy/policies. The method of selection can include enumeration from > > known asset inventories, direct query of known assets, network > > discovery, etc. Selection of assets may be further refined by other > > criteria such as ownership, location, role, time of day, etc. > > > > (Note: I used the term "asset" instead of "endpoint" because it > > includes software assets, allowing for assessments of, for example, > > web servers, virtual machine instance settings, a virtualized database > > instance running on a cluster, etc) > > > > > > Alternatively, and asset-driven assessment: > > > > A) Assets are selected based on a set of criteria (ownership, > > location, role, time of day, etc.). > > > > B) For each asset, determine and retrieve the applicable > > policy/policies from the content repository. > > > > > > For each asset: > > > > 1) Determine what elements of posture information to collect based on > > the policy/policies to be evaluated. > > > > > > 2) For each element of the asset posture data, identify the mechanism > > for data collection and what content is needed, if any, to support > > data collection. > > > > (Note: I assume this means if the collection is via direct endpoint > > query, CMDB retrieval, etc. That means a layer of meta data is needed > > that we haven't really talked about: authentication information, DB > > host/port, connection type, etc. Since this is an explicit step in > > the process, should that data also be part of the standard?) > > > > > > 3) Harvest the actual values pertaining to posture elements identified > > in step 3 from the targeted asset(s). > > > > 4) Report collected asset posture. This will likely be done on an > > individual basis for each identified asset , requiring aggregation of > > data collected from multiple asset as needed based on the identified > policy. > > > > > > > > > > > > > > On 6/2/2013 11:57 AM, Adam W. Montville wrote: > > > All: > > > > > > I've taken the charter > > > (http://datatracker.ietf.org/doc/charter-ietf-sacm/) > > and comments submitted in a variety of threads > > (http://www.ietf.org/mail- > > archive/web/sacm/current/threads.html) and put the following together. > > > > > > I would love to see a dramatic increase in SACM participation > > > throughout > > this month - especially relating to the charter, which should be our > > primary focus at this point, and then limited to the first several > milestones. > > > > > > My concern is that SACM momentum is trailing off at a point when it > > > needs > > to be maintaining, if not increasing, from that level we saw at IETF 86. > > > > > > The following is the modified charter text: > > > > > > Securing information and the systems that store, process, and > > > transmit that > > information is a challenging task for organizations of all sizes, and > > many security practitioners spend much of their time on manual processes. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. > > Automating these routine tasks would free security practitioners to > > focus on high priority tasks, and should improve operators' ability to > > prioritize risk based on timely information about threats and > > vulnerabilities. This working group will define security automation > > protocols and data format standards in support of information security > > processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks related > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > > cases pertaining to the ass es > > > sment of endpoint posture (using the definitions of Endpoint and > > > Posture > > from RFC 5209). > > > > > > The working group will, whenever reasonable and possible, reuse > > > existing > > protocols, mechanisms, information and data models. Of particular > > interest to this working group are existing industry standards, > > preferably IETF standards, that could support automation of asset, > > change, configuration, and vulnerability management. > > > > > > The working group will define: > > > > > > 1. A set of standards to enable assessment of endpoint posture. This > > > area > > of focus provides for necessary language and data format specifications. > > > > > > 2. A set of standards for interacting with repositories of content > > > related to > > assessment of endpoint posture. > > > > > > Assessment of endpoint posture assessment entails the following > > > general > > steps: > > > > > > 1. Relevant endpoints are identified and classified based on the > > > targets of > > the policy/policies to be evaluated > > > > > > 2. For each endpoint, determine what elements of posture information > > > to > > collect based on the policy/policies to be evaluated > > > > > > 3. For each element of the endpoint posture data, identify the > > > mechanism > > for data collection and what content is needed, if any, to support > > data collection > > > > > > 4. Retrieve any content needed for data collection. Configuration > > > checks > > pertaining to a particular posture element may be used to support data > > collection. > > > > > > 5. Harvest the actual values pertaining to posture elements > > > identified in > > step 3 from the endpoint. > > > > > > 6. Report collected endpoint posture as identified in step 2. This > > > will likely > > be done on an individual basis for each identified endpoint, requiring > > aggregation of data collected from multiple endpoints as needed based > > on the identified policy. > > > > > > This approach to endpoint posture collection enables multiple > > > policies to be > > evaluated based on a single data collection activity. Policies will be > > evaluated by comparing available endpoint posture data according to > > rules expressed in the policy. Typically, these rules will compare the > > actual value against an expected value or range for specific posture > > elements. In some cases, the posture element may pertain to software > > installation state, in which case the actual and expected values may > > be "installed" or "not installed." Evaluation of multiple posture elements > may be combined using Boolean logic. > > > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. a NEA-specific use vs. a > > generally applicable assessment used during continuous monitoring). > > In addition, content repositories are expected to store up-to-date > > dictionary of specific enumerations, such as those used for > > configuration element identifiers, asset classifications, vulnerability > identifiers, and so on. > > > > > > This working group will achieve the following deliverables: > > > > > > - An Informational document on Use Cases > > > - An Informational document on Requirements > > > - An Informational document on SACM Architecture > > > - A standards-track document specifying a protocol and data format > > > for > > retrieving configuration and policy information for driving data > > collection and analysis > > > - A standards-track document specifying a protocol and data format > > > for > > collecting actual endpoint posture > > > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > > other SDOs which can be used as-is or as a starting point for > > developing solutions to the SACM requirements. The working group may > > decide to make of this document an Informational RFC, but this is not a > mandatory deliverable. > > > > > > The working group will work in close coordination with other WGs in > > > the > > IETF (including, but not limited to MILE and NEA) in order to create > > solutions that do not overlap (for example for the repository access > > protocol) and can be used or re-used to meet the goals of more than one > working group. > > > > > > In accordance with existing IETF processes, the group will > > > communicate > > with and invite participation from other relevant standards bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison relationships. > > > > > > SACM-related efforts are largely aligned, and may overlap, with > > > other IETF > > (and non-IETF) standardization efforts. There are common "problems" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > > interest to SACM is understanding and respecting the distinctions > > between itself and NEA and MILE. > > > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data- collection instructions. > > > > > > The MILE data formats provide a format to describe incident, > > > threat-related > > incident, and indicator information. SACM data formats provide ways > > to understand what endpoints are in your environment, whether they > > meet policy requirements, and their current configuration state. The > > data exchanged in MILE, supplementing the SACM data, creates enhanced > > situational awareness, thus enabling increased understanding of > > current threats and mitigations. The combined SACM and MILE data sets > > become a powerful tool to automate security with descriptions of > > endpoints, known vulnerabilities to those endpoints, and thier > > configurations along with an understanding of layered defenses. Then, > > injecting known threat information with mitigation options assists the > > organization in turning detailed security decisions into > > business-relevant decisions. The MILE protocols, RID and ROLIE, > > enable the exchange of structured data and are designed to carry any > > structured format. While RID may be use d > > > in multiple sharing models and provides multiple communication > > > flows > > (report, query, etc.) with the ability to enable peer-to-peer object > > level security, ROLIE provides a RESTful repository transport option > > with only the need for a browser on the client end, removing deployment > barriers. > > > > > > After the work items in the current charter have been submitted to > > > and > > approved by the IESG, the WG will recharter or close. > > > > > > Goals and Milestones > > > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > > taking > > into consideration RFC5706 and RFC3535 > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > > Architecture > > > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > > related > > standards work > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > > and data > > format for retrieving configuration and policy information for driving > > data collection and analysis > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > > and data > > format for collecting actual endpoint posture > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > > > Cases for > > consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > > Requirements > > for consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > > protocol and > > data format for retrieving configuration and policy information for > > driving data collection and analysis for consideration as > > standards-track RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > > and data > > format for collecting actual endpoint posture for consideration as > > standards- track RFC > > > > > > _______________________________________________ > > > 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 dbharrington@comcast.net Wed Jun 5 08:26:15 2013 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 9BB7421F8EBC for ; Wed, 5 Jun 2013 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 t-egXSnd5MHu for ; Wed, 5 Jun 2013 08:26:11 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 11A6921F960D for ; Wed, 5 Jun 2013 08:26:06 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id kbKC1l0070vyq2s5DfS2c5; Wed, 05 Jun 2013 15:26:02 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta05.westchester.pa.mail.comcast.net with comcast id kfS11l00n2yZEBF3RfS2ZS; Wed, 05 Jun 2013 15:26:02 +0000 From: "David Harrington" To: , "'ietfdbh'" References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> <51AD831E.8000100@netmagic.com> In-Reply-To: <51AD831E.8000100@netmagic.com> Date: Wed, 5 Jun 2013 11:25:39 -0400 Message-ID: <01ca01ce6200$efec5cd0$cfc51670$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEMdLuegdeWdCbFCE+YTD19zbEQBQB+8R1tASepuEMCeVwTZJqKDVlQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370445962; bh=JZiDSZMSwcoZsTswkerXoZ4isJsqdgVpWqjfn/+g/Hc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=GzdhJvjIvjjqQL8u9nCDTnlLgu2ozUA4EFq9E0RbWChxKUWNhiba4pHX1Ppz+31mS nVM9Ww88HDih8IsUrHn+Vfvlq4Qe3m5QMvX68LU5U/vFUefDHTxO4qg7xWnEcFCEXK CStDYb8RgsD35uoKdfYEzkhlpyvvK9mfNkwVMaCduokc3KmHiOLU4CUiKZsUR1Nfno baCAjbAJSif6dgTOwM3Px+ZK/vBQjb6QWC/HOA6aGZyyrZwOw6ZK8QJoTlLaAAGpUf pcr44LaHA1v7G4AplzimckSHETD38L/b3WqSSeXGu1RbA/a7QYn38MZm7ryTfYPCHv cDCt9BX9z0jSA== Cc: "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [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, 05 Jun 2013 15:26:15 -0000 Hi Tony, Steve took your suggestion and looked at the SECAM work, and by his analysis, the SECAM work is focused differently than the sacm work somewhat. http://www.ietf.org/mail-archive/web/sacm/current/msg00920.html The IETF is driven by efforts of individual volunteers; there are no membership requirements; just join in the discussion. And it's free. Individuals from the 3GPP SECAM and ETSI ISI efforts are welcome to come be a part of the IETF work being done in sacm. I looked at the possibility of participating in the SECAM and ISI work to "actively engage" as an individual across SDOs (not that I actually want to take on that extra work). 3GPP requires a corporate membership in order to contribute. I might be able to get a guest membership, but that would only allow me access to the documents, not any rights to contribute or vote, and a guest membership is only good for six months (which is less time than this WG is expected to last). ETSI requires contributors to be a member of an Organizational Partner, and has a membership fee schedule that is well outside my range as an individual contributor. So the active engagement would appear to be one-way (from SECAM and ISI to sacm) if I were to do it. And I don't want to commit my time to doing all three efforts. If you, as an IETF individual contributor, believe that there is something in the SECAM work that should be considered in our use cases, then by all means please do the analysis and send some text to the WG asking that your text be incorporated into the use case document. Ditto for the ETSI ISI work. (being careful of copyrighted material, of course) If you know of others participating in SECAM and/or ISI who want to contribute to the IETF sacm work as individual contributors, please let them know they are welcome to contribute here. For free, with no membership requirements. And we certainly welcome your taking the work being done here (which is freely available anyway) and making the SECAM and ISI efforts aware of it. While the sacm work isn't cast in stone yet, you, as a contributor to SECAM and ISI, could also pass on some of the sacm work to those efforts to provide some active engagement between the efforts. Let me stress, however, that the" active engagement" would be you acting as an individual contributor to multiple efforts. The SECAM and ISI work will typically be given no greater weight than any other individual contribution, per IETF rules. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Tuesday, June 04, 2013 2:03 AM To: ietfdbh Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org Subject: Re: [sacm] use case document You can get many at least one set of use cases from the SECAM working group in 3GPP SA3 - which is very active doing much the same things as are occurring in SACM. Ditto for the ISI group in ETSI. SACM can improve its effectiveness by proactively engaging the multiple other similar groups out there. --tony On 2013-06-04 2:01 AM, ietfdbh wrote: > I have no objection to helping edit the draft. > However, the main failing of the draft in my eyes is that it doesn't > really contain use cases. > I am not active in the industry we are targeting, so we would need > some input on use cases from operators, security admins, vendors, etc. who are. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Wed Jun 5 09:23:28 2013 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 C349321F9B99 for ; Wed, 5 Jun 2013 09:23:26 -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 kGNqiMM-XQWS for ; Wed, 5 Jun 2013 09:23:15 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1E86621F9BA6 for ; Wed, 5 Jun 2013 09:23:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=AxurpFKLPAGEDrfJ399NVaUeg2XIdrCZSTgs2+SsgNswjErJJ0k4p7b+G8johlBPBY3EpQerg2GknFT07oU/Co9OUOutrJ2k9eaNEs9GEAQnU4TfYtaKLAmNNKE3xFHF; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 18340 invoked from network); 5 Jun 2013 09:34:43 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Jun 2013 09:34:43 -0700 Message-ID: <51AF65F5.4000404@ThreatGuard.com> Date: Wed, 05 Jun 2013 12:23:17 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "sacm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sacm] WG Standards List 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, 05 Jun 2013 16:23:37 -0000 Picking through the discussions and architecture documents I put together a list of what looks like the actual standards to be produced by this working group. I have broken this list out to be explicit, so each outline item doesn't necessarily represent a separate deliverable. Items in section 2) and 4) a) have not been discussed and it may be determined that they do not need to be shared and therefore vendor-proprietary solutions are expected. 1) Content repository contents a) Policy Types: i) Configuration Compliance ii) Known Vulnerabilities iii) Malware Detection iv) Interactive Questionnaire v) ... b) Applicability of content item c) Data items necessary to determine posture d) Guidance for collection of data items e) Optional content i) Policy assistance content (Original guidance documentation, policy in prose/spreadsheet format, driving regulation, instructional videos, etc.). ii) Local policy deviations iii) Remediation 2) Controller content a) Collection metadata (source, source type, authentication, etc) b) Content repository metadata (location, authentication, scope, etc) 3) Data storage content a) Asset Inventory b) Collected data items c) Assessment derivatives 4) Data transfers a) Content repository query/response b) Asset query/response c) Data collection request d) Collected data publication e) Collection metadata request/response f) Assessment request/response g) Assessment derivatives request/response (single/multiple assets) From dbharrington@comcast.net Wed Jun 5 11:06:28 2013 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 9C39A21F9AB3 for ; Wed, 5 Jun 2013 11:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.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 U1f9DnIh4SPy for ; Wed, 5 Jun 2013 11:06:23 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 7662B21F9A24 for ; Wed, 5 Jun 2013 11:06:18 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id kghS1l0050ldTLk51i5qYh; Wed, 05 Jun 2013 18:05:50 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta04.westchester.pa.mail.comcast.net with comcast id ki5p1l00N2yZEBF01i5pxs; Wed, 05 Jun 2013 18:05:50 +0000 From: "David Harrington" To: "'Tony Rutkowski'" References: <7k17eabaj8f53qisxjq52fhs.1370451919871@email.android.com> In-Reply-To: <7k17eabaj8f53qisxjq52fhs.1370451919871@email.android.com> Date: Wed, 5 Jun 2013 14:05:27 -0400 Message-ID: <01e201ce6217$42a6a370$c7f3ea50$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E3_01CE61F5.BB966300" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJeYaVLybYJpZmIEKFXHC3Kx+XcuZgHahZw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370455550; bh=qH+xk2awZhuXdWgXeRN9etFvEf/I+Vlpzrhdq6Sy7Lo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=iuUNosub5AVXFKxZaj6pRekruExhZQH9dKxk4OVEHDlEMHvqj+Nq9FF6eBNfQ7aQm h9jXklDEMZ8O6XMP+r9rx17w0Z66SBMPVAV+ArpgA+KFCblBoF/sxQHSU7DkNuMUs/ hKqSo29nBJTjg4pm6cGKBDZW3AaYK0FDiXvydMX4yPLL0ar5aEQmX10Xns5xoUw2JC d4oKzBUy8FsE0d800naUAeVAC5IgQBwOL8S/A7N+U+4CaPDgN9gFWuX47mCdr6TCgf ZsWS/aE6kevf37xoZs8CJsgfTOlTpSZpYd1gYyp0WffQpkZastA1QTs9Gf61dj/f5M B2MZPmJP8kjdA== Cc: sacm@ietf.org Subject: Re: [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, 05 Jun 2013 18:06:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01E3_01CE61F5.BB966300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks, Tony, that would be helpful. =20 Text describing some specific use cases already used in the field (using = proprietary technology) would be especially helpful for the use cases = document. =20 David Harrington dbharrington@comcast.net +1-603-828-1401 From: Tony Rutkowski [mailto:tony@yaanatech.com]=20 Sent: Wednesday, June 05, 2013 1:05 PM To: David Harrington Subject: RE: [sacm] use case document =20 Hi David, =20 I'll see what I can do to bridge the stovepipes here.=20 =20 ETSI and the CCRA may also be starting efforts that are SACM-like. =20 =20 =20 Sent from Samsung Mobile -------- Original message -------- From: David Harrington =20 Date: 05/06/2013 17:25 (GMT+01:00)=20 To: trutkowski@netmagic.com,'ietfdbh' =20 Cc: "'Waltermire, David A.'" ,sacm@ietf.org=20 Subject: RE: [sacm] use case document=20 Hi Tony, Steve took your suggestion and looked at the SECAM work, and by his analysis, the SECAM work is focused differently than the sacm work = somewhat. http://www.ietf.org/mail-archive/web/sacm/current/msg00920.html The IETF is driven by efforts of individual volunteers; there are no membership requirements; just join in the discussion. And it's free. Individuals from the 3GPP SECAM and ETSI ISI efforts are welcome to come = be a part of the IETF work being done in sacm. I looked at the possibility of participating in the SECAM and ISI work = to "actively engage" as an individual across SDOs (not that I actually want = to take on that extra work). 3GPP requires a corporate membership in order to contribute. I might be = able to get a guest membership, but that would only allow me access to the documents, not any rights to contribute or vote, and a guest membership = is only good for six months (which is less time than this WG is expected to last). ETSI requires contributors to be a member of an Organizational Partner, = and has a membership fee schedule that is well outside my range as an = individual contributor. So the active engagement would appear to be one-way (from SECAM and ISI = to sacm) if I were to do it. And I don't want to commit my time to doing = all three efforts. If you, as an IETF individual contributor, believe that there is = something in the SECAM work that should be considered in our use cases, then by = all means please do the analysis and send some text to the WG asking that = your text be incorporated into the use case document. Ditto for the ETSI ISI work. (being careful of copyrighted material, of course) If you know of others participating in SECAM and/or ISI who want to contribute to the IETF sacm work as individual contributors, please let = them know they are welcome to contribute here. For free, with no membership requirements. And we certainly welcome your taking the work being done here (which is freely available anyway) and making the SECAM and ISI efforts aware of = it. While the sacm work isn't cast in stone yet, you, as a contributor to = SECAM and ISI, could also pass on some of the sacm work to those efforts to provide some active engagement between the efforts.=20 Let me stress, however, that the" active engagement" would be you acting = as an individual contributor to multiple efforts. The SECAM and ISI work = will typically be given no greater weight than any other individual = contribution, per IETF rules. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Tony Rutkowski Sent: Tuesday, June 04, 2013 2:03 AM To: ietfdbh Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org Subject: Re: [sacm] use case document You can get many at least one set of use cases from the SECAM working = group in 3GPP SA3 - which is very active doing much the same things as are occurring in SACM. Ditto for the ISI group in ETSI. SACM can improve its effectiveness by proactively engaging the multiple other similar groups out there. --tony On 2013-06-04 2:01 AM, ietfdbh wrote: > I have no objection to helping edit the draft. > However, the main failing of the draft in my eyes is that it doesn't=20 > really contain use cases. > I am not active in the industry we are targeting, so we would need=20 > some input on use cases from operators, security admins, vendors, etc. = who are. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_01E3_01CE61F5.BB966300 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks, Tony, that would be helpful.

 

Text describing some specific use cases already used in the field = (using proprietary technology) would be especially helpful for the use = cases document.

 

+1-603-828-1401

From:= = Tony Rutkowski [mailto:tony@yaanatech.com]
Sent: Wednesday, = June 05, 2013 1:05 PM
To: David Harrington
Subject: = RE: [sacm] use case document

 

Hi = David,

 

I'll see what I can do to bridge the stovepipes = here. 

 

ETSI and the CCRA may also be starting efforts that = are SACM-like.

 

 

 

Sent = from Samsung Mobile




-------- = Original message --------
From: David Harrington <dbharrington@comcast.net>=
Date: 05/06/2013 17:25 (GMT+01:00)
To: trutkowski@netmagic.com,= 'ietfdbh' <ietfdbh@comcast.net>
Cc: = "'Waltermire, David A.'" <david.waltermire@nist.gov&g= t;,sacm@ietf.org
Subject: RE: [sacm] use case document =


Hi Tony,

Steve took your suggestion and looked at the = SECAM work, and by his
analysis, the SECAM work is focused = differently than the sacm work somewhat.
= http://www.ietf.org/mail-archive/web/sacm/current/msg00920.html
The IETF is driven by efforts of individual volunteers; there are = no
membership requirements; just join in the discussion. And it's = free.
Individuals from the 3GPP SECAM and ETSI ISI efforts are = welcome to come be
a part of the IETF work being done in sacm.
I = looked at the possibility of participating in the SECAM and ISI work = to
"actively engage" as an individual across SDOs (not that = I actually want to
take on that extra work).
3GPP requires a = corporate membership in order to contribute. I might be able
to get a = guest membership, but that would only allow me access to = the
documents, not any rights to contribute or vote, and a guest = membership is
only good for six months (which is less time than this = WG is expected to
last).
ETSI requires contributors to be a member = of an Organizational Partner, and
has a membership fee schedule that = is well outside my range as an individual
contributor.
So the = active engagement would appear to be one-way (from SECAM and ISI = to
sacm) if I were to do it. And I don't want to commit my time to = doing all
three efforts.

If you, as an IETF individual = contributor, believe that there is something
in the SECAM work that = should be considered in our use cases, then by all
means please do = the analysis and send some text to the WG asking that your
text be = incorporated into the use case document.
Ditto for the ETSI ISI = work.
(being careful of copyrighted material, of course)
If you = know of others participating in SECAM and/or ISI who want = to
contribute to the IETF sacm work as individual contributors, = please let them
know they are welcome to contribute here. For free, = with no membership
requirements.
And we certainly welcome your = taking the work being done here (which is
freely available anyway) = and making the SECAM and ISI efforts aware of it.
While the sacm work = isn't cast in stone yet, you, as a contributor to SECAM
and ISI, = could also pass on some of the sacm work to those efforts to
provide = some active engagement between the efforts.

Let me stress, = however, that the" active engagement" would be you acting = as
an individual contributor to multiple efforts. The SECAM and ISI = work will
typically be given no greater weight than any other = individual contribution,
per IETF rules.

David = Harrington
dbharrington@comcast.net
= +1-603-828-1401

-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] = On Behalf Of Tony
Rutkowski
Sent: Tuesday, June 04, 2013 2:03 = AM
To: ietfdbh
Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org
Subject: Re: [sacm] = use case document

You can get many at least one set of use cases = from the SECAM working group
in 3GPP SA3 - which is very active doing = much the same things as are
occurring in SACM.
Ditto for the ISI = group in ETSI.

SACM can improve its effectiveness = by
proactively engaging the multiple other
similar groups out = there.
--tony


On 2013-06-04 2:01 AM, ietfdbh = wrote:
> I have no objection to helping edit the draft.
> = However, the main failing of the draft in my eyes is that it doesn't =
> really contain use cases.
> I am not active in the = industry we are targeting, so we would need
> some input on use = cases from operators, security admins, vendors, etc. = who
are.
>
> David Harrington
> ietfdbh@comcast.net
> = +1-603-828-1401
>

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

------=_NextPart_000_01E3_01CE61F5.BB966300-- From prvs=0868d4f5b1=rainer.enders@ncp-e.com Wed Jun 5 12:54:30 2013 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 C7E5721F9B2F for ; Wed, 5 Jun 2013 12:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 MI4Xxk0LiA6a for ; Wed, 5 Jun 2013 12:54:26 -0700 (PDT) Received: from mail.ncp.de (mail.remote-access.de [62.153.165.35]) by ietfa.amsl.com (Postfix) with ESMTP id C2AEB21F9B2A for ; Wed, 5 Jun 2013 12:54:11 -0700 (PDT) Received: from viruswall.ncp.de (viruswall.ncp.de [62.153.165.41]) by mail.ncp.de (Postfix) with ESMTPS id ACDB33AE290 for ; Wed, 5 Jun 2013 21:59:02 +0200 (CEST) Received: from [172.16.11.201] (port=28450 helo=ex07.ncp.local) by viruswall.ncp.de with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1UkJmO-0003PR-2p; Wed, 05 Jun 2013 21:53:57 +0200 Received: from ex07.ncp.local ([172.16.11.201]) by ex07.ncp.local ([172.16.11.201]) with mapi; Wed, 5 Jun 2013 21:53:56 +0200 X-CTCH-RefID: str=0001.0A0C0201.51AF9755.0013,ss=1,re=0.000,fgs=0 From: Rainer Enders To: Sean Turner , "Adam W. Montville" Date: Wed, 5 Jun 2013 21:53:51 +0200 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: Ac5iJmlKEiq1BY8FRpaihNJRodL9ow== Message-ID: In-Reply-To: <51ADE797.70900@ieca.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text 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, 05 Jun 2013 19:54:31 -0000 I feel this workgroup will address a very relevant problem. A question for clarification that has been on my mind for a while. I assume sacm will not address the issue of lying endpoints or the verification of endpoint identity and/or state? Can someone confirm that this is out of scope? Thank you. On 6/4/13 6:11 AM, "Sean Turner" wrote: >Adam, > >Thanks for driving this forward. This looks a lot better to me. >Hopefully Gunnar can get his comments in soon and we we can see where we >stand then. > >spt > >On 6/2/13 11:57 AM, Adam W. Montville wrote: >> All: >> >> I've taken the charter >>(http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments >>submitted in a variety of threads >>(http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and put >>the following together. >> >> I would love to see a dramatic increase in SACM participation >>throughout this month - especially relating to the charter, which should >>be our primary focus at this point, and then limited to the first >>several milestones. >> >> My concern is that SACM momentum is trailing off at a point when it >>needs to be maintaining, if not increasing, from that level we saw at >>IETF 86. >> >> The following is the modified charter text: >> >> Securing information and the systems that store, process, and transmit >>that information is a challenging task for organizations of all sizes, >>and many security practitioners spend much of their time on manual >>processes. Standardized processes to collect, verify, and update >>security system configurations would allow easier automation of the >>processes. Automating these routine tasks would free security >>practitioners to focus on high priority tasks, and should improve >>operators' ability to prioritize risk based on timely information about >>threats and vulnerabilities. This working group will define security >>automation protocols and data format standards in support of information >>security processes and practices. These standards will help security >>practitioners to be more effective by automating routine tasks related >>to client and server security, freeing them to focus on more advanced >>tasks. The initial focus of this work is to address enterprise use cases >>pertaining to the ass > es >> sment of endpoint posture (using the definitions of Endpoint and >>Posture from RFC 5209). >> >> The working group will, whenever reasonable and possible, reuse >>existing protocols, mechanisms, information and data models. Of >>particular interest to this working group are existing industry >>standards, preferably IETF standards, that could support automation of >>asset, change, configuration, and vulnerability management. >> >> The working group will define: >> >> 1. A set of standards to enable assessment of endpoint posture. This >>area of focus provides for necessary language and data format >>specifications. >> >> 2. A set of standards for interacting with repositories of content >>related to assessment of endpoint posture. >> >> Assessment of endpoint posture assessment entails the following general >>steps: >> >> 1. Relevant endpoints are identified and classified based on the >>targets of the policy/policies to be evaluated >> >> 2. For each endpoint, determine what elements of posture information to >>collect based on the policy/policies to be evaluated >> >> 3. For each element of the endpoint posture data, identify the >>mechanism for data collection and what content is needed, if any, to >>support data collection >> >> 4. Retrieve any content needed for data collection. Configuration >>checks pertaining to a particular posture element may be used to support >>data collection. >> >> 5. Harvest the actual values pertaining to posture elements identified >>in step 3 from the endpoint. >> >> 6. Report collected endpoint posture as identified in step 2. This >>will likely be done on an individual basis for each identified endpoint, >>requiring aggregation of data collected from multiple endpoints as >>needed based on the identified policy. >> >> This approach to endpoint posture collection enables multiple policies >>to be evaluated based on a single data collection activity. Policies >>will be evaluated by comparing available endpoint posture data according >>to rules expressed in the policy. Typically, these rules will compare >>the actual value against an expected value or range for specific posture >>elements. In some cases, the posture element may pertain to software >>installation state, in which case the actual and expected values may be >>"installed" or "not installed." Evaluation of multiple posture elements >>may be combined using Boolean logic. >> >> Repository protocols are needed to store, update, and retrieve >>configuration checks and other types of content required for posture >>assessment (see step 2 above). A content repository is expected to >>house specific versions of checklists (i.e. benchmarks), may be required >>to satisfy different use cases (i.e. a NEA-specific use vs. a generally >>applicable assessment used during continuous monitoring). In addition, >>content repositories are expected to store up-to-date dictionary of >>specific enumerations, such as those used for configuration element >>identifiers, asset classifications, vulnerability identifiers, and so on. >> >> This working group will achieve the following deliverables: >> >> - An Informational document on Use Cases >> - An Informational document on Requirements >> - An Informational document on SACM Architecture >> - A standards-track document specifying a protocol and data format for >>retrieving configuration and policy information for driving data >>collection and analysis >> - A standards-track document specifying a protocol and data format for >>collecting actual endpoint posture >> >> The working group will create an overview of related standards work >>Internet-Draft which will document existing work in the IETF or in other >>SDOs which can be used as-is or as a starting point for developing >>solutions to the SACM requirements. The working group may decide to make >>of this document an Informational RFC, but this is not a mandatory >>deliverable. >> >> The working group will work in close coordination with other WGs in the >>IETF (including, but not limited to MILE and NEA) in order to create >>solutions that do not overlap (for example for the repository access >>protocol) and can be used or re-used to meet the goals of more than one >>working group. >> >> In accordance with existing IETF processes, the group will communicate >>with and invite participation from other relevant standards bodies and >>regulatory organizations, and if necessary reuse existing liaison >>relationships or request the establishment of new liaison relationships. >> >> SACM-related efforts are largely aligned, and may overlap, with other >>IETF (and non-IETF) standardization efforts. There are common >>"problems" found in SACM, that may be addressed by the work done in >>SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of >>particular interest to SACM is understanding and respecting the >>distinctions between itself and NEA and MILE. >> >> One way the NEA protocols can be used is as the transport for data >>collected on the endpoint to an external service or data repository for >>further analysis and action. NEA may also serve the purpose of carrying >>data-collection instructions. >> >> The MILE data formats provide a format to describe incident, >>threat-related incident, and indicator information. SACM data formats >>provide ways to understand what endpoints are in your environment, >>whether they meet policy requirements, and their current configuration >>state. The data exchanged in MILE, supplementing the SACM data, creates >>enhanced situational awareness, thus enabling increased understanding of >>current threats and mitigations. The combined SACM and MILE data sets >>become a powerful tool to automate security with descriptions of >>endpoints, known vulnerabilities to those endpoints, and thier >>configurations along with an understanding of layered defenses. Then, >>injecting known threat information with mitigation options assists the >>organization in turning detailed security decisions into >>business-relevant decisions. The MILE protocols, RID and ROLIE, enable >>the exchange of structured data and are designed to carry any structured >>format. While RID may be use > d >> in multiple sharing models and provides multiple communication flows >>(report, query, etc.) with the ability to enable peer-to-peer object >>level security, ROLIE provides a RESTful repository transport option >>with only the need for a browser on the client end, removing deployment >>barriers. >> >> After the work items in the current charter have been submitted to and >>approved by the IESG, the WG will recharter or close. >> >> Goals and Milestones >> >> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >> >> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>taking into consideration RFC5706 and RFC3535 >> >> Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture >> >> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>related standards work >> >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and >>data format for retrieving configuration and policy information for >>driving data collection and analysis >> >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and >>data format for collecting actual endpoint posture >> >> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases >>for consideration as Informational RFC >> >> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>Requirements for consideration as Informational RFC >> >> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>Architecture for consideration as Informational RFC >> >> Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol >>and data format for retrieving configuration and policy information for >>driving data collection and analysis for consideration as >>standards-track RFC >> >> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and >>data format for collecting actual endpoint posture for consideration as >>standards-track RFC >> >> _______________________________________________ >> 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 Adam.Montville@cisecurity.org Thu Jun 6 06:41:57 2013 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 DE66321F8616 for ; Thu, 6 Jun 2013 06:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmmG1aBoPKT8 for ; Thu, 6 Jun 2013 06:41:53 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.3]) by ietfa.amsl.com (Postfix) with ESMTP id 35B4021F8609 for ; Thu, 6 Jun 2013 06:41:53 -0700 (PDT) Received: from [216.82.250.179:8622] by server-3.bemta-12.messagelabs.com id 10/6D-03515-0A190B15; Thu, 06 Jun 2013 13:41:52 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-210.messagelabs.com!1370526111!7978709!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 25452 invoked from network); 6 Jun 2013 13:41:52 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jun 2013 13:41:52 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 6 Jun 2013 09:41:47 -0400 From: Adam Montville To: Gunnar Engelbach , "sacm@ietf.org" Thread-Topic: [sacm] WG Standards List Thread-Index: AQHOYgkLqtuONcko1UmFh6u5xm+KYZkoshyf Date: Thu, 6 Jun 2013 13:41:46 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F2A83@CISEXCHANGE1.msisac.org.local> References: , <51AF65F5.4000404@ThreatGuard.com> In-Reply-To: <51AF65F5.4000404@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] WG Standards List X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:41:58 -0000 Gunnar, thanks for putting this out there. I understand that there's a pr= edisposition to avoid referencing existing work at this point, but I do wa= nt to point out that this list represents the areas we'd like to address a= nd does not necessarily convey all the work products this WG would produce= . It is likely that we will reference existing work for more than a few o= f the items you mention. Adam =20 ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Gunnar En= gelbach [Gunnar.Engelbach@ThreatGuard.com] Sent: Wednesday, June 05, 2013 9:23 AM To: sacm@ietf.org Subject: [sacm] WG Standards List Picking through the discussions and architecture documents I put together a list of what looks like the actual standards to be produced by this working group. I have broken this list out to be explicit, so each outline item doesn't necessarily represent a separate deliverable. Items in section 2) and 4) a) have not been discussed and it may be determined that they do not need to be shared and therefore vendor-proprietary solutions are expected. 1) Content repository contents a) Policy Types: i) Configuration Compliance ii) Known Vulnerabilities iii) Malware Detection iv) Interactive Questionnaire v) ... b) Applicability of content item c) Data items necessary to determine posture d) Guidance for collection of data items e) Optional content i) Policy assistance content (Original guidance documentation, policy in prose/spreadsheet format, driving regulation, instructional videos, etc.). ii) Local policy deviations iii) Remediation 2) Controller content a) Collection metadata (source, source type, authentication, etc) b) Content repository metadata (location, authentication, scope, etc) 3) Data storage content a) Asset Inventory b) Collected data items c) Assessment derivatives 4) Data transfers a) Content repository query/response b) Asset query/response c) Data collection request =20d) Collected data publication e) Collection metadata request/response f) Assessment request/response g) Assessment derivatives request/response (single/multiple assets) _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... 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 gunnar.engelbach@threatguard.com Thu Jun 6 07:48:27 2013 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 58F4021F8F69 for ; Thu, 6 Jun 2013 07:48:27 -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 j8oUyfNwMD4J for ; Thu, 6 Jun 2013 07:48:22 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id DE48321F8F5C for ; Thu, 6 Jun 2013 07:48:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=q9K2ghHp6cUcEm4Btv3CnO3kPU9fw5uTIiK6tr9O/q2K47pR6adr1PG/oRG0bF+Abp8GL1cJAX6t9UXItsgZps+u9AHOS49A/TKHM2I0AtHEOOHwpLXQ+bhp9LUK8g8N; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 14062 invoked from network); 6 Jun 2013 07:59:54 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 6 Jun 2013 07:59:54 -0700 Message-ID: <51B0A13A.5070609@ThreatGuard.com> Date: Thu, 06 Jun 2013 10:48:26 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Montville References: , <51AF65F5.4000404@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F2A83@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F2A83@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] WG Standards List X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:48:27 -0000 I'm also very reticent about taking category 3) very far. I don't think we want to try to define *how* data is stored, but we do want to document what the minimal set of data for each type is and how it is requested/communicated. 4) e) should be: *Controller* metadata request/response On 6/6/2013 9:41 AM, Adam Montville wrote: > Gunnar, thanks for putting this out there. I understand that there's a predisposition to avoid referencing existing work at this point, but I do want to point out that this list represents the areas we'd like to address and does not necessarily convey all the work products this WG would produce. It is likely that we will reference existing work for more than a few of the items you mention. > > Adam > > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Gunnar Engelbach [Gunnar.Engelbach@ThreatGuard.com] > Sent: Wednesday, June 05, 2013 9:23 AM > To: sacm@ietf.org > Subject: [sacm] WG Standards List > > Picking through the discussions and architecture documents I put > together a list of what looks like the actual standards to be produced > by this working group. I have broken this list out to be explicit, so > each outline item doesn't necessarily represent a separate deliverable. > > Items in section 2) and 4) a) have not been discussed and it may be > determined that they do not need to be shared and therefore > vendor-proprietary solutions are expected. > > > 1) Content repository contents > a) Policy Types: > i) Configuration Compliance > ii) Known Vulnerabilities > iii) Malware Detection > iv) Interactive Questionnaire > v) ... > b) Applicability of content item > c) Data items necessary to determine posture > d) Guidance for collection of data items > e) Optional content > i) Policy assistance content (Original guidance documentation, > policy in prose/spreadsheet format, driving regulation, instructional > videos, etc.). > ii) Local policy deviations > iii) Remediation > > > 2) Controller content > a) Collection metadata (source, source type, authentication, etc) > b) Content repository metadata (location, authentication, scope, etc) > > > 3) Data storage content > a) Asset Inventory > b) Collected data items > c) Assessment derivatives > > > > 4) Data transfers > a) Content repository query/response > b) Asset query/response > c) Data collection request > d) Collected data publication > e) Collection metadata request/response > f) Assessment request/response > g) Assessment derivatives request/response (single/multiple assets) > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > ... > > 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 Adam.Montville@cisecurity.org Thu Jun 6 10:17:26 2013 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 B6B9521F93E0 for ; Thu, 6 Jun 2013 10:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQg8fGYG6Ros for ; Thu, 6 Jun 2013 10:17:22 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.5]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD321F9339 for ; Thu, 6 Jun 2013 10:17:21 -0700 (PDT) Received: from [216.82.250.179:30404] by server-5.bemta-12.messagelabs.com id F8/53-14016-A14C0B15; Thu, 06 Jun 2013 17:17:14 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-210.messagelabs.com!1370539033!7985869!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 1620 invoked from network); 6 Jun 2013 17:17:14 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jun 2013 17:17:14 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 6 Jun 2013 13:17:09 -0400 From: Adam Montville To: Rainer Enders , Sean Turner , "Adam W. Montville" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5klzeGAgAICpoCAASM7EA== Date: Thu, 6 Jun 2013 17:17:08 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F2C5E@CISEXCHANGE1.msisac.org.local> References: <51ADE797.70900@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:17:26 -0000 I guess this is a question for Dan, Kathleen, and perhaps, Sean: Where do = we stand right now? What work does the *charter* need to be presentable?=20= For everyone else on the list: Does the charter look "good" and workable? Adam -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ra= iner Enders Sent: Wednesday, June 05, 2013 12:56 PM To: Sean Turner; Adam W. Montville Cc: sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I feel this workgroup will address a very relevant problem. A question for= clarification that has been on my mind for a while. I assume sacm will no= t address the issue of lying endpoints or the verification of endpoint ide= ntity and/or state? Can someone confirm that this is out of scope? Thank you. On 6/4/13 6:11 AM, "Sean Turner" wrote: >Adam, > >Thanks for driving this forward. This looks a lot better to me. >Hopefully Gunnar can get his comments in soon and we we can see where=20 >we stand then. > >spt > >On 6/2/13 11:57 AM, Adam W. Montville wrote: >> All: >> >> I've taken the charter >>(http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments=20 >>submitted in a variety of threads >>(http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and=20 >>put the following together. >> >> I would love to see a dramatic increase in SACM participation=20 >>throughout this month - especially relating to the charter, which=20 >>should be our primary focus at this point, and then limited to the=20 >>first several milestones. >> >> My concern is that SACM momentum is trailing off at a point when it=20 >>needs to be maintaining, if not increasing, from that level we saw at=20= >>IETF 86. >> >> The following is the modified charter text: >> >> Securing information and the systems that store, process, and=20 >>transmit that information is a challenging task for organizations of=20 >>all sizes, and many security practitioners spend much of their time on=20= >>manual processes. Standardized processes to collect, verify, and=20 >>update security system configurations would allow easier automation of=20= >>the processes. Automating these routine tasks would free security=20 >>practitioners to focus on high priority tasks, and should improve=20 >>operators' ability to prioritize risk based on timely information=20 >>about threats and vulnerabilities. This working group will define=20 >>security automation protocols and data format standards in support of=20= >>information security processes and practices. These standards will=20 >>help security practitioners to be more effective by automating routine=20= >>tasks related to client and server security, freeing them to focus on=20= >>more advanced tasks. The initial focus of this work is to address=20 >>enterprise use cases pertaining to the ass > es >> sment of endpoint posture (using the definitions of Endpoint and=20 >>Posture from RFC 5209). >> >> The working group will, whenever reasonable and possible, reuse=20 >>existing protocols, mechanisms, information and data models. Of=20 >>particular interest to this working group are existing industry=20 >>standards, preferably IETF standards, that could support automation of=20= >>asset, change, configuration, and vulnerability management. >> >> The working group will define: >> >> 1. A set of standards to enable assessment of endpoint posture. This=20= >>area of focus provides for necessary language and data format=20 >>specifications. >> >> 2. A set of standards for interacting with repositories of content=20 >>related to assessment of endpoint posture. >> >> Assessment of endpoint posture assessment entails the following=20 >>general >>steps: >> >> 1. Relevant endpoints are identified and classified based on the=20 >>targets of the policy/policies to be evaluated >> >> 2. For each endpoint, determine what elements of posture information=20= >>to collect based on the policy/policies to be evaluated >> >> 3. For each element of the endpoint posture data, identify the=20 >>mechanism for data collection and what content is needed, if any, to=20 >>support data collection >> >> 4. Retrieve any content needed for data collection. Configuration=20 >>checks pertaining to a particular posture element may be used to=20 >>support data collection. >> >> 5. Harvest the actual values pertaining to posture elements=20 >>identified in step 3 from the endpoint. >> >> 6. Report collected endpoint posture as identified in step 2. This=20 >>will likely be done on an individual basis for each identified=20 >>endpoint, requiring aggregation of data collected from multiple=20 >>endpoints as needed based on the identified policy. >> >> This approach to endpoint posture collection enables multiple=20 >>policies to be evaluated based on a single data collection activity.=20 >>Policies will be evaluated by comparing available endpoint posture=20 >>data according to rules expressed in the policy. Typically, these=20 >>rules will compare the actual value against an expected value or range=20= >>for specific posture elements. In some cases, the posture element may=20= >>pertain to software installation state, in which case the actual and=20 >>expected values may be "installed" or "not installed." Evaluation of=20 >>multiple posture elements may be combined using Boolean logic. >> >> Repository protocols are needed to store, update, and retrieve=20 >>configuration checks and other types of content required for posture=20 >>assessment (see step 2 above). A content repository is expected to=20 >>house specific versions of checklists (i.e. benchmarks), may be=20 >>required to satisfy different use cases (i.e. a NEA-specific use vs. a=20= >>generally applicable assessment used during continuous monitoring). =20 >>In addition, content repositories are expected to store up-to-date=20 >>dictionary of specific enumerations, such as those used for=20 >>configuration element identifiers, asset classifications, vulnerability = identifiers, and so on. >> >> This working group will achieve the following deliverables: >> >> - An Informational document on Use Cases >> - An Informational document on Requirements >> - An Informational document on SACM Architecture >> - A standards-track document specifying a protocol and data format=20 >>for retrieving configuration and policy information for driving data=20 >>collection and analysis >> - A standards-track document specifying a protocol and data format=20 >>for collecting actual endpoint posture >> >> The working group will create an overview of related standards work=20 >>Internet-Draft which will document existing work in the IETF or in=20 >>other SDOs which can be used as-is or as a starting point for=20 >>developing solutions to the SACM requirements. The working group may=20 >>decide to make of this document an Informational RFC, but this is not=20= >>a mandatory deliverable. >> >> The working group will work in close coordination with other WGs in=20 >>the IETF (including, but not limited to MILE and NEA) in order to=20 >>create solutions that do not overlap (for example for the repository=20 >>access >>protocol) and can be used or re-used to meet the goals of more than=20 >>one working group. >> >> In accordance with existing IETF processes, the group will=20 >>communicate with and invite participation from other relevant=20 >>standards bodies and regulatory organizations, and if necessary reuse=20= >>existing liaison relationships or request the establishment of new liais= on relationships. >> >> SACM-related efforts are largely aligned, and may overlap, with other=20= >>IETF (and non-IETF) standardization efforts. There are common=20 >>"problems" found in SACM, that may be addressed by the work done in=20 >>SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of=20 >>particular interest to SACM is understanding and respecting the=20 >>distinctions between itself and NEA and MILE. >> >> One way the NEA protocols can be used is as the transport for data=20 >>collected on the endpoint to an external service or data repository=20 >>for further analysis and action. NEA may also serve the purpose of=20 >>carrying data-collection instructions. >> >> The MILE data formats provide a format to describe incident,=20 >>threat-related incident, and indicator information. SACM data formats=20= >>provide ways to understand what endpoints are in your environment,=20 >>whether they meet policy requirements, and their current configuration=20= >>state. The data exchanged in MILE, supplementing the SACM data,=20 >>creates enhanced situational awareness, thus enabling increased=20 >>understanding of current threats and mitigations. The combined SACM=20 >>and MILE data sets become a powerful tool to automate security with=20 >>descriptions of endpoints, known vulnerabilities to those endpoints,=20 >>and thier configurations along with an understanding of layered=20 >>defenses. Then, injecting known threat information with mitigation=20 >>options assists the organization in turning detailed security=20 >>decisions into business-relevant decisions. The MILE protocols, RID=20 >>and ROLIE, enable the exchange of structured data and are designed to=20= >>carry any structured format. While RID may be use > d >> in multiple sharing models and provides multiple communication=20 >>flows (report, query, etc.) with the ability to enable peer-to-peer=20 >>object level security, ROLIE provides a RESTful repository transport=20 >>option with only the need for a browser on the client end, removing=20 >>deployment barriers. >> >> After the work items in the current charter have been submitted to=20 >>and approved by the IESG, the WG will recharter or close. >> >> Goals and Milestones >> >> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >> >> Oct. 2013 - Initial submission of an Internet-Draft on Requirements=20 >>taking into consideration RFC5706 and RFC3535 >> >> Oct. 2013 - Initial submission of an Internet-Draft on SACM=20 >> Architecture >> >> Nov. 2013 - Initial submission of an Internet-Draft on overview of=20 >>related standards work >> >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol=20 >>and data format for retrieving configuration and policy information=20 >>for driving data collection and analysis >> >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol=20 >>and data format for collecting actual endpoint posture >> >> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases=20= >>for consideration as Informational RFC >> >> Apr. 2014 - Submission to the IESG of the Internet-Draft on=20 >>Requirements for consideration as Informational RFC >> >> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM=20 >>Architecture for consideration as Informational RFC >> >> Oct. 2014 - Submission to the IESG of the Internet-Draft for a=20 >>protocol and data format for retrieving configuration and policy=20 >>information for driving data collection and analysis for consideration=20= >>as standards-track RFC >> >> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol=20 >>and data format for collecting actual endpoint posture for=20 >>consideration as standards-track RFC >> >> _______________________________________________ >> 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 ... 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 turners@ieca.com Fri Jun 7 06:49:07 2013 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 DA75521F9619 for ; Fri, 7 Jun 2013 06:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 Ncr7dviZy1Wp for ; Fri, 7 Jun 2013 06:49:02 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.41.255.2]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB321F9476 for ; Fri, 7 Jun 2013 06:49:02 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id E10B347045D92; Fri, 7 Jun 2013 08:48:55 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id C36B5470404AD for ; Fri, 7 Jun 2013 08:48:32 -0500 (CDT) Received: from [173.73.135.101] (port=61068 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ukx1x-0001zH-Ba; Fri, 07 Jun 2013 08:48:37 -0500 Message-ID: <51B1E4B4.3030503@ieca.com> Date: Fri, 07 Jun 2013 09:48:36 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Montville References: <51ADE797.70900@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F2C5E@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F2C5E@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:61068 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 18 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Rainer Enders , "Adam W. Montville" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 13:49:08 -0000 Adam, At this point, figuring out what's to be done with Gunnar's comments is what's left. If there some way to address his comments without rewriting the numbered list that might work. spt On 6/6/13 1:17 PM, Adam Montville wrote: > I guess this is a question for Dan, Kathleen, and perhaps, Sean: Where do we stand right now? What work does the *charter* need to be presentable? > > For everyone else on the list: Does the charter look "good" and workable? > > Adam > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Rainer Enders > Sent: Wednesday, June 05, 2013 12:56 PM > To: Sean Turner; Adam W. Montville > Cc: sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text > > I feel this workgroup will address a very relevant problem. A question for clarification that has been on my mind for a while. I assume sacm will not address the issue of lying endpoints or the verification of endpoint identity and/or state? Can someone confirm that this is out of scope? > Thank you. > > > > On 6/4/13 6:11 AM, "Sean Turner" wrote: > >> Adam, >> >> Thanks for driving this forward. This looks a lot better to me. >> Hopefully Gunnar can get his comments in soon and we we can see where >> we stand then. >> >> spt >> >> On 6/2/13 11:57 AM, Adam W. Montville wrote: >>> All: >>> >>> I've taken the charter >>> (http://datatracker.ietf.org/doc/charter-ietf-sacm/) and comments >>> submitted in a variety of threads >>> (http://www.ietf.org/mail-archive/web/sacm/current/threads.html) and >>> put the following together. >>> >>> I would love to see a dramatic increase in SACM participation >>> throughout this month - especially relating to the charter, which >>> should be our primary focus at this point, and then limited to the >>> first several milestones. >>> >>> My concern is that SACM momentum is trailing off at a point when it >>> needs to be maintaining, if not increasing, from that level we saw at >>> IETF 86. >>> >>> The following is the modified charter text: >>> >>> Securing information and the systems that store, process, and >>> transmit that information is a challenging task for organizations of >>> all sizes, and many security practitioners spend much of their time on >>> manual processes. Standardized processes to collect, verify, and >>> update security system configurations would allow easier automation of >>> the processes. Automating these routine tasks would free security >>> practitioners to focus on high priority tasks, and should improve >>> operators' ability to prioritize risk based on timely information >>> about threats and vulnerabilities. This working group will define >>> security automation protocols and data format standards in support of >>> information security processes and practices. These standards will >>> help security practitioners to be more effective by automating routine >>> tasks related to client and server security, freeing them to focus on >>> more advanced tasks. The initial focus of this work is to address >>> enterprise use cases pertaining to the ass >> es >>> sment of endpoint posture (using the definitions of Endpoint and >>> Posture from RFC 5209). >>> >>> The working group will, whenever reasonable and possible, reuse >>> existing protocols, mechanisms, information and data models. Of >>> particular interest to this working group are existing industry >>> standards, preferably IETF standards, that could support automation of >>> asset, change, configuration, and vulnerability management. >>> >>> The working group will define: >>> >>> 1. A set of standards to enable assessment of endpoint posture. This >>> area of focus provides for necessary language and data format >>> specifications. >>> >>> 2. A set of standards for interacting with repositories of content >>> related to assessment of endpoint posture. >>> >>> Assessment of endpoint posture assessment entails the following >>> general >>> steps: >>> >>> 1. Relevant endpoints are identified and classified based on the >>> targets of the policy/policies to be evaluated >>> >>> 2. For each endpoint, determine what elements of posture information >>> to collect based on the policy/policies to be evaluated >>> >>> 3. For each element of the endpoint posture data, identify the >>> mechanism for data collection and what content is needed, if any, to >>> support data collection >>> >>> 4. Retrieve any content needed for data collection. Configuration >>> checks pertaining to a particular posture element may be used to >>> support data collection. >>> >>> 5. Harvest the actual values pertaining to posture elements >>> identified in step 3 from the endpoint. >>> >>> 6. Report collected endpoint posture as identified in step 2. This >>> will likely be done on an individual basis for each identified >>> endpoint, requiring aggregation of data collected from multiple >>> endpoints as needed based on the identified policy. >>> >>> This approach to endpoint posture collection enables multiple >>> policies to be evaluated based on a single data collection activity. >>> Policies will be evaluated by comparing available endpoint posture >>> data according to rules expressed in the policy. Typically, these >>> rules will compare the actual value against an expected value or range >>> for specific posture elements. In some cases, the posture element may >>> pertain to software installation state, in which case the actual and >>> expected values may be "installed" or "not installed." Evaluation of >>> multiple posture elements may be combined using Boolean logic. >>> >>> Repository protocols are needed to store, update, and retrieve >>> configuration checks and other types of content required for posture >>> assessment (see step 2 above). A content repository is expected to >>> house specific versions of checklists (i.e. benchmarks), may be >>> required to satisfy different use cases (i.e. a NEA-specific use vs. a >>> generally applicable assessment used during continuous monitoring). >>> In addition, content repositories are expected to store up-to-date >>> dictionary of specific enumerations, such as those used for >>> configuration element identifiers, asset classifications, vulnerability identifiers, and so on. >>> >>> This working group will achieve the following deliverables: >>> >>> - An Informational document on Use Cases >>> - An Informational document on Requirements >>> - An Informational document on SACM Architecture >>> - A standards-track document specifying a protocol and data format >>> for retrieving configuration and policy information for driving data >>> collection and analysis >>> - A standards-track document specifying a protocol and data format >>> for collecting actual endpoint posture >>> >>> The working group will create an overview of related standards work >>> Internet-Draft which will document existing work in the IETF or in >>> other SDOs which can be used as-is or as a starting point for >>> developing solutions to the SACM requirements. The working group may >>> decide to make of this document an Informational RFC, but this is not >>> a mandatory deliverable. >>> >>> The working group will work in close coordination with other WGs in >>> the IETF (including, but not limited to MILE and NEA) in order to >>> create solutions that do not overlap (for example for the repository >>> access >>> protocol) and can be used or re-used to meet the goals of more than >>> one working group. >>> >>> In accordance with existing IETF processes, the group will >>> communicate with and invite participation from other relevant >>> standards bodies and regulatory organizations, and if necessary reuse >>> existing liaison relationships or request the establishment of new liaison relationships. >>> >>> SACM-related efforts are largely aligned, and may overlap, with other >>> IETF (and non-IETF) standardization efforts. There are common >>> "problems" found in SACM, that may be addressed by the work done in >>> SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of >>> particular interest to SACM is understanding and respecting the >>> distinctions between itself and NEA and MILE. >>> >>> One way the NEA protocols can be used is as the transport for data >>> collected on the endpoint to an external service or data repository >>> for further analysis and action. NEA may also serve the purpose of >>> carrying data-collection instructions. >>> >>> The MILE data formats provide a format to describe incident, >>> threat-related incident, and indicator information. SACM data formats >>> provide ways to understand what endpoints are in your environment, >>> whether they meet policy requirements, and their current configuration >>> state. The data exchanged in MILE, supplementing the SACM data, >>> creates enhanced situational awareness, thus enabling increased >>> understanding of current threats and mitigations. The combined SACM >>> and MILE data sets become a powerful tool to automate security with >>> descriptions of endpoints, known vulnerabilities to those endpoints, >>> and thier configurations along with an understanding of layered >>> defenses. Then, injecting known threat information with mitigation >>> options assists the organization in turning detailed security >>> decisions into business-relevant decisions. The MILE protocols, RID >>> and ROLIE, enable the exchange of structured data and are designed to >>> carry any structured format. While RID may be use >> d >>> in multiple sharing models and provides multiple communication >>> flows (report, query, etc.) with the ability to enable peer-to-peer >>> object level security, ROLIE provides a RESTful repository transport >>> option with only the need for a browser on the client end, removing >>> deployment barriers. >>> >>> After the work items in the current charter have been submitted to >>> and approved by the IESG, the WG will recharter or close. >>> >>> Goals and Milestones >>> >>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>> >>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>> taking into consideration RFC5706 and RFC3535 >>> >>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>> Architecture >>> >>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>> related standards work >>> >>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>> and data format for retrieving configuration and policy information >>> for driving data collection and analysis >>> >>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>> and data format for collecting actual endpoint posture >>> >>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases >>> for consideration as Informational RFC >>> >>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>> Requirements for consideration as Informational RFC >>> >>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>> Architecture for consideration as Informational RFC >>> >>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>> protocol and data format for retrieving configuration and policy >>> information for driving data collection and analysis for consideration >>> as standards-track RFC >>> >>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol >>> and data format for collecting actual endpoint posture for >>> consideration as standards-track RFC >>> >>> _______________________________________________ >>> 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 > > ... > > 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. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From Adam.Montville@cisecurity.org Fri Jun 7 08:08:00 2013 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 7EB7221F8FBE for ; Fri, 7 Jun 2013 08:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV2NeyuHtGAB for ; Fri, 7 Jun 2013 08:07:50 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id 747D721F8E93 for ; Fri, 7 Jun 2013 08:07:50 -0700 (PDT) Received: from [216.82.253.243:44959] by server-9.bemta-7.messagelabs.com id 28/D4-28694-547F1B15; Fri, 07 Jun 2013 15:07:49 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-10.tower-171.messagelabs.com!1370617668!17965705!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 16085 invoked from network); 7 Jun 2013 15:07:48 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-10.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 15:07:48 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 11:07:42 -0400 From: Adam Montville To: "Waltermire, David A." , Gunnar Engelbach , "Adam W. Montville" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4A== Date: Fri, 7 Jun 2013 15:07:42 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:08:00 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Wednesday, June 05, 2013 7:06 AM > To: Gunnar Engelbach; Adam W. Montville > Cc: sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > Great catch on change notification! The challenge with polling on a peri= odic > basis is that the sample rate needs to be twice the rate of change. Usin= g > periodic data collection, there is a potential risk of missing a critica= l security- > related change event that might indicate an attack is underway. If polli= ng is > performed outside the attack window, it is possible that the attack won'= t be > noticed. Is this becoming too prescriptive in a way? You rightly point out that at= tacks could be missed with a polling mechanism, but how are agent-less sol= utions going to implement anything else?=20 Also, is this the type of information we need to have in a charter or is t= his better applied in the work products of the WG? I think=20the latter. >=20 > Policy driven assessment, as you have written below, can be used to addr= ess > this type of detection using most of the same bits and bytes. To suppor= t > event-driven notification, the endpoint assessment software will need to= be > told what events to collect and pass on. Most of what is described in st= eps 1- > 4 of the draft charter still apply in setting up the event-driven collec= tion > environment. What is different is how steps 5 and 6 work. For step 5, th= e > values are not harvested per se; they are generated based on change > notifications. For step 6, incremental changes are reported on a continu= ous > basis, until the endpoint is instructed not to collect those events anym= ore. Step 5 would need to be updated to accommodate change notification, such t= hat results are either harvested or reported. But, again, I think this be= longs in our work products and not the charter. >=20 > This is a desirable capability for end-user organizations and I believe = it should > be reflected in the charter. The more we carry on this discussion the more I question having anything o= ther than an exemplary list of steps to help describe the concept of "conf= iguration assessment." We can add language to the charter without needing= to enumerate all the possible use cases (we have a document for that alre= ady) and then ensure the assessment steps we provide are generic - remembe= r the only reason they were included were to provide additional context fo= r an uninitiated reader to better understand what this WG is about. =20 To be more generic, we can take the list and turn it into something like t= his (I think Sean had not wanted this list to be modified, but...): 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This should be enough to provide context to an external reader to *general= ly* understand the problem space this WG addresses (would be interesting = to validate by getting someone wholly unfamiliar with this problem domain = to review). To me, this is perfectly acceptable - it's possible for the WG to leave th= e details (i.e. policy-driven vs. asset-driven, assessment polling vs. nea= r real-time assessment, and so on) to the Use Case and Architecture docume= nts. Finally, I'd like to point out that the milestones and deliverables for th= is WG, as expressed in the present draft charter, are fairly encompassing = as well. They do not get into the details - especially in light of the le= ngthy list Gunnar shared. >=20 > Sincerely, > Dave >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Gunnar Engelbach > > Sent: Tuesday, June 04, 2013 1:20 PM > > To: Adam W. Montville > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > My primary quibbles are below, but I'd like to start by highlighting > > something Stephen Whitlock said: "...deviations from standard > > configurations (whether by accident or intent) would result in a > notification..." > > > > Going back to Dave Waltermire's proposed architecture, it included > > change notification originating from endpoints which helps feed > > Stephen's ideal, and I don't see an allowance for that in this revisio= n. > > > > Real time compliance/vulnerability notification originating from > > endpoint events is a desirable security goal that I think falls within= > > the scope of this WG. > > > > There is also a significant lag between the formation of a new WG and > > the delivery of usable products. > > > > So, while top-down assessments, seems to be plenty for this WG to gnaw= > > on at the moment, I'd like to also keep bottom-up in mind so that any > > work done now doesn't preclude that as a follow-on. And, preferably, > > makes it possible to quickly add that next. > > > > > > There also seems to be a chicken-and-egg type of thing of selection of= > > policy versus selection of assets as the starting point. I think both= > > are valid so I tried, clumsily, to address that in my revision of the > > assessment steps, to follow. > > > > ---------------------------+++++++++++++--------------------------- > > > > > > > > The components, protocols, and content documents defined by this > > working group can be used in multiple ways such as top-down assessment= > > of policy compliance, notification of compliance posture change > > initiated by a change made on an endpoint, determination of affected > > assets based on reportage of a new vulnerability, ad-hoc queries of sp= ecific > asset settings, etc. > > > > The initial focus of this working group is the performance of top-down= > > policy assessments using the following steps: > > > > > > A policy-driven assessment: > > > > A) The content repository is queried for the content documents that > > codify the policy/policies of interest. > > > > B) Assets are selected that match the criteria of the selected > > policy/policies. The method of selection can include enumeration from= > > known asset inventories, direct query of known assets, network > > discovery, etc. Selection of assets may be further refined by other > > criteria such as ownership, location, role, time of day, etc. > > > > (Note: I used the term "asset" instead of "endpoint" because it > > includes software assets, allowing for assessments of, for example, > > web servers, virtual machine instance settings, a virtualized database= > > instance running on a cluster, etc) > > > > > > Alternatively, and asset-driven assessment: > > > > A) Assets are selected based on a set of criteria (ownership, > > location, role, time of day, etc.). > > > > B) For each asset, determine and retrieve the applicable > > policy/policies from the content repository. > > > > > > For each asset: > > > > 1) Determine what elements of posture information to collect based on > > the policy/policies to be evaluated. > > > > > > 2) For each element of the asset posture data, identify the mechanism > > for data collection and what content is needed, if any, to support > > data collection. > > > > (Note: I assume this means if the collection is via direct endpoint > > query, CMDB retrieval, etc. That means a layer of meta data is needed= > > that we haven't really talked about: authentication information, DB > > host/port, connection type, etc. Since this is an explicit step in > > the process, should that data also be part of the standard?) > > > > > > 3) Harvest the actual values pertaining to posture elements identified= > > in step 3 from the targeted asset(s). > > > > 4) Report collected asset posture. This will likely be done on an > > individual basis for each identified asset , requiring aggregation of > > data collected from multiple asset as needed based on the identified > policy. > > > > > > > > > > > > > > On 6/2/2013 11:57 AM, Adam W. Montville wrote: > > > All: > > > > > > I've taken the charter > > > (http://datatracker.ietf.org/doc/charter-ietf-sacm/) > > and comments submitted in a variety of threads > > (http://www.ietf.org/mail- > > archive/web/sacm/current/threads.html) and put the following together.= > > > > > > I would love to see a dramatic increase in SACM participation > > > throughout > > this month - especially relating to the charter, which should be our > > primary focus at this point, and then limited to the first several mil= estones. > > > > > > My concern is that SACM momentum is trailing off at a point when it > > > needs > > to be maintaining, if not increasing, from that level we saw at IETF 8= 6. > > > > > > The following is the modified charter text: > > > > > > Securing information and the systems that store, process, and > > > transmit that > > information is a challenging task for organizations of all sizes, and > > many security practitioners spend much of their time on manual process= es. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. > > Automating these routine tasks would free security practitioners to > > focus on high priority tasks, and should improve operators' ability to= > > prioritize risk based on timely information about threats and > > vulnerabilities. This working group will define security automation > > protocols and data format standards in support of information security= > > processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks related= > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > > cases pertaining to the ass es > > > sment of endpoint posture (using the definitions of Endpoint and > > > Posture > > from RFC 5209). > > > > > > The working group will, whenever reasonable and possible, reuse > > > existing > > protocols, mechanisms, information and data models. Of particular > > interest to this working group are existing industry standards, > > preferably IETF standards, that could support automation of asset, > > change, configuration, and vulnerability management. > > > > > > The working group will define: > > > > > > 1. A set of standards to enable assessment of endpoint posture. This= > > > area > > of focus provides for necessary language and data format specification= s. > > > > > > 2. A set of standards for interacting with repositories of content > > > related to > > assessment of endpoint posture. > > > > > > Assessment of endpoint posture assessment entails the following > > > general > > steps: > > > > > > 1. Relevant endpoints are identified and classified based on the > > > targets of > > the policy/policies to be evaluated > > > > > > 2. For each endpoint, determine what elements of posture information= > > > to > > collect based on the policy/policies to be evaluated > > > > > > 3. For each element of the endpoint posture data, identify the > > > mechanism > > for data collection and what content is needed, if any, to support > > data collection > > > > > > 4. Retrieve any content needed for data collection. Configuration > > > checks > > pertaining to a particular posture element may be used to support data= > > collection. > > > > > > 5. Harvest the actual values pertaining to posture elements > > > identified in > > step 3 from the endpoint. > > > > > > 6. Report collected endpoint posture as identified in step 2. This > > > will likely > > be done on an individual basis for each identified endpoint, requiring= > > aggregation of data collected from multiple endpoints as needed based > > on the identified policy. > > > > > > This approach to endpoint posture collection enables multiple > > > policies to be > > evaluated based on a single data collection activity. Policies will be= > > evaluated by comparing available endpoint posture data according to > > rules expressed in the policy. Typically, these rules will compare the= > > actual value against an expected value or range for specific posture > > elements. In some cases, the posture element may pertain to software > > installation state, in which case the actual and expected values may > > be "installed" or "not installed." Evaluation of multiple posture elem= ents > may be combined using Boolean logic. > > > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. a NEA-specific use vs. a= > > generally applicable assessment used during continuous monitoring). > > In addition, content repositories are expected to store up-to-date > > dictionary of specific enumerations, such as those used for > > configuration element identifiers, asset classifications, vulnerabilit= y > identifiers, and so on. > > > > > > This working group will achieve the following deliverables: > > > > > > - An Informational document on Use Cases > > > - An Informational document on Requirements > > > - An Informational document on SACM Architecture > > > - A standards-track document specifying a protocol and data format > > > for > > retrieving configuration and policy information for driving data > > collection and analysis > > > - A standards-track document specifying a protocol and data format > > > for > > collecting actual endpoint posture > > > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > > other SDOs which can be used as-is or as a starting point for > > developing solutions to the SACM requirements. The working group may > > decide to make of this document an Informational RFC, but this is not = a > mandatory deliverable. > > > > > > The working group will work in close coordination with other WGs in > > > the > > IETF (including, but not limited to MILE and NEA) in order to create > > solutions that do not overlap (for example for the repository access > > protocol) and can be used or re-used to meet the goals of more than on= e > working group. > > > > > > In accordance with existing IETF processes, the group will > > > communicate > > with and invite participation from other relevant standards bodies and= > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison relationship= s. > > > > > > SACM-related efforts are largely aligned, and may overlap, with > > > other IETF > > (and non-IETF) standardization efforts. There are common "problems" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > > interest to SACM is understanding and respecting the distinctions > > between itself and NEA and MILE. > > > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data- collection instructions. > > > > > > The MILE data formats provide a format=20to describe incident, > > > threat-related > > incident, and indicator information. SACM data formats provide ways > > to understand what endpoints are in your environment, whether they > > meet policy requirements, and their current configuration state. The > > data exchanged in MILE, supplementing the SACM data, creates enhanced > > situational awareness, thus enabling increased understanding of > > current threats and mitigations. The combined SACM and MILE data sets= > > become a powerful tool to automate security with descriptions of > > endpoints, known vulnerabilities to those endpoints, and thier > > configurations along with an understanding of layered defenses. Then,= > > injecting known threat information with mitigation options assists the= > > organization in turning detailed security decisions into > > business-relevant decisions. The MILE protocols, RID and ROLIE, > > enable the exchange of structured data and are designed to carry any > > structured format. While RID may be use d > > > =20in multiple sharing models and provides multiple communication > > > flows > > (report, query, etc.) with the ability to enable peer-to-peer object > > level security, ROLIE provides a RESTful repository transport option > > with only the need for a browser on the client end, removing deploymen= t > barriers. > > > > > > After the work items in the current charter have been submitted to > > > and > > approved by the IESG, the WG will recharter or close. > > > > > > Goals and Milestones > > > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > > taking > > into consideration RFC5706 and RFC3535 > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > > Architecture > > > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > > related > > standards work > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > > and data > > format for retrieving configuration and policy information for driving= > > data collection and analysis > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > > and data > > format for collecting actual endpoint posture > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > > > Cases for > > consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > > Requirements > > for consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > > protocol and > > data format for retrieving configuration and policy information for > > driving data collection and analysis for consideration as > > standards-track RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > > and data > > format for collecting actual endpoint posture=20for consideration as > > standards- track RFC > > > > > > _______________________________________________ > > > 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 >=20 > ... 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 Kent_Landfield@mcafee.com Fri Jun 7 08:38:46 2013 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 371F721F9703 for ; Fri, 7 Jun 2013 08:38: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRe8ODNzAHqg for ; Fri, 7 Jun 2013 08:38:41 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 993DB21F9702 for ; Fri, 7 Jun 2013 08:38:33 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 506f_57f2_cafff367_96f9_4b35_89ab_51a36555ba3c; Fri, 07 Jun 2013 10:38:10 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER1N2.corp.nai.org ([169.254.3.103]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 11:36:23 -0400 From: To: , , , Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6npxNalvQ89Okyx82eII/CXtpkmEx2AgAFcNICAAzXtAP//tC+A Date: Fri, 7 Jun 2013 15:36:22 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF288E70@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF288E70MIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:38:46 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF288E70MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Are we straying from the intent here? Policy driven assessments are normal= ly evaluated against a known good. Is this system running the approved sof= tware, approved services with the recommended configuration and permissions= , etc=85 If we are now talking about an event driven notification architec= ture, are we looking as something like IF-MAP ? This seems to be straying = and expanding the focus of the charter. I thought that was what we were try= ing to avoid. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Friday, June 7, 2013 10:07 AM To: David Waltermire >, Gunnar Engelbach >, "Adam W. Montville" > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Wednesday, June 05, 2013 7:06 AM To: Gunnar Engelbach; Adam W. Montville Cc: sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text Great catch on change notification! The challenge with polling on a periodi= c basis is that the sample rate needs to be twice the rate of change. Using periodic data collection, there is a potential risk of missing a critical s= ecurity- related change event that might indicate an attack is underway. If polling = is performed outside the attack window, it is possible that the attack won't b= e noticed. Is this becoming too prescriptive in a way? You rightly point out that att= acks could be missed with a polling mechanism, but how are agent-less solut= ions going to implement anything else? Also, is this the type of information we need to have in a charter or is th= is better applied in the work products of the WG? I think the latter. Policy driven assessment, as you have written below, can be used to address this type of detection using most of the same bits and bytes. To support event-driven notification, the endpoint assessment software will need to be told what events to collect and pass on. Most of what is described in steps= 1- 4 of the draft charter still apply in setting up the event-driven collectio= n environment. What is different is how steps 5 and 6 work. For step 5, the values are not harvested per se; they are generated based on change notifications. For step 6, incremental changes are reported on a continuous basis, until the endpoint is instructed not to collect those events anymore= . Step 5 would need to be updated to accommodate change notification, such th= at results are either harvested or reported. But, again, I think this belo= ngs in our work products and not the charter. This is a desirable capability for end-user organizations and I believe it = should be reflected in the charter. The more we carry on this discussion the more I question having anything ot= her than an exemplary list of steps to help describe the concept of "config= uration assessment." We can add language to the charter without needing to= enumerate all the possible use cases (we have a document for that already)= and then ensure the assessment steps we provide are generic - remember the= only reason they were included were to provide additional context for an u= ninitiated reader to better understand what this WG is about. To be more generic, we can take the list and turn it into something like th= is (I think Sean had not wanted this list to be modified, but...): 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This should be enough to provide context to an external reader to *generall= y* understand the problem space this WG addresses (would be interesting to= validate by getting someone wholly unfamiliar with this problem domain to = review). To me, this is perfectly acceptable - it's possible for the WG to leave the= details (i.e. policy-driven vs. asset-driven, assessment polling vs. near = real-time assessment, and so on) to the Use Case and Architecture documents= . Finally, I'd like to point out that the milestones and deliverables for thi= s WG, as expressed in the present draft charter, are fairly encompassing as= well. They do not get into the details - especially in light of the lengt= hy list Gunnar shared. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] On Behalf > Of Gunnar Engelbach > Sent: Tuesday, June 04, 2013 1:20 PM > To: Adam W. Montville > Cc: sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text > > > My primary quibbles are below, but I'd like to start by highlighting > something Stephen Whitlock said: "...deviations from standard > configurations (whether by accident or intent) would result in a notification..." > > Going back to Dave Waltermire's proposed architecture, it included > change notification originating from endpoints which helps feed > Stephen's ideal, and I don't see an allowance for that in this revision. > > Real time compliance/vulnerability notification originating from > endpoint events is a desirable security goal that I think falls within > the scope of this WG. > > There is also a significant lag between the formation of a new WG and > the delivery of usable products. > > So, while top-down assessments, seems to be plenty for this WG to gnaw > on at the moment, I'd like to also keep bottom-up in mind so that any > work done now doesn't preclude that as a follow-on. And, preferably, > makes it possible to quickly add that next. > > > There also seems to be a chicken-and-egg type of thing of selection of > policy versus selection of assets as the starting point. I think both > are valid so I tried, clumsily, to address that in my revision of the > assessment steps, to follow. > > ---------------------------+++++++++++++--------------------------- > > > > The components, protocols, and content documents defined by this > working group can be used in multiple ways such as top-down assessment > of policy compliance, notification of compliance posture change > initiated by a change made on an endpoint, determination of affected > assets based on reportage of a new vulnerability, ad-hoc queries of speci= fic asset settings, etc. > > The initial focus of this working group is the performance of top-down > policy assessments using the following steps: > > > A policy-driven assessment: > > A) The content repository is queried for the content documents that > codify the policy/policies of interest. > > B) Assets are selected that match the criteria of the selected > policy/policies. The method of selection can include enumeration from > known asset inventories, direct query of known assets, network > discovery, etc. Selection of assets may be further refined by other > criteria such as ownership, location, role, time of day, etc. > > (Note: I used the term "asset" instead of "endpoint" because it > includes software assets, allowing for assessments of, for example, > web servers, virtual machine instance settings, a virtualized database > instance running on a cluster, etc) > > > Alternatively, and asset-driven assessment: > > A) Assets are selected based on a set of criteria (ownership, > location, role, time of day, etc.). > > B) For each asset, determine and retrieve the applicable > policy/policies from the content repository. > > > For each asset: > > 1) Determine what elements of posture information to collect based on > the policy/policies to be evaluated. > > > 2) For each element of the asset posture data, identify the mechanism > for data collection and what content is needed, if any, to support > data collection. > > (Note: I assume this means if the collection is via direct endpoint > query, CMDB retrieval, etc. That means a layer of meta data is needed > that we haven't really talked about: authentication information, DB > host/port, connection type, etc. Since this is an explicit step in > the process, should that data also be part of the standard?) > > > 3) Harvest the actual values pertaining to posture elements identified > in step 3 from the targeted asset(s). > > 4) Report collected asset posture. This will likely be done on an > individual basis for each identified asset , requiring aggregation of > data collected from multiple asset as needed based on the identified policy. > > > > > > > On 6/2/2013 11:57 AM, Adam W. Montville wrote: > > All: > > > > I've taken the charter > > (http://datatracker.ietf.org/doc/charter-ietf-sacm/) > and comments submitted in a variety of threads > (http://www.ietf.org/mail- > archive/web/sacm/current/threads.html) and put the following together. > > > > I would love to see a dramatic increase in SACM participation > > throughout > this month - especially relating to the charter, which should be our > primary focus at this point, and then limited to the first several milest= ones. > > > > My concern is that SACM momentum is trailing off at a point when it > > needs > to be maintaining, if not increasing, from that level we saw at IETF 86. > > > > The following is the modified charter text: > > > > Securing information and the systems that store, process, and > > transmit that > information is a challenging task for organizations of all sizes, and > many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the ass es > > sment of endpoint posture (using the definitions of Endpoint and > > Posture > from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse > > existing > protocols, mechanisms, information and data models. Of particular > interest to this working group are existing industry standards, > preferably IETF standards, that could support automation of asset, > change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area > of focus provides for necessary language and data format specifications. > > > > 2. A set of standards for interacting with repositories of content > > related to > assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following > > general > steps: > > > > 1. Relevant endpoints are identified and classified based on the > > targets of > the policy/policies to be evaluated > > > > 2. For each endpoint, determine what elements of posture information > > to > collect based on the policy/policies to be evaluated > > > > 3. For each element of the endpoint posture data, identify the > > mechanism > for data collection and what content is needed, if any, to support > data collection > > > > 4. Retrieve any content needed for data collection. Configuration > > checks > pertaining to a particular posture element may be used to support data > collection. > > > > 5. Harvest the actual values pertaining to posture elements > > identified in > step 3 from the endpoint. > > > > 6. Report collected endpoint posture as identified in step 2. This > > will likely > be done on an individual basis for each identified endpoint, requiring > aggregation of data collected from multiple endpoints as needed based > on the identified policy. > > > > This approach to endpoint posture collection enables multiple > > policies to be > evaluated based on a single data collection activity. Policies will be > evaluated by comparing available endpoint posture data according to > rules expressed in the policy. Typically, these rules will compare the > actual value against an expected value or range for specific posture > elements. In some cases, the posture element may pertain to software > installation state, in which case the actual and expected values may > be "installed" or "not installed." Evaluation of multiple posture element= s may be combined using Boolean logic. > > > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. a NEA-specific use vs. a > generally applicable assessment used during continuous monitoring). > In addition, content repositories are expected to store up-to-date > dictionary of specific enumerations, such as those used for > configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format > > for > retrieving configuration and policy information for driving data > collection and analysis > > - A standards-track document specifying a protocol and data format > > for > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > > > The working group will work in close coordination with other WGs in > > the > IETF (including, but not limited to MILE and NEA) in order to create > solutions that do not overlap (for example for the repository access > protocol) and can be used or re-used to meet the goals of more than one working group. > > > > In accordance with existing IETF processes, the group will > > communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > > > SACM-related efforts are largely aligned, and may overlap, with > > other IETF > (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data- collection instructions. > > > > The MILE data formats provide a format to describe incident, > > threat-related > incident, and indicator information. SACM data formats provide ways > to understand what endpoints are in your environment, whether they > meet policy requirements, and their current configuration state. The > data exchanged in MILE, supplementing the SACM data, creates enhanced > situational awareness, thus enabling increased understanding of > current threats and mitigations. The combined SACM and MILE data sets > become a powerful tool to automate security with descriptions of > endpoints, known vulnerabilities to those endpoints, and thier > configurations along with an understanding of layered defenses. Then, > injecting known threat information with mitigation options assists the > organization in turning detailed security decisions into > business-relevant decisions. The MILE protocols, RID and ROLIE, > enable the exchange of structured data and are designed to carry any > structured format. While RID may be use d > > in multiple sharing models and provides multiple communication > > flows > (report, query, etc.) with the ability to enable peer-to-peer object > level security, ROLIE provides a RESTful repository transport option > with only the need for a browser on the client end, removing deployment barriers. > > > > After the work items in the current charter have been submitted to > > and > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > taking > into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > related > standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > and data > format for retrieving configuration and policy information for driving > data collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > and data > format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > > Cases for > consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > Requirements > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis for consideration as > standards-track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > and data > format for collecting actual endpoint posture for consideration as > standards- track RFC > > > > _______________________________________________ > > 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 ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF288E70MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Are we straying from the intent here?  Policy driven assessments = are normally evaluated against a known good.  Is this system running t= he approved software, approved services with the recommended configuration = and permissions, etc=85  If we are now talking about an event driven notification architecture, are we looking as somethi= ng like IF-MAP ?  This seems to be straying and expanding the focus of= the charter. I thought that was what we were trying to avoid.

Kent Landfield

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

From: Adam Montville <Adam.Montville@cisecurity.org>= ;
Date: Friday, June 7, 2013 10:07 AM=
To: David Waltermire <david.waltermire@nist.gov>, Gunna= r Engelbach <gunnar.= engelbach@threatguard.com>, "Adam W. Montville" <adam@stoicsecurity.com&g= t;
Cc: "sacm@ietf.org" <sacm@i= etf.org>
Subject: Re: [sacm] Updated Candida= te Charter Text


-----Original Message-----
Waltermire, David A.
Sent: Wednesday, June 05, 2013 7:06 AM
To: Gunnar Engelbach; Adam W. Montville
Subject: Re: [sacm] Updated Candidate Charter Text
Great catch on change notification! The challenge with polling on a pe= riodic
basis is that the sample rate needs to be twice the rate of change. Us= ing
periodic data collection, there is a potential risk of missing a criti= cal security-
related change event that might indicate an attack is underway. If pol= ling is
performed outside the attack window, it is possible that the attack wo= n't be
noticed.

Is this becoming too prescriptive in a way?  You rightly poi= nt out that attacks could be missed with a polling mechanism, but how are a= gent-less solutions going to implement anything else?

Also, is this the type of information we need to have in a charter or = is this better applied in the work products of the WG?  I think t= he latter.


Policy driven assessment, as you have written below, can be used to ad= dress
this type of detection using most of the same bits and bytes. &nb= sp;To support
event-driven notification, the endpoint assessment software will need = to be
told what events to collect and pass on. Most of what is described in = steps 1-
4 of the draft charter still apply in setting up the event-driven coll= ection
environment. What is different is how steps 5 and 6 work. For step 5, = the
values are not harvested per se; they are generated based on change
notifications. For step 6, incremental changes are reported on a conti= nuous
basis, until the endpoint is instructed not to collect those events an= ymore.

Step 5 would need to be updated to accommodate change notification, su= ch that results are either harvested or reported.  But, again, I = think this belongs in our work products and not the charter.

This is a desirable capability for end-user organizations and I believ= e it should
be reflected in the charter.

The more we carry on this discussion the more I question having anythi= ng other than an exemplary list of steps to help describe the concept of &q= uot;configuration assessment."  We can add language to the c= harter without needing to enumerate all the possible use cases (we have a document for that already) and then ensure the assess= ment steps we provide are generic - remember the only reason they were incl= uded were to provide additional context for an uninitiated reader to better= understand what this WG is about.  

To be more generic, we can take the list and turn it into something li= ke this (I think Sean had not wanted this list to be modified, but...):

1. Identify endpoints
2. Determine specific endpoint elements to assess
3. Collect actual value of elements
4. Compare actual element values to expected element values
5. Report results

This should be enough to provide context to an external reader to *gen= erally* understand the problem space  this WG addresses (would be= interesting to validate by getting someone wholly unfamiliar with this pro= blem domain to review).

To me, this is perfectly acceptable - it's possible for the WG to leav= e the details (i.e. policy-driven vs. asset-driven, assessment polling vs. = near real-time assessment, and so on) to the Use Case and Architecture docu= ments.

Finally, I'd like to point out that the milestones and deliverables fo= r this WG, as expressed in the present draft charter, are fairly encompassi= ng as well.  They do not get into the details - especially in lig= ht of the lengthy list Gunnar shared.

Sincerely,
Dave
> -----Original Message-----
> Of Gunnar Engelbach
> Sent: Tuesday, June 04, 2013 1:20 PM
> To: Adam W. Montville
> Subject: Re: [sacm] Updated Candidate Charter Text
>
>
> My primary quibbles are below, but I'd like to start by highlight= ing
> something Stephen Whitlock said:  "...deviations f= rom standard
> configurations (whether by accident or intent) would result in a<= /div>
notification..."
>
> Going back to Dave Waltermire's proposed architecture, it include= d
> change notification originating from endpoints which helps feed
> Stephen's ideal, and I don't see an allowance for that in this re= vision.
>
> Real time compliance/vulnerability notification originating from<= /div>
> endpoint events is a desirable security goal that I think falls w= ithin
> the scope of this WG.
>
> There is also a significant lag between the formation of a new WG= and
> the delivery of usable products.
>
> So, while top-down assessments, seems to be plenty for this WG to= gnaw
> on at the moment, I'd like to also keep bottom-up in mind so that= any
> work done now doesn't preclude that as a follow-on.  An= d, preferably,
> makes it possible to quickly add that next.
>
>
> There also seems to be a chicken-and-egg type of thing of selecti= on of
> policy versus selection of assets as the starting point. &nb= sp;I think both
> are valid so I tried, clumsily, to address that in my revision of= the
> assessment steps, to follow.
>
> ---------------------------+++++++= 3;+++++---------------------------
>
>
>
> The components, protocols, and content documents defined by this<= /div>
> working group can be used in multiple ways such as top-down asses= sment
> of policy compliance, notification of compliance posture change
> initiated by a change made on an endpoint, determination of affec= ted
> assets based on reportage of a new vulnerability, ad-hoc queries = of specific
asset settings, etc.
>
> The initial focus of this working group is the performance of top= -down
> policy assessments using the following steps:
>
>
> A policy-driven assessment:
>
> A) The content repository is queried for the content documents th= at
> codify the policy/policies of interest.
>
> B) Assets are selected that match the criteria of the selected
> policy/policies.  The method of selection can include e= numeration from
> known asset inventories, direct query of known assets, network
> discovery, etc.  Selection of assets may be further ref= ined by other
> criteria such as ownership, location, role, time of day, etc.
>
> (Note:  I used the term "asset" instead of &q= uot;endpoint" because it
> includes software assets, allowing for assessments of, for exampl= e,
> web servers, virtual machine instance settings, a virtualized dat= abase
> instance running on a cluster, etc)
>
>
> Alternatively, and asset-driven assessment:
>
> A) Assets are selected based on a set of criteria (ownership,
> location, role, time of day, etc.).
>
> B) For each asset, determine and retrieve the applicable
> policy/policies from the content repository.
>
>
> For each asset:
>
> 1) Determine what elements of posture information to collect base= d on
> the policy/policies to be evaluated.
>
>
> 2) For each element of the asset posture data, identify the mecha= nism
> for data collection and what content is needed, if any, to suppor= t
> data collection.
>
> (Note:  I assume this means if the collection is via di= rect endpoint
> query, CMDB retrieval, etc.  That means a layer of meta= data is needed
> that we haven't really talked about:  authentication in= formation, DB
> host/port, connection type, etc.  Since this is an expl= icit step in
> the process, should that data also be part of the standard?)
>
>
> 3) Harvest the actual values pertaining to posture elements ident= ified
> in step 3 from the targeted asset(s).
>
> 4) Report collected asset posture.  This will likely be= done on an
> individual basis for each identified asset , requiring aggregatio= n of
> data collected from multiple asset as needed based on the identif= ied
policy.
>
>
>
>
>
>
> On 6/2/2013 11:57 AM, Adam W. Montville wrote:
> > All:
> >
> > I've taken the charter
> and comments submitted in a variety of threads
> archive/web/sacm/current/threads.html) and put the following toge= ther.
> >
> > I would love to see a dramatic increase in SACM participatio= n
> > throughout
> this month - especially relating to the charter, which should be = our
> primary focus at this point, and then limited to the first severa= l milestones.
> >
> > My concern is that SACM momentum is trailing off at a point = when it
> > needs
> to be maintaining, if not increasing, from that level we saw at I= ETF 86.
> >
> > The following is the modified charter text:
> >
> > Securing information and the systems that store, process, an= d
> > transmit that
> information is a challenging task for organizations of all sizes,= and
> many security practitioners spend much of their time on manual pr= ocesses.
> Standardized processes to collect, verify, and update security sy= stem
> configurations would allow easier automation of the processes.
> Automating these routine tasks would free security practitioners = to
> focus on high priority tasks, and should improve operators' abili= ty to
> prioritize risk based on timely information about threats and
> vulnerabilities. This working group will define security automati= on
> protocols and data format standards in support of information sec= urity
> processes and practices. These standards will help security
> practitioners to be more effective by automating routine tasks re= lated
> to client and server security, freeing them to focus on more adva= nced
> tasks. The initial focus of this work is to address enterprise us= e
> cases pertaining to the ass  es
> >   sment of endpoint posture (using the definitions= of Endpoint and
> > Posture
> from RFC 5209).
> >
> > The working group will, whenever reasonable and possible, re= use
> > existing
> protocols, mechanisms, information and data models. Of particular=
> interest to this working group are existing industry standards,
> preferably IETF standards, that could support automation of asset= ,
> change, configuration, and vulnerability management.
> >
> > The working group will define:
> >
> > 1. A set of standards to enable assessment of endpoint postu= re. This
> > area
> of focus provides for necessary language and data format specific= ations.
> >
> > 2. A set of standards for interacting with repositories of c= ontent
> > related to
> assessment of endpoint posture.
> >
> > Assessment of endpoint posture assessment entails the follow= ing
> > general
> steps:
> >
> > 1. Relevant endpoints are identified and classified based on= the
> > targets of
> the policy/policies to be evaluated
> >
> > 2. For each endpoint, determine what elements of posture inf= ormation
> > to
> collect based on the policy/policies to be evaluated
> >
> > 3. For each element of the endpoint posture data, identify t= he
> > mechanism
> for data collection and what content is needed, if any, to suppor= t
> data collection
> >
> > 4. Retrieve any content needed for data collection. &nb= sp;Configuration
> > checks
> pertaining to a particular posture element may be used to support= data
> collection.
> >
> > 5. Harvest the actual values pertaining to posture elements<= /div>
> > identified in
> step 3 from the endpoint.
> >
> > 6. Report collected endpoint posture as identified in step 2= .  This
> > will likely
> be done on an individual basis for each identified endpoint, requ= iring
> aggregation of data collected from multiple endpoints as needed b= ased
> on the identified policy.
> >
> > This approach to endpoint posture collection enables multipl= e
> > policies to be
> evaluated based on a single data collection activity. Policies wi= ll be
> evaluated by comparing available endpoint posture data according = to
> rules expressed in the policy. Typically, these rules will compar= e the
> actual value against an expected value or range for specific post= ure
> elements. In some cases, the posture element may pertain to softw= are
> installation state, in which case the actual and expected values = may
> be "installed" or "not installed." Evaluation= of multiple posture elements
may be combined using Boolean logic.
> >
> > Repository protocols are needed to store, update, and retrie= ve
> configuration checks and other types of content required for post= ure
> assessment (see step 2 above).  A content repository is= expected to
> house specific versions of checklists (i.e. benchmarks), may be
> required to satisfy different use cases (i.e. a NEA-specific use = vs. a
> generally applicable assessment used during continuous monitoring= ).
> In addition, content repositories are expected to store up-to-dat= e
> dictionary of specific enumerations, such as those used for
> configuration element identifiers, asset classifications, vulnera= bility
identifiers, and so on.
> >
> > This working group will achieve the following deliverables:<= /div>
> >
> > - An Informational document on Use Cases
> > - An Informational document on Requirements
> > - An Informational document on SACM Architecture
> > - A standards-track document specifying a protocol and data = format
> > for
> retrieving configuration and policy information for driving data<= /div>
> collection and analysis
> > - A standards-track document specifying a protocol and data = format
> > for
> collecting actual endpoint posture
> >
> > The working group will create an overview of related standar= ds work
> Internet-Draft which will document existing work in the IETF or i= n
> other SDOs which can be used as-is or as a starting point for
> developing solutions to the SACM requirements. The working group = may
> decide to make of this document an Informational RFC, but this is= not a
mandatory deliverable.
> >
> > The working group will work in close coordination with other= WGs in
> > the
> IETF (including, but not limited to MILE and NEA) in order to cre= ate
> solutions that do not overlap (for example for the repository acc= ess
> protocol) and can be used or re-used to meet the goals of more th= an one
working group.
> >
> > In accordance with existing IETF processes, the group will
> > communicate
> with and invite participation from other relevant standards bodie= s and
> regulatory organizations, and if necessary reuse existing liaison=
> relationships or request the establishment of new liaison relatio= nships.
> >
> > SACM-related efforts are largely aligned, and may overlap, w= ith
> > other IETF
> (and non-IETF) standardization efforts.  There are comm= on "problems"
> found in SACM, that may be addressed by the work done in SNMP, IP= FIX,
> NETCONF, SYSLOG, NEA, MILE, and potentially others.  Of= particular
> interest to SACM is understanding and respecting the distinctions=
> between itself and NEA and MILE.
> >
> > One way the NEA protocols can be used is as the transport fo= r data
> collected on the endpoint to an external service or data reposito= ry
> for further analysis and action.  NEA may also serve th= e purpose of
> carrying data- collection instructions.
> >
> > The MILE data formats provide a format to describe incident,=
> > threat-related
> incident, and indicator information.  SACM data formats= provide ways
> to understand what endpoints are in your environment, whether the= y
> meet policy requirements, and their current configuration state.&= nbsp; The
> data exchanged in MILE, supplementing the SACM data, creates enha= nced
> situational awareness, thus enabling increased understanding of
> current threats and mitigations.  The combined SACM and= MILE data sets
> become a powerful tool to automate security with descriptions of<= /div>
> endpoints, known vulnerabilities to those endpoints, and thier
> configurations along with an understanding of layered defenses.&n= bsp; Then,
> injecting known threat information with mitigation options assist= s the
> organization in turning detailed security decisions into
> business-relevant decisions.  The MILE protocols, RID a= nd ROLIE,
> enable the exchange of structured data and are designed to carry = any
> structured format.  While RID may be use  d
> >   in multiple sharing models and provides multiple= communication
> > flows
> (report, query, etc.) with the ability to enable peer-to-peer obj= ect
> level security, ROLIE provides a RESTful repository transport opt= ion
> with only the need for a browser on the client end, removing depl= oyment
barriers.
> >
> > After the work items in the current charter have been submit= ted to
> > and
> approved by the IESG, the WG will recharter or close.
> >
> > Goals and Milestones
> >
> > Sep. 2013 - Initial submission of an Internet-Draft on Use C= ases
> >
> > Oct. 2013 - Initial submission of an Internet-Draft on Requi= rements
> > taking
> into consideration RFC5706 and RFC3535
> >
> > Oct. 2013 - Initial submission of an Internet-Draft on SACM<= /div>
> > Architecture
> >
> > Nov. 2013 - Initial submission of an Internet-Draft on overv= iew of
> > related
> standards work
> >
> > Jan. 2014 - Initial submission of an Internet-Draft for a pr= otocol
> > and data
> format for retrieving configuration and policy information for dr= iving
> data collection and analysis
> >
> > Jan. 2014 - Initial submission of an Internet-Draft for a pr= otocol
> > and data
> format for collecting actual endpoint posture
> >
> > Apr. 2014 - Submission to the IESG of the Internet-Draft on = Use
> > Cases for
> consideration as Informational RFC
> >
> > Apr. 2014 - Submission to the IESG of the Internet-Draft on<= /div>
> > Requirements
> for consideration as Informational RFC
> >
> > Apr. 2014 - Submission to the IESG of the Internet-Draft on = SACM
> Architecture for consideration as Informational RFC
> >
> > Oct. 2014 - Submission to the IESG of the Internet-Draft for= a
> > protocol and
> data format for retrieving configuration and policy information f= or
> driving data collection and analysis for consideration as
> standards-track RFC
> >
> > Oct. 2014 - Submission to the IESG of the Internet-Draft a p= rotocol
> > and data
> format for collecting actual endpoint posture for consideration a= s
> standards- track RFC
> >
> > _______________________________________________
> > sacm mailing list
> >
> _______________________________________________
> sacm mailing list
_______________________________________________
sacm mailing list
...

This message and attachments may contain confidential information.&nbs= p; If it appears that this message was sent to you by mistake, any ret= ention, dissemination, distribution or copying of this message and attachme= nts is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachme= nts.
_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF288E70MIVEXAMER1N1corpn_-- From Adam.Montville@cisecurity.org Fri Jun 7 09:01:27 2013 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 0E17D21F9925 for ; Fri, 7 Jun 2013 09:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P-Jx6hTGSNr for ; Fri, 7 Jun 2013 09:01:05 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 499CE21F990D for ; Fri, 7 Jun 2013 09:00:53 -0700 (PDT) Received: from [216.82.253.227:50825] by server-2.bemta-7.messagelabs.com id 8D/6F-32713-4B302B15; Fri, 07 Jun 2013 16:00:52 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-170.messagelabs.com!1370620851!5983286!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 10210 invoked from network); 7 Jun 2013 16:00:52 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 16:00:52 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 12:00:45 -0400 From: Adam Montville To: Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUIA= Date: Fri, 7 Jun 2013 16:00:45 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> In-Reply-To: <51B1FE8E.3050405@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:01:28 -0000 [snip] > > To be more generic, we can take the list and turn it into something li= ke this > (I think Sean had not wanted this list to be modified, but...): > > > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess 3. Collect actual > > value of elements 4. Compare actual element values to expected element= > > values 5. Report results [snip]=20 > The charter need not to go in to gory detail and we can only guess what = other > people who haven't been involved will say when the charter goes out for > external review. I'm good with the existing bullet list or this shorten= ed one > as long as you can capture that this can supports policy-driven and/or a= sset- > driven models. >=20 > spt If we're going to "capture" that this supports policy-/asset-driven models= , then the abbreviated list is better with some explanatory text that simp= ly makes that claim. What if we simply preface the list with something li= ke this: "The following general steps accommodate both policy-driven and asset-driv= en assessment." Adam 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 turners@ieca.com Fri Jun 7 09:09:31 2013 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 823E121F960D for ; Fri, 7 Jun 2013 09:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Y6XvFZYP3Q2F for ; Fri, 7 Jun 2013 09:09:26 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.41.245.8]) by ietfa.amsl.com (Postfix) with ESMTP id E75A721F89A6 for ; Fri, 7 Jun 2013 09:09:25 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 3D78647454DC1; Fri, 7 Jun 2013 10:38:51 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 29D4847454D6C for ; Fri, 7 Jun 2013 10:38:51 -0500 (CDT) Received: from [173.73.135.101] (port=61259 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ukykh-00077c-MQ; Fri, 07 Jun 2013 10:38:55 -0500 Message-ID: <51B1FE8E.3050405@ieca.com> Date: Fri, 07 Jun 2013 11:38:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Montville References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:61259 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Gunnar Engelbach , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:09:31 -0000 On 6/7/13 11:07 AM, Adam Montville wrote: > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Waltermire, David A. >> Sent: Wednesday, June 05, 2013 7:06 AM >> To: Gunnar Engelbach; Adam W. Montville >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Updated Candidate Charter Text >> >> Great catch on change notification! The challenge with polling on a periodic >> basis is that the sample rate needs to be twice the rate of change. Using >> periodic data collection, there is a potential risk of missing a critical security- >> related change event that might indicate an attack is underway. If polling is >> performed outside the attack window, it is possible that the attack won't be >> noticed. > > Is this becoming too prescriptive in a way? You rightly point out that attacks could be missed with a polling mechanism, but how are agent-less solutions going to implement anything else? > > Also, is this the type of information we need to have in a charter or is this better applied in the work products of the WG? I think the latter. > > >> >> Policy driven assessment, as you have written below, can be used to address >> this type of detection using most of the same bits and bytes. To support >> event-driven notification, the endpoint assessment software will need to be >> told what events to collect and pass on. Most of what is described in steps 1- >> 4 of the draft charter still apply in setting up the event-driven collection >> environment. What is different is how steps 5 and 6 work. For step 5, the >> values are not harvested per se; they are generated based on change >> notifications. For step 6, incremental changes are reported on a continuous >> basis, until the endpoint is instructed not to collect those events anymore. > > Step 5 would need to be updated to accommodate change notification, such that results are either harvested or reported. But, again, I think this belongs in our work products and not the charter. > >> >> This is a desirable capability for end-user organizations and I believe it should >> be reflected in the charter. > > The more we carry on this discussion the more I question having anything other than an exemplary list of steps to help describe the concept of "configuration assessment." We can add language to the charter without needing to enumerate all the possible use cases (we have a document for that already) and then ensure the assessment steps we provide are generic - remember the only reason they were included were to provide additional context for an uninitiated reader to better understand what this WG is about. > > To be more generic, we can take the list and turn it into something like this (I think Sean had not wanted this list to be modified, but...): > > 1. Identify endpoints > 2. Determine specific endpoint elements to assess > 3. Collect actual value of elements > 4. Compare actual element values to expected element values > 5. Report results > > This should be enough to provide context to an external reader to *generally* understand the problem space this WG addresses (would be interesting to validate by getting someone wholly unfamiliar with this problem domain to review). > > To me, this is perfectly acceptable - it's possible for the WG to leave the details (i.e. policy-driven vs. asset-driven, assessment polling vs. near real-time assessment, and so on) to the Use Case and Architecture documents. The charter need not to go in to gory detail and we can only guess what other people who haven't been involved will say when the charter goes out for external review. I'm good with the existing bullet list or this shortened one as long as you can capture that this can supports policy-driven and/or asset-driven models. spt > Finally, I'd like to point out that the milestones and deliverables for this WG, as expressed in the present draft charter, are fairly encompassing as well. They do not get into the details - especially in light of the lengthy list Gunnar shared. > >> >> Sincerely, >> Dave >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>> Of Gunnar Engelbach >>> Sent: Tuesday, June 04, 2013 1:20 PM >>> To: Adam W. Montville >>> Cc: sacm@ietf.org >>> Subject: Re: [sacm] Updated Candidate Charter Text >>> >>> >>> My primary quibbles are below, but I'd like to start by highlighting >>> something Stephen Whitlock said: "...deviations from standard >>> configurations (whether by accident or intent) would result in a >> notification..." >>> >>> Going back to Dave Waltermire's proposed architecture, it included >>> change notification originating from endpoints which helps feed >>> Stephen's ideal, and I don't see an allowance for that in this revision. >>> >>> Real time compliance/vulnerability notification originating from >>> endpoint events is a desirable security goal that I think falls within >>> the scope of this WG. >>> >>> There is also a significant lag between the formation of a new WG and >>> the delivery of usable products. >>> >>> So, while top-down assessments, seems to be plenty for this WG to gnaw >>> on at the moment, I'd like to also keep bottom-up in mind so that any >>> work done now doesn't preclude that as a follow-on. And, preferably, >>> makes it possible to quickly add that next. >>> >>> >>> There also seems to be a chicken-and-egg type of thing of selection of >>> policy versus selection of assets as the starting point. I think both >>> are valid so I tried, clumsily, to address that in my revision of the >>> assessment steps, to follow. >>> >>> ---------------------------+++++++++++++--------------------------- >>> >>> >>> >>> The components, protocols, and content documents defined by this >>> working group can be used in multiple ways such as top-down assessment >>> of policy compliance, notification of compliance posture change >>> initiated by a change made on an endpoint, determination of affected >>> assets based on reportage of a new vulnerability, ad-hoc queries of specific >> asset settings, etc. >>> >>> The initial focus of this working group is the performance of top-down >>> policy assessments using the following steps: >>> >>> >>> A policy-driven assessment: >>> >>> A) The content repository is queried for the content documents that >>> codify the policy/policies of interest. >>> >>> B) Assets are selected that match the criteria of the selected >>> policy/policies. The method of selection can include enumeration from >>> known asset inventories, direct query of known assets, network >>> discovery, etc. Selection of assets may be further refined by other >>> criteria such as ownership, location, role, time of day, etc. >>> >>> (Note: I used the term "asset" instead of "endpoint" because it >>> includes software assets, allowing for assessments of, for example, >>> web servers, virtual machine instance settings, a virtualized database >>> instance running on a cluster, etc) >>> >>> >>> Alternatively, and asset-driven assessment: >>> >>> A) Assets are selected based on a set of criteria (ownership, >>> location, role, time of day, etc.). >>> >>> B) For each asset, determine and retrieve the applicable >>> policy/policies from the content repository. >>> >>> >>> For each asset: >>> >>> 1) Determine what elements of posture information to collect based on >>> the policy/policies to be evaluated. >>> >>> >>> 2) For each element of the asset posture data, identify the mechanism >>> for data collection and what content is needed, if any, to support >>> data collection. >>> >>> (Note: I assume this means if the collection is via direct endpoint >>> query, CMDB retrieval, etc. That means a layer of meta data is needed >>> that we haven't really talked about: authentication information, DB >>> host/port, connection type, etc. Since this is an explicit step in >>> the process, should that data also be part of the standard?) >>> >>> >>> 3) Harvest the actual values pertaining to posture elements identified >>> in step 3 from the targeted asset(s). >>> >>> 4) Report collected asset posture. This will likely be done on an >>> individual basis for each identified asset , requiring aggregation of >>> data collected from multiple asset as needed based on the identified >> policy. >>> >>> >>> >>> >>> >>> >>> On 6/2/2013 11:57 AM, Adam W. Montville wrote: >>>> All: >>>> >>>> I've taken the charter >>>> (http://datatracker.ietf.org/doc/charter-ietf-sacm/) >>> and comments submitted in a variety of threads >>> (http://www.ietf.org/mail- >>> archive/web/sacm/current/threads.html) and put the following together. >>>> >>>> I would love to see a dramatic increase in SACM participation >>>> throughout >>> this month - especially relating to the charter, which should be our >>> primary focus at this point, and then limited to the first several milestones. >>>> >>>> My concern is that SACM momentum is trailing off at a point when it >>>> needs >>> to be maintaining, if not increasing, from that level we saw at IETF 86. >>>> >>>> The following is the modified charter text: >>>> >>>> Securing information and the systems that store, process, and >>>> transmit that >>> information is a challenging task for organizations of all sizes, and >>> many security practitioners spend much of their time on manual processes. >>> Standardized processes to collect, verify, and update security system >>> configurations would allow easier automation of the processes. >>> Automating these routine tasks would free security practitioners to >>> focus on high priority tasks, and should improve operators' ability to >>> prioritize risk based on timely information about threats and >>> vulnerabilities. This working group will define security automation >>> protocols and data format standards in support of information security >>> processes and practices. These standards will help security >>> practitioners to be more effective by automating routine tasks related >>> to client and server security, freeing them to focus on more advanced >>> tasks. The initial focus of this work is to address enterprise use >>> cases pertaining to the ass es >>>> sment of endpoint posture (using the definitions of Endpoint and >>>> Posture >>> from RFC 5209). >>>> >>>> The working group will, whenever reasonable and possible, reuse >>>> existing >>> protocols, mechanisms, information and data models. Of particular >>> interest to this working group are existing industry standards, >>> preferably IETF standards, that could support automation of asset, >>> change, configuration, and vulnerability management. >>>> >>>> The working group will define: >>>> >>>> 1. A set of standards to enable assessment of endpoint posture. This >>>> area >>> of focus provides for necessary language and data format specifications. >>>> >>>> 2. A set of standards for interacting with repositories of content >>>> related to >>> assessment of endpoint posture. >>>> >>>> Assessment of endpoint posture assessment entails the following >>>> general >>> steps: >>>> >>>> 1. Relevant endpoints are identified and classified based on the >>>> targets of >>> the policy/policies to be evaluated >>>> >>>> 2. For each endpoint, determine what elements of posture information >>>> to >>> collect based on the policy/policies to be evaluated >>>> >>>> 3. For each element of the endpoint posture data, identify the >>>> mechanism >>> for data collection and what content is needed, if any, to support >>> data collection >>>> >>>> 4. Retrieve any content needed for data collection. Configuration >>>> checks >>> pertaining to a particular posture element may be used to support data >>> collection. >>>> >>>> 5. Harvest the actual values pertaining to posture elements >>>> identified in >>> step 3 from the endpoint. >>>> >>>> 6. Report collected endpoint posture as identified in step 2. This >>>> will likely >>> be done on an individual basis for each identified endpoint, requiring >>> aggregation of data collected from multiple endpoints as needed based >>> on the identified policy. >>>> >>>> This approach to endpoint posture collection enables multiple >>>> policies to be >>> evaluated based on a single data collection activity. Policies will be >>> evaluated by comparing available endpoint posture data according to >>> rules expressed in the policy. Typically, these rules will compare the >>> actual value against an expected value or range for specific posture >>> elements. In some cases, the posture element may pertain to software >>> installation state, in which case the actual and expected values may >>> be "installed" or "not installed." Evaluation of multiple posture elements >> may be combined using Boolean logic. >>>> >>>> Repository protocols are needed to store, update, and retrieve >>> configuration checks and other types of content required for posture >>> assessment (see step 2 above). A content repository is expected to >>> house specific versions of checklists (i.e. benchmarks), may be >>> required to satisfy different use cases (i.e. a NEA-specific use vs. a >>> generally applicable assessment used during continuous monitoring). >>> In addition, content repositories are expected to store up-to-date >>> dictionary of specific enumerations, such as those used for >>> configuration element identifiers, asset classifications, vulnerability >> identifiers, and so on. >>>> >>>> This working group will achieve the following deliverables: >>>> >>>> - An Informational document on Use Cases >>>> - An Informational document on Requirements >>>> - An Informational document on SACM Architecture >>>> - A standards-track document specifying a protocol and data format >>>> for >>> retrieving configuration and policy information for driving data >>> collection and analysis >>>> - A standards-track document specifying a protocol and data format >>>> for >>> collecting actual endpoint posture >>>> >>>> The working group will create an overview of related standards work >>> Internet-Draft which will document existing work in the IETF or in >>> other SDOs which can be used as-is or as a starting point for >>> developing solutions to the SACM requirements. The working group may >>> decide to make of this document an Informational RFC, but this is not a >> mandatory deliverable. >>>> >>>> The working group will work in close coordination with other WGs in >>>> the >>> IETF (including, but not limited to MILE and NEA) in order to create >>> solutions that do not overlap (for example for the repository access >>> protocol) and can be used or re-used to meet the goals of more than one >> working group. >>>> >>>> In accordance with existing IETF processes, the group will >>>> communicate >>> with and invite participation from other relevant standards bodies and >>> regulatory organizations, and if necessary reuse existing liaison >>> relationships or request the establishment of new liaison relationships. >>>> >>>> SACM-related efforts are largely aligned, and may overlap, with >>>> other IETF >>> (and non-IETF) standardization efforts. There are common "problems" >>> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular >>> interest to SACM is understanding and respecting the distinctions >>> between itself and NEA and MILE. >>>> >>>> One way the NEA protocols can be used is as the transport for data >>> collected on the endpoint to an external service or data repository >>> for further analysis and action. NEA may also serve the purpose of >>> carrying data- collection instructions. >>>> >>>> The MILE data formats provide a format to describe incident, >>>> threat-related >>> incident, and indicator information. SACM data formats provide ways >>> to understand what endpoints are in your environment, whether they >>> meet policy requirements, and their current configuration state. The >>> data exchanged in MILE, supplementing the SACM data, creates enhanced >>> situational awareness, thus enabling increased understanding of >>> current threats and mitigations. The combined SACM and MILE data sets >>> become a powerful tool to automate security with descriptions of >>> endpoints, known vulnerabilities to those endpoints, and thier >>> configurations along with an understanding of layered defenses. Then, >>> injecting known threat information with mitigation options assists the >>> organization in turning detailed security decisions into >>> business-relevant decisions. The MILE protocols, RID and ROLIE, >>> enable the exchange of structured data and are designed to carry any >>> structured format. While RID may be use d >>>> in multiple sharing models and provides multiple communication >>>> flows >>> (report, query, etc.) with the ability to enable peer-to-peer object >>> level security, ROLIE provides a RESTful repository transport option >>> with only the need for a browser on the client end, removing deployment >> barriers. >>>> >>>> After the work items in the current charter have been submitted to >>>> and >>> approved by the IESG, the WG will recharter or close. >>>> >>>> Goals and Milestones >>>> >>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>> >>>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>>> taking >>> into consideration RFC5706 and RFC3535 >>>> >>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>> Architecture >>>> >>>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>>> related >>> standards work >>>> >>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>> and data >>> format for retrieving configuration and policy information for driving >>> data collection and analysis >>>> >>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>> and data >>> format for collecting actual endpoint posture >>>> >>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use >>>> Cases for >>> consideration as Informational RFC >>>> >>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>> Requirements >>> for consideration as Informational RFC >>>> >>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>> Architecture for consideration as Informational RFC >>>> >>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>> protocol and >>> data format for retrieving configuration and policy information for >>> driving data collection and analysis for consideration as >>> standards-track RFC >>>> >>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol >>>> and data >>> format for collecting actual endpoint posture for consideration as >>> standards- track RFC >>>> >>>> _______________________________________________ >>>> 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 >> >> ... > > 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. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From gunnar.engelbach@threatguard.com Fri Jun 7 09:17:17 2013 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 43B9521F86D5 for ; Fri, 7 Jun 2013 09:17:17 -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 JCjgCM6YhvuH for ; Fri, 7 Jun 2013 09:17:12 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 913D921F8667 for ; Fri, 7 Jun 2013 09:17:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=a9L8qeEC5WHCXRH0+k0eYEKGtkvY9map0zcoED8xW+5+wUXgshtKGZoibAJdneQcV62nDYK5kCNFhLD2EBjj5ClA7z0KeJOEOY+BCwQeJOJX3N25/jKKP2VR4T7W0UGA; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 25125 invoked from network); 7 Jun 2013 09:28:45 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 7 Jun 2013 09:28:44 -0700 Message-ID: <51B20789.5060409@ThreatGuard.com> Date: Fri, 07 Jun 2013 12:17:13 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sean Turner References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> In-Reply-To: <51B1FE8E.3050405@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Adam W. Montville" , Adam Montville , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:17:17 -0000 I'm fine with the simplified bullet points as long as it is clear that they are an example to help clarify the purpose of the charter and don't represent the exact goal of the working group. On 6/7/2013 11:38 AM, Sean Turner wrote: > On 6/7/13 11:07 AM, Adam Montville wrote: >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Waltermire, David A. >>> Sent: Wednesday, June 05, 2013 7:06 AM >>> To: Gunnar Engelbach; Adam W. Montville >>> Cc: sacm@ietf.org >>> Subject: Re: [sacm] Updated Candidate Charter Text >>> >>> Great catch on change notification! The challenge with polling on a >>> periodic >>> basis is that the sample rate needs to be twice the rate of change. >>> Using >>> periodic data collection, there is a potential risk of missing a >>> critical security- >>> related change event that might indicate an attack is underway. If >>> polling is >>> performed outside the attack window, it is possible that the attack >>> won't be >>> noticed. >> >> Is this becoming too prescriptive in a way? You rightly point out >> that attacks could be missed with a polling mechanism, but how are >> agent-less solutions going to implement anything else? >> >> Also, is this the type of information we need to have in a charter or >> is this better applied in the work products of the WG? I think the >> latter. >> >> >>> >>> Policy driven assessment, as you have written below, can be used to >>> address >>> this type of detection using most of the same bits and bytes. To >>> support >>> event-driven notification, the endpoint assessment software will need >>> to be >>> told what events to collect and pass on. Most of what is described in >>> steps 1- >>> 4 of the draft charter still apply in setting up the event-driven >>> collection >>> environment. What is different is how steps 5 and 6 work. For step 5, >>> the >>> values are not harvested per se; they are generated based on change >>> notifications. For step 6, incremental changes are reported on a >>> continuous >>> basis, until the endpoint is instructed not to collect those events >>> anymore. >> >> Step 5 would need to be updated to accommodate change notification, >> such that results are either harvested or reported. But, again, I >> think this belongs in our work products and not the charter. >> >>> >>> This is a desirable capability for end-user organizations and I >>> believe it should >>> be reflected in the charter. >> >> The more we carry on this discussion the more I question having >> anything other than an exemplary list of steps to help describe the >> concept of "configuration assessment." We can add language to the >> charter without needing to enumerate all the possible use cases (we >> have a document for that already) and then ensure the assessment steps >> we provide are generic - remember the only reason they were included >> were to provide additional context for an uninitiated reader to better >> understand what this WG is about. >> >> To be more generic, we can take the list and turn it into something >> like this (I think Sean had not wanted this list to be modified, but...): >> >> 1. Identify endpoints >> 2. Determine specific endpoint elements to assess >> 3. Collect actual value of elements >> 4. Compare actual element values to expected element values >> 5. Report results >> >> This should be enough to provide context to an external reader to >> *generally* understand the problem space this WG addresses (would be >> interesting to validate by getting someone wholly unfamiliar with this >> problem domain to review). >> >> To me, this is perfectly acceptable - it's possible for the WG to >> leave the details (i.e. policy-driven vs. asset-driven, assessment >> polling vs. near real-time assessment, and so on) to the Use Case and >> Architecture documents. > > The charter need not to go in to gory detail and we can only guess what > other people who haven't been involved will say when the charter goes > out for external review. I'm good with the existing bullet list or this > shortened one as long as you can capture that this can supports > policy-driven and/or asset-driven models. > > spt > >> Finally, I'd like to point out that the milestones and deliverables >> for this WG, as expressed in the present draft charter, are fairly >> encompassing as well. They do not get into the details - especially >> in light of the lengthy list Gunnar shared. >> >>> >>> Sincerely, >>> Dave >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>> Of Gunnar Engelbach >>>> Sent: Tuesday, June 04, 2013 1:20 PM >>>> To: Adam W. Montville >>>> Cc: sacm@ietf.org >>>> Subject: Re: [sacm] Updated Candidate Charter Text >>>> >>>> >>>> My primary quibbles are below, but I'd like to start by highlighting >>>> something Stephen Whitlock said: "...deviations from standard >>>> configurations (whether by accident or intent) would result in a >>> notification..." >>>> >>>> Going back to Dave Waltermire's proposed architecture, it included >>>> change notification originating from endpoints which helps feed >>>> Stephen's ideal, and I don't see an allowance for that in this >>>> revision. >>>> >>>> Real time compliance/vulnerability notification originating from >>>> endpoint events is a desirable security goal that I think falls within >>>> the scope of this WG. >>>> >>>> There is also a significant lag between the formation of a new WG and >>>> the delivery of usable products. >>>> >>>> So, while top-down assessments, seems to be plenty for this WG to gnaw >>>> on at the moment, I'd like to also keep bottom-up in mind so that any >>>> work done now doesn't preclude that as a follow-on. And, preferably, >>>> makes it possible to quickly add that next. >>>> >>>> >>>> There also seems to be a chicken-and-egg type of thing of selection of >>>> policy versus selection of assets as the starting point. I think both >>>> are valid so I tried, clumsily, to address that in my revision of the >>>> assessment steps, to follow. >>>> >>>> ---------------------------+++++++++++++--------------------------- >>>> >>>> >>>> >>>> The components, protocols, and content documents defined by this >>>> working group can be used in multiple ways such as top-down assessment >>>> of policy compliance, notification of compliance posture change >>>> initiated by a change made on an endpoint, determination of affected >>>> assets based on reportage of a new vulnerability, ad-hoc queries of >>>> specific >>> asset settings, etc. >>>> >>>> The initial focus of this working group is the performance of top-down >>>> policy assessments using the following steps: >>>> >>>> >>>> A policy-driven assessment: >>>> >>>> A) The content repository is queried for the content documents that >>>> codify the policy/policies of interest. >>>> >>>> B) Assets are selected that match the criteria of the selected >>>> policy/policies. The method of selection can include enumeration from >>>> known asset inventories, direct query of known assets, network >>>> discovery, etc. Selection of assets may be further refined by other >>>> criteria such as ownership, location, role, time of day, etc. >>>> >>>> (Note: I used the term "asset" instead of "endpoint" because it >>>> includes software assets, allowing for assessments of, for example, >>>> web servers, virtual machine instance settings, a virtualized database >>>> instance running on a cluster, etc) >>>> >>>> >>>> Alternatively, and asset-driven assessment: >>>> >>>> A) Assets are selected based on a set of criteria (ownership, >>>> location, role, time of day, etc.). >>>> >>>> B) For each asset, determine and retrieve the applicable >>>> policy/policies from the content repository. >>>> >>>> >>>> For each asset: >>>> >>>> 1) Determine what elements of posture information to collect based on >>>> the policy/policies to be evaluated. >>>> >>>> >>>> 2) For each element of the asset posture data, identify the mechanism >>>> for data collection and what content is needed, if any, to support >>>> data collection. >>>> >>>> (Note: I assume this means if the collection is via direct endpoint >>>> query, CMDB retrieval, etc. That means a layer of meta data is needed >>>> that we haven't really talked about: authentication information, DB >>>> host/port, connection type, etc. Since this is an explicit step in >>>> the process, should that data also be part of the standard?) >>>> >>>> >>>> 3) Harvest the actual values pertaining to posture elements identified >>>> in step 3 from the targeted asset(s). >>>> >>>> 4) Report collected asset posture. This will likely be done on an >>>> individual basis for each identified asset , requiring aggregation of >>>> data collected from multiple asset as needed based on the identified >>> policy. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 6/2/2013 11:57 AM, Adam W. Montville wrote: >>>>> All: >>>>> >>>>> I've taken the charter >>>>> (http://datatracker.ietf.org/doc/charter-ietf-sacm/) >>>> and comments submitted in a variety of threads >>>> (http://www.ietf.org/mail- >>>> archive/web/sacm/current/threads.html) and put the following together. >>>>> >>>>> I would love to see a dramatic increase in SACM participation >>>>> throughout >>>> this month - especially relating to the charter, which should be our >>>> primary focus at this point, and then limited to the first several >>>> milestones. >>>>> >>>>> My concern is that SACM momentum is trailing off at a point when it >>>>> needs >>>> to be maintaining, if not increasing, from that level we saw at IETF >>>> 86. >>>>> >>>>> The following is the modified charter text: >>>>> >>>>> Securing information and the systems that store, process, and >>>>> transmit that >>>> information is a challenging task for organizations of all sizes, and >>>> many security practitioners spend much of their time on manual >>>> processes. >>>> Standardized processes to collect, verify, and update security system >>>> configurations would allow easier automation of the processes. >>>> Automating these routine tasks would free security practitioners to >>>> focus on high priority tasks, and should improve operators' ability to >>>> prioritize risk based on timely information about threats and >>>> vulnerabilities. This working group will define security automation >>>> protocols and data format standards in support of information security >>>> processes and practices. These standards will help security >>>> practitioners to be more effective by automating routine tasks related >>>> to client and server security, freeing them to focus on more advanced >>>> tasks. The initial focus of this work is to address enterprise use >>>> cases pertaining to the ass es >>>>> sment of endpoint posture (using the definitions of Endpoint and >>>>> Posture >>>> from RFC 5209). >>>>> >>>>> The working group will, whenever reasonable and possible, reuse >>>>> existing >>>> protocols, mechanisms, information and data models. Of particular >>>> interest to this working group are existing industry standards, >>>> preferably IETF standards, that could support automation of asset, >>>> change, configuration, and vulnerability management. >>>>> >>>>> The working group will define: >>>>> >>>>> 1. A set of standards to enable assessment of endpoint posture. This >>>>> area >>>> of focus provides for necessary language and data format >>>> specifications. >>>>> >>>>> 2. A set of standards for interacting with repositories of content >>>>> related to >>>> assessment of endpoint posture. >>>>> >>>>> Assessment of endpoint posture assessment entails the following >>>>> general >>>> steps: >>>>> >>>>> 1. Relevant endpoints are identified and classified based on the >>>>> targets of >>>> the policy/policies to be evaluated >>>>> >>>>> 2. For each endpoint, determine what elements of posture information >>>>> to >>>> collect based on the policy/policies to be evaluated >>>>> >>>>> 3. For each element of the endpoint posture data, identify the >>>>> mechanism >>>> for data collection and what content is needed, if any, to support >>>> data collection >>>>> >>>>> 4. Retrieve any content needed for data collection. Configuration >>>>> checks >>>> pertaining to a particular posture element may be used to support data >>>> collection. >>>>> >>>>> 5. Harvest the actual values pertaining to posture elements >>>>> identified in >>>> step 3 from the endpoint. >>>>> >>>>> 6. Report collected endpoint posture as identified in step 2. This >>>>> will likely >>>> be done on an individual basis for each identified endpoint, requiring >>>> aggregation of data collected from multiple endpoints as needed based >>>> on the identified policy. >>>>> >>>>> This approach to endpoint posture collection enables multiple >>>>> policies to be >>>> evaluated based on a single data collection activity. Policies will be >>>> evaluated by comparing available endpoint posture data according to >>>> rules expressed in the policy. Typically, these rules will compare the >>>> actual value against an expected value or range for specific posture >>>> elements. In some cases, the posture element may pertain to software >>>> installation state, in which case the actual and expected values may >>>> be "installed" or "not installed." Evaluation of multiple posture >>>> elements >>> may be combined using Boolean logic. >>>>> >>>>> Repository protocols are needed to store, update, and retrieve >>>> configuration checks and other types of content required for posture >>>> assessment (see step 2 above). A content repository is expected to >>>> house specific versions of checklists (i.e. benchmarks), may be >>>> required to satisfy different use cases (i.e. a NEA-specific use vs. a >>>> generally applicable assessment used during continuous monitoring). >>>> In addition, content repositories are expected to store up-to-date >>>> dictionary of specific enumerations, such as those used for >>>> configuration element identifiers, asset classifications, vulnerability >>> identifiers, and so on. >>>>> >>>>> This working group will achieve the following deliverables: >>>>> >>>>> - An Informational document on Use Cases >>>>> - An Informational document on Requirements >>>>> - An Informational document on SACM Architecture >>>>> - A standards-track document specifying a protocol and data format >>>>> for >>>> retrieving configuration and policy information for driving data >>>> collection and analysis >>>>> - A standards-track document specifying a protocol and data format >>>>> for >>>> collecting actual endpoint posture >>>>> >>>>> The working group will create an overview of related standards work >>>> Internet-Draft which will document existing work in the IETF or in >>>> other SDOs which can be used as-is or as a starting point for >>>> developing solutions to the SACM requirements. The working group may >>>> decide to make of this document an Informational RFC, but this is not a >>> mandatory deliverable. >>>>> >>>>> The working group will work in close coordination with other WGs in >>>>> the >>>> IETF (including, but not limited to MILE and NEA) in order to create >>>> solutions that do not overlap (for example for the repository access >>>> protocol) and can be used or re-used to meet the goals of more than one >>> working group. >>>>> >>>>> In accordance with existing IETF processes, the group will >>>>> communicate >>>> with and invite participation from other relevant standards bodies and >>>> regulatory organizations, and if necessary reuse existing liaison >>>> relationships or request the establishment of new liaison >>>> relationships. >>>>> >>>>> SACM-related efforts are largely aligned, and may overlap, with >>>>> other IETF >>>> (and non-IETF) standardization efforts. There are common "problems" >>>> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular >>>> interest to SACM is understanding and respecting the distinctions >>>> between itself and NEA and MILE. >>>>> >>>>> One way the NEA protocols can be used is as the transport for data >>>> collected on the endpoint to an external service or data repository >>>> for further analysis and action. NEA may also serve the purpose of >>>> carrying data- collection instructions. >>>>> >>>>> The MILE data formats provide a format to describe incident, >>>>> threat-related >>>> incident, and indicator information. SACM data formats provide ways >>>> to understand what endpoints are in your environment, whether they >>>> meet policy requirements, and their current configuration state. The >>>> data exchanged in MILE, supplementing the SACM data, creates enhanced >>>> situational awareness, thus enabling increased understanding of >>>> current threats and mitigations. The combined SACM and MILE data sets >>>> become a powerful tool to automate security with descriptions of >>>> endpoints, known vulnerabilities to those endpoints, and thier >>>> configurations along with an understanding of layered defenses. Then, >>>> injecting known threat information with mitigation options assists the >>>> organization in turning detailed security decisions into >>>> business-relevant decisions. The MILE protocols, RID and ROLIE, >>>> enable the exchange of structured data and are designed to carry any >>>> structured format. While RID may be use d >>>>> in multiple sharing models and provides multiple communication >>>>> flows >>>> (report, query, etc.) with the ability to enable peer-to-peer object >>>> level security, ROLIE provides a RESTful repository transport option >>>> with only the need for a browser on the client end, removing deployment >>> barriers. >>>>> >>>>> After the work items in the current charter have been submitted to >>>>> and >>>> approved by the IESG, the WG will recharter or close. >>>>> >>>>> Goals and Milestones >>>>> >>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>>> >>>>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>>>> taking >>>> into consideration RFC5706 and RFC3535 >>>>> >>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>>> Architecture >>>>> >>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>>>> related >>>> standards work >>>>> >>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>> and data >>>> format for retrieving configuration and policy information for driving >>>> data collection and analysis >>>>> >>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>> and data >>>> format for collecting actual endpoint posture >>>>> >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use >>>>> Cases for >>>> consideration as Informational RFC >>>>> >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>>> Requirements >>>> for consideration as Informational RFC >>>>> >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>>> Architecture for consideration as Informational RFC >>>>> >>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>>> protocol and >>>> data format for retrieving configuration and policy information for >>>> driving data collection and analysis for consideration as >>>> standards-track RFC >>>>> >>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol >>>>> and data >>>> format for collecting actual endpoint posture for consideration as >>>> standards- track RFC >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> ... >> >> 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. >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> From turners@ieca.com Fri Jun 7 09:20:53 2013 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 6538E21F9923 for ; Fri, 7 Jun 2013 09:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 i5ICAbVZAjJ9 for ; Fri, 7 Jun 2013 09:20:47 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.44.28]) by ietfa.amsl.com (Postfix) with ESMTP id 066BD21F92B7 for ; Fri, 7 Jun 2013 09:20:47 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 4D42848BECAB2; Fri, 7 Jun 2013 11:20:23 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 3C41648BECA7D for ; Fri, 7 Jun 2013 11:20:23 -0500 (CDT) Received: from [173.73.135.101] (port=61388 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UkzPC-0002lr-6z; Fri, 07 Jun 2013 11:20:46 -0500 Message-ID: <51B2085D.2020400@ieca.com> Date: Fri, 07 Jun 2013 12:20:45 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Montville References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:61388 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Gunnar Engelbach , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:20:53 -0000 Okay so this looks like it's going to work. Let's make the changes in the draft charter. spt On 6/7/13 12:00 PM, Adam Montville wrote: > [snip] >>> To be more generic, we can take the list and turn it into something like this >> (I think Sean had not wanted this list to be modified, but...): >>> >>> 1. Identify endpoints >>> 2. Determine specific endpoint elements to assess 3. Collect actual >>> value of elements 4. Compare actual element values to expected element >>> values 5. Report results > [snip] >> The charter need not to go in to gory detail and we can only guess what other >> people who haven't been involved will say when the charter goes out for >> external review. I'm good with the existing bullet list or this shortened one >> as long as you can capture that this can supports policy-driven and/or asset- >> driven models. >> >> spt > > If we're going to "capture" that this supports policy-/asset-driven models, then the abbreviated list is better with some explanatory text that simply makes that claim. What if we simply preface the list with something like this: > > "The following general steps accommodate both policy-driven and asset-driven assessment." > > Adam > > 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 gunnar.engelbach@threatguard.com Fri Jun 7 09:48:08 2013 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 94A3521F9925 for ; Fri, 7 Jun 2013 09:48:08 -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 7zMcLBjmLDEC for ; Fri, 7 Jun 2013 09:47:59 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6F63621F96FB for ; Fri, 7 Jun 2013 09:47:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=ML/cv0MEE6WboDp9Rb9M1n7A7K2hIjNmJj7JnrtR182PirPgBECm2ZSLM2wOgavnTWdqwQZlCOE4dU19PMcJjwjBQBrKaBoG1Z6hup/aRRxEGdzeTRQj3v8d4Gu/UMD4; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 27003 invoked from network); 7 Jun 2013 09:59:31 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 7 Jun 2013 09:59:31 -0700 Message-ID: <51B20EC5.4060407@ThreatGuard.com> Date: Fri, 07 Jun 2013 12:48:05 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent_Landfield@McAfee.com References: <3CBA099FBA0AB843895D72474092B8CF288E70@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF288E70@MIVEXAMER1N1.corp.nai.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: adam@stoicsecurity.com, Adam.Montville@cisecurity.org, david.waltermire@nist.gov, sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:48:08 -0000 Policy, as a codification of best practices, regulatory requirements, or known vulnerabilities, is certainly the starting point. The current model of top-down whole-policy assessment makes the most sense as a starting point, but it's also inefficient and leaves a gap of exposure between the time of a system change and the next assessment. Closing that gap by increasing the periodicity of scans just increases the amount of resources dedicated to security assessments (and most of which will show no delta), and performing security assessments is not the reason why organizations put money into networks. Processing change notifications is the way out of that spiral. That's not to say that this WG will deal with that to start with, or ever, but it all goes back to the policies, which are the core of this WG. So my point is that while we are focusing on the more traditional approach, let's keep the event-oriented future in mind to the extent that we are able. Similarly, Rainer Enders had a very good point about endpoint trust. My feel for this WG is that it won't be addressed, but it's an important factor to keep in mind. That might just be as simple as including a field that indicates the trust level of the collected data items. --gun On 6/7/2013 11:36 AM, Kent_Landfield@McAfee.com wrote: > Are we straying from the intent here? Policy driven assessments are > normally evaluated against a known good. Is this system running the > approved software, approved services with the recommended configuration > and permissions, etc… If we are now talking about an event driven > notification architecture, are we looking as something like IF-MAP ? > This seems to be straying and expanding the focus of the charter. I > thought that was what we were trying to avoid. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: Adam Montville > > Date: Friday, June 7, 2013 10:07 AM > To: David Waltermire >, Gunnar Engelbach > >, "Adam W. Montville" > > > Cc: "sacm@ietf.org " > > Subject: Re: [sacm] Updated Candidate Charter Text > > > -----Original Message----- > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Wednesday, June 05, 2013 7:06 AM > To: Gunnar Engelbach; Adam W. Montville > Cc: sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text > Great catch on change notification! The challenge with polling > on a periodic > basis is that the sample rate needs to be twice the rate of > change. Using > periodic data collection, there is a potential risk of missing a > critical security- > related change event that might indicate an attack is underway. > If polling is > performed outside the attack window, it is possible that the > attack won't be > noticed. > > > Is this becoming too prescriptive in a way? You rightly point out > that attacks could be missed with a polling mechanism, but how are > agent-less solutions going to implement anything else? > > Also, is this the type of information we need to have in a charter > or is this better applied in the work products of the WG? I think > the latter. > > > Policy driven assessment, as you have written below, can be used > to address > this type of detection using most of the same bits and > bytes. To support > event-driven notification, the endpoint assessment software will > need to be > told what events to collect and pass on. Most of what is > described in steps 1- > 4 of the draft charter still apply in setting up the > event-driven collection > environment. What is different is how steps 5 and 6 work. For > step 5, the > values are not harvested per se; they are generated based on change > notifications. For step 6, incremental changes are reported on a > continuous > basis, until the endpoint is instructed not to collect those > events anymore. > > > Step 5 would need to be updated to accommodate change notification, > such that results are either harvested or reported. But, again, I > think this belongs in our work products and not the charter. > > This is a desirable capability for end-user organizations and I > believe it should > be reflected in the charter. > > > The more we carry on this discussion the more I question having > anything other than an exemplary list of steps to help describe the > concept of "configuration assessment." We can add language to the > charter without needing to enumerate all the possible use cases (we > have a document for that already) and then ensure the assessment > steps we provide are generic - remember the only reason they were > included were to provide additional context for an uninitiated > reader to better understand what this WG is about. > > To be more generic, we can take the list and turn it into something > like this (I think Sean had not wanted this list to be modified, > but...): > > 1. Identify endpoints > 2. Determine specific endpoint elements to assess > 3. Collect actual value of elements > 4. Compare actual element values to expected element values > 5. Report results > > This should be enough to provide context to an external reader to > *generally* understand the problem space this WG addresses (would > be interesting to validate by getting someone wholly unfamiliar with > this problem domain to review). > > To me, this is perfectly acceptable - it's possible for the WG to > leave the details (i.e. policy-driven vs. asset-driven, assessment > polling vs. near real-time assessment, and so on) to the Use Case > and Architecture documents. > > Finally, I'd like to point out that the milestones and deliverables > for this WG, as expressed in the present draft charter, are fairly > encompassing as well. They do not get into the details - especially > in light of the lengthy list Gunnar shared. > > Sincerely, > Dave > > -----Original Message----- > > From:sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf > > Of Gunnar Engelbach > > Sent: Tuesday, June 04, 2013 1:20 PM > > To: Adam W. Montville > > Cc:sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > My primary quibbles are below, but I'd like to start by highlighting > > something Stephen Whitlock said: "...deviations from standard > > configurations (whether by accident or intent) would result in a > notification..." > > > > Going back to Dave Waltermire's proposed architecture, it included > > change notification originating from endpoints which helps feed > > Stephen's ideal, and I don't see an allowance for that in this revision. > > > > Real time compliance/vulnerability notification originating from > > endpoint events is a desirable security goal that I think falls within > > the scope of this WG. > > > > There is also a significant lag between the formation of a new WG and > > the delivery of usable products. > > > > So, while top-down assessments, seems to be plenty for this WG to gnaw > > on at the moment, I'd like to also keep bottom-up in mind so that any > > work done now doesn't preclude that as a follow-on. And, preferably, > > makes it possible to quickly add that next. > > > > > > There also seems to be a chicken-and-egg type of thing of selection of > > policy versus selection of assets as the starting point. I think both > > are valid so I tried, clumsily, to address that in my revision of the > > assessment steps, to follow. > > > > ---------------------------+++++++++++++--------------------------- > > > > > > > > The components, protocols, and content documents defined by this > > working group can be used in multiple ways such as top-down assessment > > of policy compliance, notification of compliance posture change > > initiated by a change made on an endpoint, determination of affected > > assets based on reportage of a new vulnerability, ad-hoc queries of specific > asset settings, etc. > > > > The initial focus of this working group is the performance of top-down > > policy assessments using the following steps: > > > > > > A policy-driven assessment: > > > > A) The content repository is queried for the content documents that > > codify the policy/policies of interest. > > > > B) Assets are selected that match the criteria of the selected > > policy/policies. The method of selection can include enumeration from > > known asset inventories, direct query of known assets, network > > discovery, etc. Selection of assets may be further refined by other > > criteria such as ownership, location, role, time of day, etc. > > > > (Note: I used the term "asset" instead of "endpoint" because it > > includes software assets, allowing for assessments of, for example, > > web servers, virtual machine instance settings, a virtualized database > > instance running on a cluster, etc) > > > > > > Alternatively, and asset-driven assessment: > > > > A) Assets are selected based on a set of criteria (ownership, > > location, role, time of day, etc.). > > > > B) For each asset, determine and retrieve the applicable > > policy/policies from the content repository. > > > > > > For each asset: > > > > 1) Determine what elements of posture information to collect based on > > the policy/policies to be evaluated. > > > > > > 2) For each element of the asset posture data, identify the mechanism > > for data collection and what content is needed, if any, to support > > data collection. > > > > (Note: I assume this means if the collection is via direct endpoint > > query, CMDB retrieval, etc. That means a layer of meta data is needed > > that we haven't really talked about: authentication information, DB > > host/port, connection type, etc. Since this is an explicit step in > > the process, should that data also be part of the standard?) > > > > > > 3) Harvest the actual values pertaining to posture elements identified > > in step 3 from the targeted asset(s). > > > > 4) Report collected asset posture. This will likely be done on an > > individual basis for each identified asset , requiring aggregation of > > data collected from multiple asset as needed based on the identified > policy. > > > > > > > > > > > > > > On 6/2/2013 11:57 AM, Adam W. Montville wrote: > > > All: > > > > > > I've taken the charter > > > (http://datatracker.ietf.org/doc/charter-ietf-sacm/) > > and comments submitted in a variety of threads > > (http://www.ietf.org/mail- > > archive/web/sacm/current/threads.html) and put the following together. > > > > > > I would love to see a dramatic increase in SACM participation > > > throughout > > this month - especially relating to the charter, which should be our > > primary focus at this point, and then limited to the first several milestones. > > > > > > My concern is that SACM momentum is trailing off at a point when it > > > needs > > to be maintaining, if not increasing, from that level we saw at IETF 86. > > > > > > The following is the modified charter text: > > > > > > Securing information and the systems that store, process, and > > > transmit that > > information is a challenging task for organizations of all sizes, and > > many security practitioners spend much of their time on manual processes. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. > > Automating these routine tasks would free security practitioners to > > focus on high priority tasks, and should improve operators' ability to > > prioritize risk based on timely information about threats and > > vulnerabilities. This working group will define security automation > > protocols and data format standards in support of information security > > processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks related > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > > cases pertaining to the ass es > > > sment of endpoint posture (using the definitions of Endpoint and > > > Posture > > from RFC 5209). > > > > > > The working group will, whenever reasonable and possible, reuse > > > existing > > protocols, mechanisms, information and data models. Of particular > > interest to this working group are existing industry standards, > > preferably IETF standards, that could support automation of asset, > > change, configuration, and vulnerability management. > > > > > > The working group will define: > > > > > > 1. A set of standards to enable assessment of endpoint posture. This > > > area > > of focus provides for necessary language and data format specifications. > > > > > > 2. A set of standards for interacting with repositories of content > > > related to > > assessment of endpoint posture. > > > > > > Assessment of endpoint posture assessment entails the following > > > general > > steps: > > > > > > 1. Relevant endpoints are identified and classified based on the > > > targets of > > the policy/policies to be evaluated > > > > > > 2. For each endpoint, determine what elements of posture information > > > to > > collect based on the policy/policies to be evaluated > > > > > > 3. For each element of the endpoint posture data, identify the > > > mechanism > > for data collection and what content is needed, if any, to support > > data collection > > > > > > 4. Retrieve any content needed for data collection. Configuration > > > checks > > pertaining to a particular posture element may be used to support data > > collection. > > > > > > 5. Harvest the actual values pertaining to posture elements > > > identified in > > step 3 from the endpoint. > > > > > > 6. Report collected endpoint posture as identified in step 2. This > > > will likely > > be done on an individual basis for each identified endpoint, requiring > > aggregation of data collected from multiple endpoints as needed based > > on the identified policy. > > > > > > This approach to endpoint posture collection enables multiple > > > policies to be > > evaluated based on a single data collection activity. Policies will be > > evaluated by comparing available endpoint posture data according to > > rules expressed in the policy. Typically, these rules will compare the > > actual value against an expected value or range for specific posture > > elements. In some cases, the posture element may pertain to software > > installation state, in which case the actual and expected values may > > be "installed" or "not installed." Evaluation of multiple posture elements > may be combined using Boolean logic. > > > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. a NEA-specific use vs. a > > generally applicable assessment used during continuous monitoring). > > In addition, content repositories are expected to store up-to-date > > dictionary of specific enumerations, such as those used for > > configuration element identifiers, asset classifications, vulnerability > identifiers, and so on. > > > > > > This working group will achieve the following deliverables: > > > > > > - An Informational document on Use Cases > > > - An Informational document on Requirements > > > - An Informational document on SACM Architecture > > > - A standards-track document specifying a protocol and data format > > > for > > retrieving configuration and policy information for driving data > > collection and analysis > > > - A standards-track document specifying a protocol and data format > > > for > > collecting actual endpoint posture > > > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > > other SDOs which can be used as-is or as a starting point for > > developing solutions to the SACM requirements. The working group may > > decide to make of this document an Informational RFC, but this is not a > mandatory deliverable. > > > > > > The working group will work in close coordination with other WGs in > > > the > > IETF (including, but not limited to MILE and NEA) in order to create > > solutions that do not overlap (for example for the repository access > > protocol) and can be used or re-used to meet the goals of more than one > working group. > > > > > > In accordance with existing IETF processes, the group will > > > communicate > > with and invite participation from other relevant standards bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison relationships. > > > > > > SACM-related efforts are largely aligned, and may overlap, with > > > other IETF > > (and non-IETF) standardization efforts. There are common "problems" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > > interest to SACM is understanding and respecting the distinctions > > between itself and NEA and MILE. > > > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data- collection instructions. > > > > > > The MILE data formats provide a format to describe incident, > > > threat-related > > incident, and indicator information. SACM data formats provide ways > > to understand what endpoints are in your environment, whether they > > meet policy requirements, and their current configuration state. The > > data exchanged in MILE, supplementing the SACM data, creates enhanced > > situational awareness, thus enabling increased understanding of > > current threats and mitigations. The combined SACM and MILE data sets > > become a powerful tool to automate security with descriptions of > > endpoints, known vulnerabilities to those endpoints, and thier > > configurations along with an understanding of layered defenses. Then, > > injecting known threat information with mitigation options assists the > > organization in turning detailed security decisions into > > business-relevant decisions. The MILE protocols, RID and ROLIE, > > enable the exchange of structured data and are designed to carry any > > structured format. While RID may be use d > > > in multiple sharing models and provides multiple communication > > > flows > > (report, query, etc.) with the ability to enable peer-to-peer object > > level security, ROLIE provides a RESTful repository transport option > > with only the need for a browser on the client end, removing deployment > barriers. > > > > > > After the work items in the current charter have been submitted to > > > and > > approved by the IESG, the WG will recharter or close. > > > > > > Goals and Milestones > > > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > > taking > > into consideration RFC5706 and RFC3535 > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > > Architecture > > > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > > related > > standards work > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > > and data > > format for retrieving configuration and policy information for driving > > data collection and analysis > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol > > > and data > > format for collecting actual endpoint posture > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > > > Cases for > > consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > > Requirements > > for consideration as Informational RFC > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > > protocol and > > data format for retrieving configuration and policy information for > > driving data collection and analysis for consideration as > > standards-track RFC > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > > and data > > format for collecting actual endpoint posture for consideration as > > standards- track RFC > > > > > > _______________________________________________ > > > 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 > ... > > > 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. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From Adam.Montville@cisecurity.org Fri Jun 7 10:23:40 2013 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 425CA21F994F for ; Fri, 7 Jun 2013 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caeGGtwlskA0 for ; Fri, 7 Jun 2013 10:23:31 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.205]) by ietfa.amsl.com (Postfix) with ESMTP id D30F421F9402 for ; Fri, 7 Jun 2013 10:23:25 -0700 (PDT) Received: from [216.82.241.211:61721] by server-13.bemta-8.messagelabs.com id EF/A3-30414-A0712B15; Fri, 07 Jun 2013 17:23:22 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-9.tower-85.messagelabs.com!1370625801!37050082!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 2775 invoked from network); 7 Jun 2013 17:23:21 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-9.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 17:23:21 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 13:23:15 -0400 From: Adam Montville To: Gunnar Engelbach , "Kent_Landfield@McAfee.com" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUMcAgAAUCYD//8Y5AA== Date: Fri, 7 Jun 2013 17:23:14 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F389A@CISEXCHANGE1.msisac.org.local> References: <3CBA099FBA0AB843895D72474092B8CF288E70@MIVEXAMER1N1.corp.nai.org> <51B20EC5.4060407@ThreatGuard.com> In-Reply-To: <51B20EC5.4060407@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adam@stoicsecurity.com" , "david.waltermire@nist.gov" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:23:40 -0000 > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Friday, June 07, 2013 9:48 AM > To: Kent_Landfield@McAfee.com > Cc: Adam Montville; david.waltermire@nist.gov; adam@stoicsecurity.com; > sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 >=20 > Policy, as a codification of best practices, regulatory requirements, or= known > vulnerabilities, is certainly the starting point. >=20 > The current model of top-down whole-policy assessment makes the most > sense as a starting point, but it's also inefficient and leaves a gap of= exposure > between the time of a system change and the next assessment. > Closing that gap by increasing the periodicity of scans just increases t= he > amount of resources dedicated to security assessments (and most of which= > will show no delta), and performing security assessments is not the reas= on > why organizations put money into networks. This supports the continuous monitoring part of "Security Automation and C= ontinuous Monitoring." =20 >=20 > Processing change notifications is the way out of that spiral. That's n= ot to say > that this WG will deal with that to start with, or ever, but it all goes= back to > the policies, which are the core of this WG. Agree. >=20 > So my point is that while we are focusing on the more traditional approa= ch, > let's keep the event-oriented future in mind to the extent that we are a= ble. Agree. >=20 > Similarly, Rainer Enders had a very good point about endpoint trust. My= feel > for this WG is that it won't be addressed, but it's an important factor = to keep > in mind. That might just be as simple as including a field that indicat= es the > trust level of the collected data items. Agree. >=20 >=20 > --gun >=20 >=20 > On 6/7/2013 11:36 AM, Kent_Landfield@McAfee.com wrote: > > Are we straying from the intent here? Policy driven assessments are > > normally evaluated against a known good. Is this system running the > > approved software, approved services with the recommended > > configuration and permissions, etc... If we are now talking about an > > event driven notification architecture, are we looking as something li= ke IF- > MAP ? > > This seems to be straying and expanding the focus of the charter. I > > thought that was what we were trying to avoid. > > > > *Kent Landfield* > > > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > > > From: Adam Montville > > > > Date: Friday, June 7, 2013 10:07 AM > > To: David Waltermire > >, Gunnar Engelbach > > > >, "Adam W. Montville" > > > > > Cc: "sacm@ietf.org " > > > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org > > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Waltermire, David A. > > Sent: Wednesday, June 05, 2013 7:06 AM > > To: Gunnar Engelbach; Adam W. Montville > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > Great catch on change notification! The challenge with polling= > > on a periodic > > basis is that the sample rate needs to be twice the rate of > > change. Using > > periodic data collection, there is a potential risk of missing= a > > critical security- > > related change event that might indicate an attack is underway= . > > If polling is > > performed outside the attack window, it is possible that the > > attack won't be > > noticed. > > > > > > Is this becoming too prescriptive in a way? You rightly point out= > > =20 that attacks could be missed with a polling mechanism, but how a= re > > agent-less solutions going to implement anything else? > > > > Also, is this the type of information we need to have in a charter= > > or is this better applied in the work products of the WG? I think= > > the latter. > > > > > > Policy driven assessment, as you have written below, can be us= ed > > to address > > this type of detection using most of the same bits and > > bytes. To support > > event-driven notification, the endpoint assessment software wi= ll > > need to be > > told what events to collect and pass on. Most of what is > > described in steps 1- > > 4 of the draft charter still apply in setting up the > > event-driven collection > > environment. What is different is how steps 5 and 6 work. For > > step 5, the > > values are not harvested per se; they are generated based on c= hange > > notifications. For step 6, incremental changes are reported on= a > > continuous > > basis, until the endpoint is instructed not to collect those > > events anymore. > > > > > > Step 5 would need to be updated to accommodate change notification= , > > such that results are either harvested or reported. But, again, I= > > think this belongs in our work products and not the charter. > > > > This is a desirable capability for end-user organizations and = I > > believe it should > > be reflected in the charter. > > > > > > The more we carry on this discussion the more I question having > > anything other than an exemplary list of steps to help describe th= e > > concept of "configuration assessment." We can add language to the= > > charter without needing to enumerate all the possible use cases (w= e > > have a document for that already) and then ensure the assessment > > steps we provide are generic - remember the only reason they were > > included were to provide additional context for an uninitiated > > reader to better understand what this WG is about. > > > > To be more generic, we can take the list and turn it into somethin= g > > like this (I think Sean had not wanted this list to be modified, > > but...): > > > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > > > This should be enough to provide context to an external reader to > > *generally* understand the problem space this WG addresses (would= > > be interesting to validate by getting someone wholly unfamiliar wi= th > > this problem domain to review). > > > > To me, this is perfectly acceptable - it's possible for the WG to > > leave the details (i.e. policy-driven vs. asset-driven, assessment= > > polling vs. near real-time assessment, and so on) to the Use Case > > and Architecture documents. > > > > Finally, I'd like to point out that the milestones and deliverable= s > > for this WG, as expressed in the present draft charter, are fairly= > > encompassing as well. They do not get into the details - especial= ly > > in light of the lengthy list Gunnar shared. > > > > Sincerely, > > Dave > > > -----Original Message----- > > > From:sacm-bounces@ietf.org > > [mailto:sacm-bounces@ietf.org] On Behalf > > > Of Gunnar Engelbach > > > Sent: Tuesday, June 04, 2013 1:20 PM > > > To: Adam W. Montville > > > Cc:sacm@ietf.org > > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > > > > My primary quibbles are below, but I'd like to start by high= lighting > > > something Stephen Whitlock said: "...deviations from standa= rd > > > configurations (whether by accident or intent) would result = in a > > notification..." > > > > > > Going back to Dave Waltermire's proposed architecture, it in= cluded > > > change notification originating from endpoints which helps f= eed > > > Stephen's ideal, and I don't see an allowance for that in th= is revision. > > > > > > Real time compliance/vulnerability notification originating = from > > > endpoint events is a desirable security goal that I think fa= lls within > > > the scope of this WG. > > > > > > There is also a significant lag between the formation of a n= ew WG and > > > the delivery of usable products. > > > > > > So, while top-down assessments, seems to be plenty for this = WG to > gnaw > > > on at the moment, I'd like to also keep bottom-up in mind so= that any > > > work done now doesn't preclude that as a follow-on. And, > preferably, > > > makes it possible to quickly add that next. > > > > > > > > > There also seems to be a chicken-and-egg type of thing of se= lection > of > > > policy versus selection of assets as the starting point. I = think both > > > are valid so I tried, clumsily, to address that in my revisi= on of the > > > assessment steps, to follow. > > > > > > ---------------------------+++++++++++++--------------------= ------- > > > > > > > > > > > > The components, protocols, and content documents defined by = this > > > working group can be used in multiple ways such as top-down > assessment > > > of policy compliance, notification of compliance posture cha= nge > > > initiated by a change made on an endpoint, determination of > affected > > > assets based on reportage of a new vulnerability, ad-hoc que= ries of > specific > > asset settings, etc. > > > > > > The initial focus of this working group is the performance o= f top- > down > > > policy assessments using the following steps: > > > > > > > > > A policy-driven assessment: > > > > > > A) The content repository is queried for the content documen= ts that > > > codify the policy/policies of interest. > > > > > > B) Assets are selected that match the criteria of the select= ed > > > policy/policies. The method of selection can include enumer= ation > from > > > known asset inventories, direct query of known assets, netwo= rk > > > discovery, etc. Selection of assets may be further refined = by other > > > criteria such as ownership, location, role, time of day, etc= . > > > > > > (Note: I used the term "asset" instead of "endpoint" becaus= e it > > > includes software assets, allowing for assessments of, for e= xample, > > > web servers, virtual machine instance settings, a virtualize= d database > > > instance running on a cluster, etc) > > > > > > > > > Alternatively, and asset-driven assessment: > > > > > > A) Assets are selected based on a set of criteria (ownership= , > > > location, role, time of day, etc.). > > > > > > B) For each asset, determine and retrieve the applicable > > > policy/policies from the content repository. > > > > > > > > > For each asset: > > > > > > 1) Determine what elements of posture information to collect= based > on > > > the policy/policies to be evaluated. > > > > > > > > > 2) For each element of the asset posture data, identify the > mechanism > > > for data collection and what content is needed, if any, to s= upport > > > data collection. > > > > > > (Note: I assume this means if the collection is via direct = endpoint > > > query, CMDB retrieval, etc. That means a layer of meta data= is > needed > > > that we haven't really talked about: authentication informa= tion, DB > > > host/port, connection type, etc. Since this is an explicit = step in > > > the process, should that data also be part of the standard?)= > > > > > > > > > 3) Harvest the actual values pertaining to posture elements = identified > > > in step 3 from the targeted asset(s). > > > > > > 4) Report collected asset posture. This will likely be done= on an > > > individual basis for each identified asset , requiring aggre= gation of > > > data collected from multiple asset as needed based on the id= entified > > policy. > > > > > > > > > > > > > > > > > > > > > On 6/2/2013 11:57 AM, Adam W. Montville wrote: > > > > All: > > > > > > > > I've taken the charter > > > > (http://datatracker.ietf.org/doc/charter-ietf-sacm/) > > > and comments submitted in a variety of threads > > > (http://www.ietf.org/mail- > > > archive/web/sacm/current/threads.html) and put the following= > together. > > > > > > > > I would love to see a dramatic increase in SACM participat= ion > > > > throughout > > > this month - especially relating to the charter, which shoul= d be our > > > primary focus at this point, and then limited to the first s= everal > milestones. > > > > > > > > My concern is that SACM momentum is trailing off at a poin= t when > it > > > > needs > > > to be maintaining, if not increasing, from that level we saw= at IETF 86. > > > > > > > > The following is the modified charter text: > > > > > > > > Securing information and the systems that store, process, = and > > > > transmit that > > > information is a challenging task for organizations of all s= izes, and > > > many security practitioners spend much of their time on manu= al > processes. > > > Standardized processes to collect, verify, and update securi= ty system > > > configurations would allow easier automation of the processe= s. > > > Automating these routine tasks would free security practitio= ners to > > > focus on high priority tasks, and should improve operators' = ability to > > > prioritize risk based on timely information about threats an= d > > > vulnerabilities. This working group will define security aut= omation > > > protocols and data format standards in support of informatio= n > security > > > processes and practices. These standards will help security > > > practitioners to be more effective by automating routine tas= ks > related > > > to client and server security, freeing them to focus on more= advanced > > > tasks. The initial focus of this work is to address enterpri= se use > > > cases pertaining to the ass es > > > > sment of endpoint posture (using the definitions of Endp= oint and > > > > Posture > > > from RFC 5209). > > > > > > > > The working group will, whenever reasonable and possible, = reuse > > > > existing > > > protocols, mechanisms, information and data models. Of parti= cular > > > interest to this working group are existing industry standar= ds, > > > preferably IETF standards, that could support automation of = asset, > > > change, configuration, and vulnerability management. > > > > > > > > The working group will define: > > > > > > > > 1. A set of standards to enable assessment of endpoint pos= ture. > This > > > > area > > > of focus provides for necessary language and data format > specifications. > > > > > > > > 2. A set of standards for interacting with repositories of= content > > > > related to > > > assessment of endpoint posture. > > > > > > > > Assessment of endpoint posture assessment entails the foll= owing > > > > general > > > steps: > > > > > > > > 1. Relevant endpoints are identified and classified based = on the > > > > targets of > > > the policy/policies to be evaluated > > > > > > > > 2. For each endpoint, determine what elements of posture > information > > > > to > > > collect based on the policy/policies to be evaluated > > > > > > > > 3. For each element of the endpoint posture data, identify= the > > > > mechanism > > > for data collection and what content is needed, if any, to s= upport > > > data collection > > > > > > > > 4. Retrieve any content needed for data collection. Confi= guration > > > > checks > > > pertaining to a particular posture element may be used to su= pport > data > > > collection. > > > > > > > > 5. Harvest the actual values pertaining to posture element= s > > > > identified in > > > step 3 from the endpoint. > > > > > > > > 6. Report collected endpoint posture as identified in step= 2. This > > > > will likely > > > be done on an individual basis for each identified endpoint,= requiring > > > aggregation of data collected from multiple endpoints as nee= ded > based > > > on the identified policy. > > > > > > > > This approach to endpoint posture collection enables multi= ple > > > > policies to be > > > evaluated based on a single data collection activity. Polici= es will be > > > evaluated by comparing available endpoint posture data accor= ding to > > > rules expressed in the policy. Typically, these rules will c= ompare the > > > actual value against an expected value or range for specific= posture > > > elements. In some cases, the posture element may pertain to > software > > > installation state, in which case the actual and expected va= lues may > > > be "installed" or "not installed." Evaluation of multiple po= sture > elements > > may be combined using Boolean logic. > > > > > > > > Repository protocols are needed to store, update, and retr= ieve > > > configuration checks and other types of content required for= posture > > > assessment (see step 2 above). A content repository is expe= cted to > > > house specific versions of checklists (i.e. benchmarks), may= be > > > required to satisfy different use cases (i.e. a NEA-specific= use vs. a > > > generally applicable assessment used during continuous monit= oring). > > > In addition, content repositories are expected to store up-t= o-date > > > dictionary of specific enumerations, such as those used for > > > configuration element identifiers, asset classifications, vu= lnerability > > identifiers, and so on. > > > > > > > > This working group will achieve the following deliverables= : > > > > > > > > - An Informational document on Use Cases > > > > - An Informational document on Requirements > > =20 > > - An Informational document on SACM Architecture > > > > - A standards-track document specifying a protocol and dat= a format > > > > for > > > retrieving configuration and policy information for driving = data > > > collection and analysis > > > > - A standards-track document specifying a protocol and dat= a format > > > > for > > > collecting actual endpoint posture > > > > > > > > The working group will create an overview of related stand= ards > work > > > Internet-Draft which will document existing work in the IETF= or in > > > other SDOs which can be used as-is or as a starting point fo= r > > > developing solutions to the SACM requirements. The working g= roup > may > > > decide to make of this document an Informational RFC, but th= is is not > a > > mandatory deliverable. > > > > > > > > The working group will work in close coordination with oth= er WGs in > > > > the > > =20 > IETF (including, but not limited to MILE and NEA) in order= to create > > > solutions that do not overlap (for example for the repositor= y access > > > protocol) and can be used or re-used to meet the goals of mo= re than > one > > working group. > > > > > > > > In accordance with existing IETF processes, the group will= > > > > communicate > > > with and invite participation from other relevant standards = bodies > and > > > regulatory organizations, and if necessary reuse existing li= aison > > > relationships or request the establishment of new liaison > relationships. > > > > > > > > SACM-related efforts are largely aligned, and may overlap,= with > > > > other IETF > > > (and non-IETF) standardization efforts. There are common > "problems" > > > found in SACM, that may be addressed by the work done in SNM= P, > IPFIX, > > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of part= icular > > > interest to SACM is understanding and respecting the distinc= tions > > > between itself and NEA and MILE. > > > > > > > > One way the NEA protocols can be used is as the transport = for data > > > collected on the endpoint to an external service or data rep= ository > > > for further analysis and action. NEA may also serve the pur= pose of > > > carrying data- collection instructions. > > > > > > > > The MILE data formats provide a format to describe inciden= t, > > > > threat-related > > > incident, and indicator information. SACM data formats prov= ide ways > > > to understand what endpoints are in your environment, whethe= r > they > > > meet policy requirements, and their current configuration st= ate. The > > > data exchanged in MILE, supplementing the SACM data, creates= > enhanced > > > situational awareness, thus enabling increased understanding= of > > > current threats and mitigations. The combined SACM and MILE= data > sets > > > become a powerful tool to automate security with description= s of > > > endpoints, known vulnerabilities to those endpoints, and thi= er > > > configurations along with an understanding of layered defens= es. > Then, > > > injecting known threat information with mitigation options a= ssists the > > > organization in turning detailed security decisions into > > > business-relevant decisions. The MILE protocols, RID and RO= LIE, > > > enable the exchange of structured data and are designed to c= arry any > > > structured format. While RID may be use d > > > > in multiple sharing models and provides multiple communi= cation > > > > flows > > > (report, query, etc.) with the ability to enable peer-to-pee= r object > > > level security, ROLIE provides a RESTful repository transpor= t option > > > with only the need for a browser on the client end, removing= > deployment > > barriers. > > > > > > > > After the work items in the current charter have been subm= itted to > > > > and > > > approved by the IESG, the WG will recharter or close. > > > > > > > > Goals and Milestones > > > > > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use= Cases > > > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on Req= uirements > > > > taking > > > into consideration RFC5706 and RFC3535 > > > > > > > > Oct. 2013 - Initial submission of an Internet-Draft on SAC= M > > > > Architecture > > > > > > > > Nov. 2013 - Initial submission of an Internet-Draft on ove= rview of > > > > related > > > standards work > > > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a = protocol > > > > and data > > > format for retrieving configuration and policy information f= or driving > > =20 > data collection and analysis > > > > > > > > Jan. 2014 - Initial submission of an Internet-Draft for a = protocol > > > > and data > > > format for collecting actual endpoint posture > > > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft o= n Use > > > > Cases for > > > consideration as Informational RFC > > > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft o= n > > > > Requirements > > > for consideration as Informational RFC > > > > > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft o= n SACM > > > Architecture for consideration as Informational RFC > > > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft f= or a > > > > protocol and > > > data format for retrieving configuration and policy informat= ion for > > > driving data collection and analysis for consideration as > > > standards-track RFC > > > > > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a= protocol > > > > and data > > > format for collecting actual endpoint posture for considerat= ion as > > > standards- track RFC > > > > > > > > _______________________________________________ > > > > 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 > > ... > > > > > > 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 notif= y > > the sender immediately and permanently delete the message and any > > attachments. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 > ... 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 Adam.Montville@cisecurity.org Fri Jun 7 10:24:16 2013 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 17C7021F947C for ; Fri, 7 Jun 2013 10:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY7kBjJqUnQ1 for ; Fri, 7 Jun 2013 10:24:10 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) by ietfa.amsl.com (Postfix) with ESMTP id CDDA521F994A for ; Fri, 7 Jun 2013 10:23:44 -0700 (PDT) Received: from [216.82.250.19:56054] by server-8.bemta-12.messagelabs.com id 50/C0-02708-F1712B15; Fri, 07 Jun 2013 17:23:43 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-11.tower-87.messagelabs.com!1370625822!18407354!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 6616 invoked from network); 7 Jun 2013 17:23:43 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-11.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 17:23:43 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 13:23:36 -0400 From: Adam Montville To: Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxA Date: Fri, 7 Jun 2013 17:23:36 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> In-Reply-To: <51B2085D.2020400@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:24:16 -0000 Dan, I assume you're going to make those updates? > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Friday, June 07, 2013 9:21 AM > To: Adam Montville > Cc: Waltermire, David A.; Gunnar Engelbach; Adam W. Montville; > sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > Okay so this looks like it's going to work. Let's make the changes in t= he draft > charter. >=20 > spt >=20 > On 6/7/13 12:00 PM, Adam Montville wrote: > > [snip] > >>> To be more generic, we can take the list and turn it into something > >>> like this > >> (I think Sean had not wanted this list to be modified, but...): > >>> > >>> 1. Identify endpoints > >>> 2. Determine specific endpoint elements to assess 3. Collect actual > >>> value of elements 4. Compare actual element values to expected > >>> element values 5. Report results > > [snip] > >> The charter need not to go in to gory detail and we can only guess > >> what other people who haven't been involved will say when the charter= > >> goes out for external review. I'm good with the existing bullet list= > >> or this shortened one as long as you can capture that this can > >> supports policy-driven and/or asset- driven models. > >> > >> spt > > > > If we're going to "capture" that this supports policy-/asset-driven mo= dels, > then the abbreviated list is better with some explanatory text that simp= ly > makes that claim. What if we simply preface the list with something lik= e this: > > > > "The following general steps accommodate both policy-driven and asset-= > driven assessment." > > > > Adam > > > > 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 i= s > strictly prohibited. Please notify the sender immediately and permanent= ly > delete the message and any attachments. > > >=20 > ... 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 Adam.Montville@cisecurity.org Fri Jun 7 11:26:25 2013 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 5DE0C21F9798 for ; Fri, 7 Jun 2013 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgfGV3Ycu80W for ; Fri, 7 Jun 2013 11:26:20 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCB521F994C for ; Fri, 7 Jun 2013 11:26:03 -0700 (PDT) Received: from [216.82.250.19:23843] by server-16.bemta-12.messagelabs.com id CE/23-15704-4B522B15; Fri, 07 Jun 2013 18:25:56 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-2.tower-87.messagelabs.com!1370629554!18455552!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 19364 invoked from network); 7 Jun 2013 18:25:55 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-2.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 18:25:55 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 14:25:48 -0400 From: Adam Montville To: Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVA= Date: Fri, 7 Jun 2013 18:25:48 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:26:25 -0000 Ok, I went ahead and updated the draft charter language - see below. Hopefully this is right. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Securing information and the systems that store, process, and transmit tha= t information is a challenging task for organizations of all sizes, and ma= ny security practitioners spend much of their time on manual processes. St= andardized processes to collect, verify, and update security system config= urations would allow easier automation of the processes. Automating these = routine tasks would free security practitioners to focus on high priority = tasks, and should improve operators' ability to prioritize risk based on t= imely information about threats and vulnerabilities. This working group wi= ll define security automation protocols and data format standards in suppo= rt of information security processes and practices. These standards will h= elp security practitioners to be more effective by automating routine task= s related to client and server security, freeing them to focus on more adv= anced tasks. The initial focus of this work is to address enterprise use c= ases pertaining to the assessment of endpoint posture (using the definitio= ns of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing p= rotocols, mechanisms, information and data models. Of particular interest = to this working group are existing industry standards, preferably IETF sta= ndards, that could support automation of asset, change, configuration, and= vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area = of focus provides for necessary language and data format specifications. 2. A set of standards for interacting with repositories of content related= to assessment of endpoint posture. Assessment of endpoint posture assessment entails the following general st= eps, which accommodate policy-driven and asset-driven assessment: 1. Identify endpoints 2. Determine specific endpoint elements to=20assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to = be evaluated based on a single data collection activity. Policies will be = evaluated by comparing available endpoint posture data according to rules = expressed in the policy. Typically, these rules will compare the actual va= lue against an expected value or range for specific posture elements. In s= ome cases, the posture element may pertain to software installation state,= in which case the actual and expected values may be "installed" or "not i= nstalled." Evaluation of multiple posture elements may be combined using B= oolean logic. Repository protocols are needed to store, update, and retrieve configurati= on checks and other types of content required for posture assessment (see = step 2 above). A content repository is expected to house specific version= s of checklists (i.e. benchmarks), may be required to satisfy different us= e cases (i.e. a NEA-specific use vs. a generally applicable assessment use= d during continuous monitoring). In addition, content repositories are ex= pected to store up-to-date dictionary of specific enumerations, such as th= ose used for configuration element identifiers, asset classifications, vul= nerability identifiers, and so on. This working group will achieve the following deliverables: - An Informational document on Use Cases - An Informational document on Requirements - An Informational document on SACM Architecture - A standards-track document specifying a protocol and data format for ret= rieving configuration and policy information for driving data collection a= nd analysis - A standards-track document specifying a protocol and data format for col= lecting actual endpoint posture=20 The working group will create an overview of related standards work Intern= et-Draft which will document existing work in the IETF or in other SDOs wh= ich can be used as-is or as a starting point for developing solutions to t= he SACM requirements. The working group may decide to make of this documen= t an Informational RFC, but this is not a mandatory deliverable. =20 The working group will work in close coordination with other WGs in the IE= TF (including, but not limited to MILE and NEA) in order to create solutio= ns that do not overlap (for example for the repository access protocol) an= d can be used or re-used to meet the goals of more than one working group.= =20 In accordance with existing IETF processes, the group will communicate wit= h and invite participation from other relevant standards bodies and regula= tory organizations, and if necessary reuse existing liaison relationships = or request the establishment of new liaison relationships. SACM-related efforts are largely aligned, and may overlap, with other IETF= (and non-IETF) standardization efforts. There are common "problems" foun= d in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF,= SYSLOG, NEA, MILE, and potentially others. Of particular interest to SAC= M is=20understanding and respecting the distinctions between itself and NE= A and MILE. One way the NEA protocols can be used is as the transport for data collect= ed on the endpoint to an external service or data repository for further a= nalysis and action. NEA may also serve the purpose of carrying data-colle= ction instructions. The MILE data formats provide a format to describe incident, threat-relate= d incident, and indicator information. SACM data formats provide ways to = understand what endpoints are in your environment, whether they meet polic= y requirements, and their current configuration state. The data exchanged= in MILE, supplementing the SACM data, creates enhanced situational awaren= ess, thus enabling increased understanding of current threats and mitigati= ons. The combined SACM and MILE data sets become a powerful tool to autom= ate security with descriptions of endpoints, known vulnerabilities to thos= e endpoints, and thier configurations along with an understanding of layer= ed defenses. Then, injecting known threat information with mitigation opt= ions assists the organization in turning detailed security decisions into = business-relevant decisions. The MILE protocols, RID and ROLIE, enable th= e exchange of structured data and are designed to carry any structured for= mat. While RID may be used in multiple sharing models and provides multip= le communication flows (report, query, etc.) with the ability to enable pe= er-to-peer object level security, ROLIE provides a RESTful repository tran= sport option with only the need for a browser on the client end, removing = deployment barriers. After the work items in the current charter have been submitted to and app= roved by the IESG, the WG will recharter or close. =20 Goals and Milestones Sep. 2013 - Initial submission of an Internet-Draft on Use Cases=20 Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking= into consideration RFC5706 and RFC3535 Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture=20= Nov. 2013 - Initial submission of an=20Internet-Draft on overview of relat= ed standards work=20 Jan. 2014 - Initial submission of an Internet-Draft for a protocol and dat= a format for retrieving configuration and policy information for driving d= ata collection and analysis Jan. 2014 - Initial submission of an Internet-Draft for a protocol and dat= a format for collecting actual endpoint posture=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for = consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements f= or consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Architect= ure for consideration as Informational RFC=20 Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol an= d data format for retrieving configuration and policy information for driv= ing data collection and analysis for consideration as standards-track RFC=20= Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and da= ta format for collecting=20actual endpoint posture for consideration as st= andards-track RFC > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, June 07, 2013 10:24 AM > To: Sean Turner > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > Dan, I assume you're going to make those updates? >=20 > > -----Original Message----- > > From: Sean Turner [mailto:turners@ieca.com] > > Sent: Friday, June 07, 2013 9:21 AM > > To: Adam Montville > > Cc: Waltermire, David A.; Gunnar Engelbach; Adam W. Montville; > > sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > Okay so this looks like it's going to work. Let's make the changes in= > > the draft charter. > > > > spt > > > > On 6/7/13 12:00 PM, Adam Montville wrote: > > > [snip] > > >>> To be more generic, we can take the list and turn it into > > >>> something like this > > >> (I think Sean had not wanted this list to be modified, but...): > > >>> > > >>> 1. Identify endpoints > > >>> 2. Determine specific endpoint elements to assess 3. Collect > > >>> actual value of elements 4. Compare actual element values to > > >>> expected element values 5. Report results > > > [snip] > > >> The charter need not to go in to gory detail and we can only guess > > >> what other people who haven't been involved will say when the > > >> charter goes out for external review. I'm good with the existing > > >> bullet list or this shortened one as long as you can capture that > > >> this can supports policy-driven and/or asset- driven models. > > >> > > >> spt > > > > > > If we're going to "capture" that this supports policy-/asset-driven > > > models, > > then the abbreviated list is better with some explanatory text that > > simply makes that claim. What if we simply preface the list with some= thing > like this: > > > > > > "The following general steps accommodate both policy-driven and > > > asset- > > driven assessment." > > > > > > Adam > > > > > > 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. > > > > > > > ... >=20 > This message and attachments may contain confidential information. If i= t > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments i= s > strictly prohibited. Please notify the sender immediately and permanent= ly > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... 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 Adam.Montville@cisecurity.org Fri Jun 7 12:10:31 2013 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 4EC7521F9991 for ; Fri, 7 Jun 2013 12:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBMCuh2Do7go for ; Fri, 7 Jun 2013 12:10:26 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) by ietfa.amsl.com (Postfix) with ESMTP id B101C21F9970 for ; Fri, 7 Jun 2013 12:10:25 -0700 (PDT) Received: from [216.82.242.179:13121] by server-2.bemta-8.messagelabs.com id 51/88-22532-02032B15; Fri, 07 Jun 2013 19:10:24 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-2.tower-86.messagelabs.com!1370632223!46278826!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 27176 invoked from network); 7 Jun 2013 19:10:23 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-2.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 19:10:23 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 15:10:17 -0400 From: Adam Montville To: Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YA== Date: Fri, 7 Jun 2013 19:10:15 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 19:10:31 -0000 Apparently, I didn't include all the information or grabbed the wrong exam= ple charter. Apologies - specifically to Dave for omitting his contributi= ons! Either he or I will provide a corrected update. Adam > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, June 07, 2013 11:26 AM > To: Sean Turner > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > Ok, I went ahead and updated the draft charter language - see below. >=20 > Hopefully this is right. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Securing information and the systems that store, process, and transmit t= hat > information is a challenging task for organizations of all sizes, and ma= ny > security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. Automatin= g > these routine tasks would free security practitioners to focus on high p= riority > tasks, and should improve operators' ability to prioritize risk based on= timely > information about threats and vulnerabilities. This working group will d= efine > security automation protocols and data format standards in support of > information security processes and practices. These standards will help > security practitioners to be more effective by automating routine tasks > related to client and server security, freeing them to focus on more > advanced tasks. The initial focus of this work is to address enterprise = use > cases pertaining to the asses sment of endpoint posture (using the > definitions of Endpoint and Posture from RFC 5209). >=20 > The working group will, whenever reasonable and possible, reuse existing= > protocols, mechanisms, information and data models. Of particular intere= st > to this working group are existing industry standards, preferably IETF > standards, that could support automation of asset, change, configuration= , > and vulnerability management. >=20 > The working group will define: >=20 > 1. A set of standards to enable assessment of endpoint posture. This are= a of > focus provides for necessary language and data format specifications. >=20 > 2. A set of standards for interacting with repositories of content relat= ed to > assessment of endpoint posture. >=20 > Assessment of endpoint posture assessment entails the following general > steps, which accommodate policy-driven and asset-driven assessment: >=20 > 1. Identify endpoints >=20 > 2. Determine specific endpoint elements to assess >=20 > 3. Collect actual value of elements >=20 > 4. Compare actual element values to expected element values >=20 > 5. Report results >=20 > This approach to endpoint posture collection enables multiple policies t= o be > evaluated based on a single data collection activity. Policies will be e= valuated > by comparing available endpoint posture data according to rules expresse= d in > the policy. Typically, these rules will compare the actual value against= an > expected value or range for specific posture elements. In some cases, th= e > posture element may pertain to software installation state, in which cas= e the > actual and expected values may be "installed" or "not installed." Evalua= tion > of multiple posture elements may be combined using Boolean logic. >=20 > Repository protocols are needed to store, update, and retrieve configura= tion > checks and other types of content required for posture assessment (see > step 2 above). A content repository is expected to house specific versi= ons of > checklists (i.e. benchmarks), may be required to satisfy different use c= ases > (i.e. a NEA-specific use vs. a generally applicable assessment used duri= ng > continuous monitoring). In addition, content repositories are expected = to > store up-to-date dictionary of specific enumerations, such as those used= for > configuration element identifiers, asset classifications, vulnerability > identifiers, and so on. >=20 > This working group will achieve the following deliverables: >=20 > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data collect= ion and > analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture >=20 > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in other= SDOs > which can be used as-is or as a starting point for developing solutions = to the > SACM requirements. The working group may decide to make of this > document an Informational RFC, but this is not a mandatory deliverable. >=20 > The working group will work in close coordination with other WGs in the = IETF > (including, but not limited to MILE and NEA) in order to create solution= s that > do not overlap (for example=20for the repository access protocol) and ca= n be > used or re-used to meet the goals of more than one working group. >=20 > In accordance with existing IETF processes, the group will communicate w= ith > and invite participation from other relevant standards bodies and regula= tory > organizations, and if necessary reuse existing liaison relationships or = request > the establishment of new liaison relationships. >=20 > SACM-related efforts are largely aligned, and may overlap, with other IE= TF > (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular inter= est > to SACM is understanding and respecting the distinctions between itself = and > NEA and MILE. >=20 > One way the NEA protocols can be used is as the transport for data colle= cted > on the endpoint to an external service or data repository for further an= alysis > and action. NEA may also serve the purpose of carrying=20data-collectio= n > instructions. >=20 > The MILE data formats provide a format to describe incident, threat-rela= ted > incident, and indicator information. SACM data formats provide ways to > understand what endpoints are in your environment, whether they meet > policy requirements, and their current configuration state. The data > exchanged in MILE, supplementing the SACM data, creates enhanced > situational awareness, thus enabling increased understanding of current > threats and mitigations. The combined SACM and MILE data sets become a > powerful tool to automate security with descriptions of endpoints, known= > vulnerabilities to those endpoints, and thier configurations along with = an > understanding of layered defenses. Then, injecting known threat > information with mitigation options assists the organization in turning > detailed security decisions into business-relevant decisions. The MILE > protocols, RID and ROLIE, enable the exchange of structured data and are= > designed to carry any structured format. While RID may be used in mult= iple > sharing models and provides multiple communication flows (report, query,= > etc.) with the ability to enable peer-to-peer object level security, ROL= IE > provides a RESTful repository transport option with only the need for a > browser on the client end, removing deployment barriers. >=20 >=20 > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. >=20 > Goals and Milestones >=20 > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >=20 > Oct. 2013 - Initial submission of an Internet-Draft on Requirements taki= ng > into consideration RFC5706 and RFC3535 >=20 > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture= >=20 > Nov. 2013 - Initial submission of an Internet-Draft on overview of relat= ed > standards work >=20 > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata > format for retrieving configuration and policy information for driving d= ata > collection and analysis >=20 > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata > format for collecting actual endpoint posture >=20 > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases fo= r > consideration as Informational RFC >=20 > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements= for > consideration as Informational RFC >=20 > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC >=20 > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol = and > data format for retrieving configuration and policy information for driv= ing > data collection and analysis for consideration as standards-track RFC >=20 > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and = data > format for collecting actual endpoint posture for consideration as stand= ards- > track RFC >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Friday, June 07, 2013 10:24 AM > > To: Sean Turner > > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > > sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > Dan, I assume you're going to make those updates? > > > > > -----Original Message----- > > > From: Sean Turner [mailto:turners@ieca.com] > > > Sent: Friday, June 07, 2013 9:21 AM > > > To: Adam Montville > > > Cc: Waltermire, David A.; Gunnar Engelbach; Adam W. Montville; > > > sacm@ietf.org > > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > Okay so this looks like it's going to work. Let's make the changes > > > in the draft charter. > > > > > > spt > > > > > > On 6/7/13 12:00 PM, Adam Montville wrote: > > > > [snip] > > > >>> To be more generic, we can take the list and turn it into > > > >>> something like this > > > >> (I think Sean had not wanted this list to be modified, but...): > > > >>> > > > >>> 1. Identify endpoints > > > >>> 2. Determine specific endpoint elements to assess 3. Collect > > > >>> actual value of elements 4. Compare actual element values to > > > >>> expected element values 5. Report results > > > > [snip] > > > >> The charter need not to go in to gory detail and we can only > > > >> guess what other people who haven't been involved will say when > > > >> the charter goes out for external review. I'm good with the > > > >> existing bullet list or this shortened one as long as you can > > > >> capture that this can supports policy-driven and/or asset- driven= > models. > > > >> > > > >> spt > > > > > > > > If we're going to "capture" that this supports > > > > policy-/asset-driven models, > > > then the abbreviated list is better with some explanatory text that > > > simply makes that claim. What if we simply preface the list with > > > something > > like this: > > > > > > > > "The following general steps accommodate both policy-driven and > > > > asset- > > > driven assessment." > > > > > > > > Adam > > > > > > > > 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. > > > > > > > > > > ... > > > > 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. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > ... >=20 > This message and attachments may contain confidential information. If i= t > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments i= s > strictly prohibited. Please notify the sender immediately and permanent= ly > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... 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 Adam.Montville@cisecurity.org Fri Jun 7 12:18:21 2013 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 7DEAE21F9798 for ; Fri, 7 Jun 2013 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbPS5y8CkDQX for ; Fri, 7 Jun 2013 12:18:16 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.6]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3521F96ED for ; Fri, 7 Jun 2013 12:18:16 -0700 (PDT) Received: from [216.82.250.19:63006] by server-6.bemta-12.messagelabs.com id EA/7E-08226-8F132B15; Fri, 07 Jun 2013 19:18:16 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-12.tower-87.messagelabs.com!1370632694!14579898!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 30351 invoked from network); 7 Jun 2013 19:18:15 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-12.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 19:18:15 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 15:18:07 -0400 From: Adam Montville To: Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAAAQYg Date: Fri, 7 Jun 2013 19:18:07 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F3AE0@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 19:18:21 -0000 Updated... Dave, let me know if I missed anything of yours. Likewise for= anyone else :-) ---------------------- Securing information and the systems that store, process, and transmit tha= t information is a challenging task for organizations of all sizes, and ma= ny security practitioners spend much of their time on manual processes. St= andardized processes to collect, verify, and update security system config= urations would allow easier automation of the processes. Automating these = routine tasks would free security practitioners to focus on high priority = tasks, and should improve operators' ability to prioritize risk based on t= imely information about threats and vulnerabilities. This working group wi= ll define security automation protocols and data format standards in suppo= rt of information security processes and practices. These standards will h= elp security practitioners to be more effective by automating routine task= s related to client and server security, freeing them to focus on more adv= anced tasks. The initial focus of this work is to address enterprise use c= ases pertaining to the assessment of endpoint posture (using the definitio= ns of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing p= rotocols, mechanisms, information and data models. Of particular interest = to this working group are existing industry standards, preferably IETF sta= ndards, that could support automation of asset, change, configuration, and= vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area = of focus provides for necessary language and data format specifications. 2. A set of standards for interacting with repositories of content related= to assessment of endpoint posture. Assessment of endpoint posture assessment entails the following general st= eps, which accommodate policy-driven and asset-driven assessment: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to = be evaluated based on a single data collection activity. Policies will be = evaluated by comparing available endpoint posture data according to rules = expressed in the policy. Typically, these rules will compare the actual va= lue against an expected value or range for specific posture elements. In s= ome cases, the posture element may pertain to software installation state,= in which case the actual and expected values may be "installed" or "not i= nstalled." Evaluation of multiple posture elements may be combined using B= oolean logic. Repository protocols are needed to store, update, and retrieve configurati= on checks and other types of content required for posture assessment (see = step 2 above). A content repository is expected to house specific version= s of checklists (i.e. benchmarks), may be required to satisfy different us= e cases (i.e. asset inventory, configuration settings, or vulnerabilities)= . In addition, content repositories are expected to store up-to-date dict= ionary of specific enumerations, such as those used for configuration elem= ent identifiers, asset classifications, vulnerability identifiers, and so = on. This working group will achieve the following deliverables: - An Informational document on Use Cases - An Informational document on Requirements - An Informational document on SACM Architecture - A standards-track document specifying a protocol and data format for ret= rieving configuration and policy information for driving data collection a= nd analysis - A standards-track document specifying a protocol and data format for col= lecting actual endpoint posture=20 The working group will create an overview of related standards work Intern= et-Draft which will document existing work in the IETF or in other SDOs wh= ich can be used as-is or as a starting point for developing solutions to t= he SACM requirements. The working group may decide to make of this documen= t an Informational RFC, but this is not a mandatory deliverable. =20 The working group will work in close coordination with other WGs in the IE= TF (including, but not limited to MILE and NEA) in order to create solutio= ns that do not overlap and can be used or re-used to meet the goals of mor= e than one working group.=20 In accordance with existing IETF processes, the group will communicate wit= h and invite participation from other relevant standards bodies and regula= tory organizations, and if necessary reuse existing liaison relationships = or request the establishment of new liaison relationships. SACM-related efforts are largely aligned, and may overlap, with other IETF= (and non-IETF) standardization efforts. There are common "problems" foun= d in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF,= SYSLOG, NEA, MILE, and potentially others. Of particular interest to SAC= M is understanding and respecting the distinctions between itself and NEA = and MILE. One way the NEA protocols can be used is as the transport for data collect= ed on the endpoint to an external service or data repository for further a= nalysis and action. NEA may also serve the purpose of carrying data-colle= ction instructions. The MILE data formats provide a format to describe incident, threat-relate= d incident, and indicator information. SACM data formats provide ways to = understand what endpoints are in your environment, whether they meet polic= y requirements, and their current configuration state. The data exchanged= in MILE, supplementing the SACM data, creates enhanced situational awaren= ess, thus enabling increased understanding of current threats and mitigati= ons. The combined SACM and MILE data sets become a powerful tool to autom= ate security with descriptions of endpoints, known vulnerabilities to thos= e endpoints, and their configurations along with an understanding of layer= ed defenses. Then, injecting known threat information with mitigation opt= ions assists the organization in turning detailed security decisions into = business-relevant decisions. The MILE protocols, RID and ROLIE, enable th= e exchange of structured data and are designed to carry any structured for= mat. While RID may be used in multiple sharing models and provides multip= le communication flows (report, query, etc.) with the ability to enable pe= er-to-peer object level security, ROLIE provides a RESTful repository tran= sport option with only the need for a browser on the client end, removing = deployment barriers. After the work items in the current charter have been submitted to and app= roved by the IESG, the WG will recharter or close. =20 Goals and Milestones Sep. 2013 - Initial submission of an Internet-Draft on Use Cases=20 Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking= into consideration RFC5706 and RFC3535 Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture=20= Nov. 2013 - Initial submission of an Internet-Draft on overview of related= standards work=20 Jan. 2014 - Initial submission of an Internet-Draft for a protocol and dat= a format for retrieving configuration and policy information for driving d= ata collection and analysis Jan. 2014 - Initial submission of an Internet-Draft for a protocol and dat= a format for collecting actual endpoint posture=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for = consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements f= or consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Architect= ure for consideration as Informational RFC=20 Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol an= d data format for retrieving configuration and policy information for driv= ing data collection and analysis for consideration as standards-track RFC=20= Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and da= ta format for collecting actual endpoint posture for consideration as stan= dards-track RFC > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, June 07, 2013 12:10 PM > To: Sean Turner > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > Apparently, I didn't include all the information or grabbed the wrong > example charter. Apologies - specifically to Dave for omitting his > contributions! >=20 > Either he or I will provide a corrected update. >=20 > Adam >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Friday, June 07, 2013 11:26 AM > > To: Sean Turner > > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > > sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > Ok, I went ahead and updated the draft charter language - see below. > > > > Hopefully this is right. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Securing information and the systems that store, process, and transmit= > > that information is a challenging task for organizations of all sizes,= > > and many security practitioners spend much of their time on manual > processes. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. > > Automating these routine tasks would free security practitioners to > > focus on high priority tasks, and should improve operators' ability to= > > prioritize risk based on timely information about threats and > > vulnerabilities. This working group will define security automation > > protocols and data format standards in support of information security= > > processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks related= > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > > cases pertaining to the asses=20 sment of endpoint posture (using the > definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse > > existing protocols, mechanisms, information and data models. Of > > particular interest to this working group are existing industry > > standards, preferably IETF standards, that could support automation of= > > asset, change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area of focus provides for necessary language and data format > specifications. > > > > 2. A set of standards for interacting with repositories of content > > related to assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following > > general steps, which accommodate policy-driven and asset-driven > assessment: > > > > 1. Identify endpoints > > > > 2. Determine specific endpoint elements to assess > > > > 3. Collect actual value of elements > > > > 4. Compare actual element values to expected element values > > > > 5. Report results > > > > This approach to endpoint posture collection enables multiple policies= > > to be evaluated based on a single data collection activity. Policies > > will be evaluated by comparing available endpoint posture data > > according to rules expressed in the policy. Typically, these rules > > will compare the actual value against an expected value or range for > > specific posture elements. In some cases, the posture element may > > pertain to software installation state, in which case the actual and > > expected values may be "installed" or "not installed." Evaluation of m= ultiple > posture elements may be combined using Boolean logic. > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. a NEA-specific use vs. a= > > generally applicable assessment used during continuous monitoring). > > In addition, content repositories are expected to store up-to-date > > dictionary of specific enumerations, such as those used for > > configuration element identifiers, asset classifications, vulnerabilit= y > identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format for= > > retrieving configuration and policy information for driving data > > collection and analysis > > - A standards-track document specifying a protocol and data format for= > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > > other SDOs which can be used as-is or as a starting point for > > developing solutions to the SACM requirements. The working group may > > decide to make of this document an Informational RFC, but this is not = a > mandatory deliverable. > > > > The working group will work in close coordination with other WGs in > > the IETF (including, but not limited to MILE and NEA) in order to > > create solutions that do not overlap (for example for the repository > > access protocol) and can be used or re-used to meet the goals of more > than one working group. > > > > In accordance with existing IETF processes, the group will communicate= > > with and invite participation from other relevant standards bodies and= > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison relationship= s. > > > > SACM-related efforts are largely aligned, and may overlap, with other > > IETF (and non-IETF) standardization efforts. =20There are common "prob= lems" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > > interest to SACM is understanding and respecting the distinctions > > between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data-collection instructions. > > > > The MILE data formats provide a format to describe incident, > > threat-related incident, and indicator information. SACM data formats= > > provide ways to understand what endpoints are in your environment, > > whether they meet policy requirements, and their current configuration= > > state. The data exchanged in MILE, supplementing the SACM data, > > creates enhanced situational awareness, thus enabling increased > > understanding of current threats and mitigations.=20 The combined SACM= > > and MILE data sets become a powerful tool to automate security with > > descriptions of endpoints, known vulnerabilities to those endpoints, > > and thier configurations along with an understanding of layered > > defenses. Then, injecting known threat information with mitigation > > options assists the organization in turning detailed security > > decisions into business-relevant decisions. The MILE protocols, RID > > and ROLIE, enable the exchange of structured data and are designed to > > carry any structured format. While RID may be used in multiple > > sharing models and provides multiple communication flows (report, > > query, > > etc.) with the ability to enable peer-to-peer object level security, > > ROLIE provides a RESTful repository transport option with only the > > need for a browser on the client end, removing deployment barriers. > > > > > > After the work items in the current charter have been submitted to and= > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > taking into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > related standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= > > data format for retrieving configuration and policy information for > > driving data collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= > > data format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > Requirements for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > protocol and data format for retrieving configuration and policy > > information for driving data collection and analysis for consideration= > > as standards-track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > and data format for collecting actual endpoint posture for > > consideration as standards- track RFC > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > > Of Adam Montville > > > Sent: Friday, June 07, 2013 10:24 AM > > > To: Sean Turner > > > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > > > sacm@ietf.org > > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > Dan, I assume you're going to make those updates? > > > > > > > -----Original Message----- > > > > From: Sean Turner [mailto:turners@ieca.com] > > > > Sent: Friday, June 07, 2013 9:21 AM > > > > To: Adam Montville > > > > Cc: Waltermire, David A.; Gunnar Engelbach; Adam W. Montville; > > > > sacm@ietf.org > > > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > > > Okay so this looks like it's going to work. Let's make the > > > > changes in the draft charter. > > > > > > > > spt > > > > > > > > On 6/7/13 12:00 PM, Adam Montville wrote: > > > > > [snip] > > > > >>> To be more generic, we can take the list and turn it into > > > > >>> something like this > > > > >> (I think Sean had not wanted this list to be modified, but...):= > > > > >>> > > > > >>> 1. Identify endpoints > > > > >>> 2. Determine specific endpoint elements to assess 3. Collect > > > > >>> actual value of elements 4. Compare actual element values to > > > > >>> expected element values 5. Report results > > > > > [snip] > > > > >> The charter need not to go in to gory detail and we can only > > > > >> guess what other people who haven't been involved will say when= > > > > >> the charter goes out for external review. I'm good with the > > > > >> existing bullet list or this shortened one as long as you can > > > > >> capture that this can supports policy-driven and/or asset- > > > > >> driven > > models. > > > > >> > > > > >> spt > > > > > > > > > > If we're going to "capture" that this supports > > > > > policy-/asset-driven models, > > > > then the abbreviated list is better with some explanatory text > > > > that simply makes that claim. What if we simply preface the list > > > > with something > > > like this: > > > > > > > > > > "The following general steps accommodate both policy-driven and > > > > > asset- > > > > driven assessment." > > > > > > > > > > Adam > > > > > > > > > > This message and attachments may contain confidential informatio= n. > > > > > 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. > > > > > > > > > > > > > ... > > > > > > 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. > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > ... > > > > 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. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > ... >=20 > This message and attachments may contain confidential information. If i= t > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments i= s > strictly prohibited. Please notify the sender immediately and permanent= ly > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... 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 jfield@gopivotal.com Fri Jun 7 12:32:23 2013 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 5941521F8EFE for ; Fri, 7 Jun 2013 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsIxsEX5VLeo for ; Fri, 7 Jun 2013 12:32:21 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 01DD621F8EF7 for ; Fri, 7 Jun 2013 12:32:20 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id o13so3620227oag.25 for ; Fri, 07 Jun 2013 12:32:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1EDZr2X1qM6Dz5tnaRnOgRnpeT+YOA5h9Srto2iV8fA=; b=WWxiFcywnjsYNgPWUEMV0AzizZJoB3jZZyiYV33owh5TUMJykSrm8h4cCLOm8mZg/F RrETzsi9Sh+gQyzuzwKaqjILqMoy4Zee/3b7TthxBQg8uTZWZXwvpBKL0oeliQm9lU74 qB6annq2ymX2YBJTQgzYpIDLfpqShigNfiOGliv8o1hG9HasoFMJj687kOol1TqNADVB bJct2tQGnaFPrzPoFxsY0hdZvg3SqpWpUjPidHlZcs+RpC8xgAvKqg/6j+1KhxKqlPwJ HmoRUZwPZN2Au+Km9AaV4lkHyGfiZqz9J4filhFjE1Wwer7lT9KJgLTqTi/o/Vm+WSFF iodQ== MIME-Version: 1.0 X-Received: by 10.60.79.231 with SMTP id m7mr72396oex.105.1370633540071; Fri, 07 Jun 2013 12:32:20 -0700 (PDT) Received: by 10.76.152.195 with HTTP; Fri, 7 Jun 2013 12:32:19 -0700 (PDT) In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> Date: Fri, 7 Jun 2013 15:32:19 -0400 Message-ID: From: John Field To: Adam Montville Content-Type: multipart/related; boundary=089e01184b0e460b0104de957de0 X-Gm-Message-State: ALoCoQmzxUtsEptuUHUuJqUFmSCxCIv3IvGnotNXQKw3eubBSr3KyE+s+D3GKcW+H+YRDr7E6474 Cc: Gunnar Engelbach , Sean Turner , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 19:32:23 -0000 --089e01184b0e460b0104de957de0 Content-Type: multipart/alternative; boundary=089e01184b0e460aff04de957ddf --089e01184b0e460aff04de957ddf Content-Type: text/plain; charset=ISO-8859-1 Three comments: 1) A definite "thumbs Up" or "+1" on the decision to shorten the summary of the endpoint posture assessment process to be the more succinct, conceptual list. At the level of the charter, this generalization is an improvement. 2) Similarly, with respect to David's comments, re: ROLIE. I agree that one should not pre-fetch the answer and identify a specific mechanism in the SACM charter. As noted, it's better to reference the collaboration with MILE, and work to identify where we can avoid unnecessary duplication. ROLIE does currently specify IODEF as MTI, which would not necessarily be appropriate for SACM repository. Of course, OTOH, that was just a stake in the ground for ROLIE, and this could represent an example of a place where generalizing ROLIE could enable it's reuse by SACM. I'm certainly open to that... 3) And, finally, one nit-pick...quoting from the last sentence of the paragraph immediately following the process outline: " Evaluation of multiple posture elements may be combined using Boolean logic." Suggest changing "Boolean logic" to "predicate logic" Thanks, John On Fri, Jun 7, 2013 at 3:10 PM, Adam Montville < Adam.Montville@cisecurity.org> wrote: > Apparently, I didn't include all the information or grabbed the wrong > example charter. Apologies - specifically to Dave for omitting his > contributions! > > Either he or I will provide a corrected update. > > Adam > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > > Adam Montville > > Sent: Friday, June 07, 2013 11:26 AM > > To: Sean Turner > > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > > sacm@ietf.org > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > Ok, I went ahead and updated the draft charter language - see below. > > > > Hopefully this is right. > > > > ============================================== > > > > Securing information and the systems that store, process, and transmit > that > > information is a challenging task for organizations of all sizes, and > many > > security practitioners spend much of their time on manual processes. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. Automating > > these routine tasks would free security practitioners to focus on high > priority > > tasks, and should improve operators' ability to prioritize risk based on > timely > > information about threats and vulnerabilities. This working group will > define > > security automation protocols and data format standards in support of > > information security processes and practices. These standards will help > > security practitioners to be more effective by automating routine tasks > > related to client and server security, freeing them to focus on more > > advanced tasks. The initial focus of this work is to address enterprise > use > > cases pertaining to the asses sment of endpoint posture (using the > > definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse existing > > protocols, mechanisms, information and data models. Of particular > interest > > to this working group are existing industry standards, preferably IETF > > standards, that could support automation of asset, change, configuration, > > and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > area of > > focus provides for necessary language and data format specifications. > > > > 2. A set of standards for interacting with repositories of content > related to > > assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following general > > steps, which accommodate policy-driven and asset-driven assessment: > > > > 1. Identify endpoints > > > > 2. Determine specific endpoint elements to assess > > > > 3. Collect actual value of elements > > > > 4. Compare actual element values to expected element values > > > > 5. Report results > > > > This approach to endpoint posture collection enables multiple policies > to be > > evaluated based on a single data collection activity. Policies will be > evaluated > > by comparing available endpoint posture data according to rules > expressed in > > the policy. Typically, these rules will compare the actual value against > an > > expected value or range for specific posture elements. In some cases, the > > posture element may pertain to software installation state, in which > case the > > actual and expected values may be "installed" or "not installed." > Evaluation > > of multiple posture elements may be combined using Boolean logic. > > > > Repository protocols are needed to store, update, and retrieve > configuration > > checks and other types of content required for posture assessment (see > > step 2 above). A content repository is expected to house specific > versions of > > checklists (i.e. benchmarks), may be required to satisfy different use > cases > > (i.e. a NEA-specific use vs. a generally applicable assessment used > during > > continuous monitoring). In addition, content repositories are expected > to > > store up-to-date dictionary of specific enumerations, such as those used > for > > configuration element identifiers, asset classifications, vulnerability > > identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format for > > retrieving configuration and policy information for driving data > collection and > > analysis > > - A standards-track document specifying a protocol and data format for > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in other > SDOs > > which can be used as-is or as a starting point for developing solutions > to the > > SACM requirements. The working group may decide to make of this > > document an Informational RFC, but this is not a mandatory deliverable. > > > > The working group will work in close coordination with other WGs in the > IETF > > (including, but not limited to MILE and NEA) in order to create > solutions that > > do not overlap (for example for the repository access protocol) and can > be > > used or re-used to meet the goals of more than one working group. > > > > In accordance with existing IETF processes, the group will communicate > with > > and invite participation from other relevant standards bodies and > regulatory > > organizations, and if necessary reuse existing liaison relationships or > request > > the establishment of new liaison relationships. > > > > SACM-related efforts are largely aligned, and may overlap, with other > IETF > > (and non-IETF) standardization efforts. There are common "problems" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest > > to SACM is understanding and respecting the distinctions between itself > and > > NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > collected > > on the endpoint to an external service or data repository for further > analysis > > and action. NEA may also serve the purpose of carrying data-collection > > instructions. > > > > The MILE data formats provide a format to describe incident, > threat-related > > incident, and indicator information. SACM data formats provide ways to > > understand what endpoints are in your environment, whether they meet > > policy requirements, and their current configuration state. The data > > exchanged in MILE, supplementing the SACM data, creates enhanced > > situational awareness, thus enabling increased understanding of current > > threats and mitigations. The combined SACM and MILE data sets become a > > powerful tool to automate security with descriptions of endpoints, known > > vulnerabilities to those endpoints, and thier configurations along with > an > > understanding of layered defenses. Then, injecting known threat > > information with mitigation options assists the organization in turning > > detailed security decisions into business-relevant decisions. The MILE > > protocols, RID and ROLIE, enable the exchange of structured data and are > > designed to carry any structured format. While RID may be used in > multiple > > sharing models and provides multiple communication flows (report, query, > > etc.) with the ability to enable peer-to-peer object level security, > ROLIE > > provides a RESTful repository transport option with only the need for a > > browser on the client end, removing deployment barriers. > > > > > > After the work items in the current charter have been submitted to and > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking > > into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related > > standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data > > format for retrieving configuration and policy information for driving > data > > collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data > > format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for > > consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements > for > > consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol > and > > data format for retrieving configuration and policy information for > driving > > data collection and analysis for consideration as standards-track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and > data > > format for collecting actual endpoint posture for consideration as > standards- > > track RFC > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > > Of Adam Montville > > > Sent: Friday, June 07, 2013 10:24 AM > > > To: Sean Turner > > > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > > > sacm@ietf.org > > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > Dan, I assume you're going to make those updates? > > > > > > > -----Original Message----- > > > > From: Sean Turner [mailto:turners@ieca.com] > > > > Sent: Friday, June 07, 2013 9:21 AM > > > > To: Adam Montville > > > > Cc: Waltermire, David A.; Gunnar Engelbach; Adam W. Montville; > > > > sacm@ietf.org > > > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > > > > > Okay so this looks like it's going to work. Let's make the changes > > > > in the draft charter. > > > > > > > > spt > > > > > > > > On 6/7/13 12:00 PM, Adam Montville wrote: > > > > > [snip] > > > > >>> To be more generic, we can take the list and turn it into > > > > >>> something like this > > > > >> (I think Sean had not wanted this list to be modified, but...): > > > > >>> > > > > >>> 1. Identify endpoints > > > > >>> 2. Determine specific endpoint elements to assess 3. Collect > > > > >>> actual value of elements 4. Compare actual element values to > > > > >>> expected element values 5. Report results > > > > > [snip] > > > > >> The charter need not to go in to gory detail and we can only > > > > >> guess what other people who haven't been involved will say when > > > > >> the charter goes out for external review. I'm good with the > > > > >> existing bullet list or this shortened one as long as you can > > > > >> capture that this can supports policy-driven and/or asset- driven > > models. > > > > >> > > > > >> spt > > > > > > > > > > If we're going to "capture" that this supports > > > > > policy-/asset-driven models, > > > > then the abbreviated list is better with some explanatory text that > > > > simply makes that claim. What if we simply preface the list with > > > > something > > > like this: > > > > > > > > > > "The following general steps accommodate both policy-driven and > > > > > asset- > > > > driven assessment." > > > > > > > > > > Adam > > > > > > > > > > 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. > > > > > > > > > > > > > ... > > > > > > 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. > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > ... > > > > 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. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > ... > > 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. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > -- John P. Field | Security Architect | Pivotal Direct: (908) 962-3394 | jfield@gopivotal.com *[image: cid:332B1A9B-BFB1-42CC-8C13-5949BB4B8266]* *goPivotal.com * --089e01184b0e460aff04de957ddf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Three comments:

1) A definite &qu= ot;thumbs Up" or "+1" on the decision to shorten the summary= of the endpoint posture assessment process to be the more succinct, concep= tual list. =A0At the level of the charter, this generalization is an improv= ement.

2) Similarly, with respect to David's c= omments, re: ROLIE. =A0I agree that one should not pre-fetch the answer and= identify a specific mechanism in the SACM charter. =A0As noted, it's b= etter to reference the collaboration with MILE, and work to identify where = we can avoid unnecessary duplication. =A0ROLIE does currently specify IODEF= as MTI, which would not necessarily be appropriate for SACM repository. = =A0Of course, OTOH, that was just a stake in the ground for ROLIE, and this= could represent an example of a place where generalizing ROLIE could enabl= e it's reuse by SACM. =A0I'm certainly open to that...

3) And, finally, one nit-pick...quoting fro= m the last sentence of =A0the paragraph immediately following the process o= utline:

"=A0Evalua= tion of multiple posture elements may be combined using Boolean logic."= ;

Suggest changing "= Boolean logic" to "predicate logic"

Thanks,
John
=A0

=A0=A0 =A0=A0


On Fri, Jun 7, 2013 at 3:10 PM, Adam Montville <Ad= am.Montville@cisecurity.org> wrote:
Apparently, I didn't include all the inf= ormation or grabbed the wrong example charter. =A0Apologies - specifically = to Dave for omitting his contributions!

Either he or I will provide a corrected update.

Adam

> -----Original Message-----
> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of
> Adam Montville
> Sent: Friday, June 07, 2013 11:26 AM > To: Sean Turner
> Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.;
> sacm@ietf.org
> Subject: Re: [sacm] Updated Candidate Charter Text
>
> Ok, I went ahead and upd= ated the draft charter language - see below.
>
> Hopefully this is right.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Securing information and the systems that store, process, and transmit= that
> information is a challenging task for organizations of all sizes, and = many
> security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system<= br> > configurations would allow easier automation of the processes. Automat= ing
> these routine tasks would free security practitioners to focus on high= priority
> tasks, and should improve operators' ability to prioritize risk ba= sed on timely
> information about threats and vulnerabilities. This working group will= define
> security automation protocols and data format standards in support of<= br> > information security processes and practices. These standards will hel= p
> security practitioners to be more effective by automating routine task= s
> related to client and server security, freeing them to focus on more > advanced tasks. The initial focus of this work is to address enterpris= e use
> cases pertaining to the asses =A0sment of endpoint posture (using the<= br> > definitions of Endpoint and Posture from RFC 5209).
>
> The working group will, whenever reasonable and possible, reuse existi= ng
> protocols, mechanisms, information and data models. Of particular inte= rest
> to this working group are existing industry standards, preferably IETF=
> standards, that could support automation of asset, change, configurati= on,
> and vulnerability management.
>
> The working group will define:
>
> 1. A set of standards to enable assessment of endpoint posture. This a= rea of
> focus provides for necessary language and data format specifications.<= br> >
> 2. A set of standards for interacting with repositories of content rel= ated to
> assessment of endpoint posture.
>
> Assessment of endpoint posture assessment entails the following genera= l
> steps, which accommodate policy-driven and asset-driven assessment: >
> 1. Identify endpoints
>
> 2. Determine specific endpoint elements to assess
>
> 3. Collect actual value of elements
>
> 4. Compare actual element values to expected element values
>
> 5. Report results
>
> This approach to endpoint posture collection enables multiple policies= to be
> evaluated based on a single data collection activity. Policies will be= evaluated
> by comparing available endpoint posture data according to rules expres= sed in
> the policy. Typically, these rules will compare the actual value again= st an
> expected value or range for specific posture elements. In some cases, = the
> posture element may pertain to software installation state, in which c= ase the
> actual and expected values may be "installed" or "not i= nstalled." Evaluation
> of multiple posture elements may be combined using Boolean logic.
>
> Repository protocols are needed to store, update, and retrieve configu= ration
> checks and other types of content required for posture assessment (see=
> step 2 above). =A0A content repository is expected to house specific v= ersions of
> checklists (i.e. benchmarks), may be required to satisfy different use= cases
> (i.e. a NEA-specific use vs. a generally applicable assessment used du= ring
> continuous monitoring). =A0In addition, content repositories are expec= ted to
> store up-to-date dictionary of specific enumerations, such as those us= ed for
> configuration element identifiers, asset classifications, vulnerabilit= y
> identifiers, and so on.
>
> This working group will achieve the following deliverables:
>
> - An Informational document on Use Cases
> - An Informational document on Requirements
> - An Informational document on SACM Architecture
> - A standards-track document specifying a protocol and data format for=
> retrieving configuration and policy information for driving data colle= ction and
> analysis
> - A standards-track document specifying a protocol and data format for=
> collecting actual endpoint posture
>
> The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in oth= er SDOs
> which can be used as-is or as a starting point for developing solution= s to the
> SACM requirements. The working group may decide to make of this
> document an Informational RFC, but this is not a mandatory deliverable= .
>
> The working group will work in close coordination with other WGs in th= e IETF
> (including, but not limited to MILE and NEA) in order to create soluti= ons that
> do not overlap (for example for the repository access protocol) and ca= n be
> used or re-used to meet the goals of more than one working group.
>
> In accordance with existing IETF processes, the group will communicate= with
> and invite participation from other relevant standards bodies and regu= latory
> organizations, and if necessary reuse existing liaison relationships o= r request
> the establishment of new liaison relationships.
>
> SACM-related efforts are largely aligned, and may overlap, with other = IETF
> (and non-IETF) standardization efforts. =A0There are common "prob= lems"
> found in SACM, that may be addressed by the work done in SNMP, IPFIX,<= br> > NETCONF, SYSLOG, NEA, MILE, and potentially others. =A0Of particular i= nterest
> to SACM is understanding and respecting the distinctions between itsel= f and
> NEA and MILE.
>
> One way the NEA protocols can be used is as the transport for data col= lected
> on the endpoint to an external service or data repository for further = analysis
> and action. =A0NEA may also serve the purpose of carrying data-collect= ion
> instructions.
>
> The MILE data formats provide a format to describe incident, threat-re= lated
> incident, and indicator information. =A0SACM data formats provide ways= to
> understand what endpoints are in your environment, whether they meet > policy requirements, and their current configuration state. =A0The dat= a
> exchanged in MILE, supplementing the SACM data, creates enhanced
> situational awareness, thus enabling increased understanding of curren= t
> threats and mitigations. =A0The combined SACM and MILE data sets becom= e a
> powerful tool to automate security with descriptions of endpoints, kno= wn
> vulnerabilities to those endpoints, and thier configurations along wit= h an
> understanding of layered defenses. =A0Then, injecting known threat
> information with mitigation options assists the organization in turnin= g
> detailed security decisions into business-relevant decisions. =A0The M= ILE
> protocols, RID and ROLIE, enable the exchange of structured data and a= re
> designed to carry any structured format. =A0While RID may be used =A0i= n multiple
> sharing models and provides multiple communication flows (report, quer= y,
> etc.) with the ability to enable peer-to-peer object level security, R= OLIE
> provides a RESTful repository transport option with only the need for = a
> browser on the client end, removing deployment barriers.
>
>
> After the work items in the current charter have been submitted to and=
> approved by the IESG, the WG will recharter or close.
>
> Goals and Milestones
>
> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases
>
> Oct. 2013 - Initial submission of an Internet-Draft on Requirements ta= king
> into consideration RFC5706 and RFC3535
>
> Oct. 2013 - Initial submission of an Internet-Draft on SACM Architectu= re
>
> Nov. 2013 - Initial submission of an Internet-Draft on overview of rel= ated
> standards work
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= data
> format for retrieving configuration and policy information for driving= data
> collection and analysis
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= data
> format for collecting actual endpoint posture
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases = for
> consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on Requiremen= ts for
> consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM
> Architecture for consideration as Informational RFC
>
> Oct. 2014 - Submission to the IESG of the Internet-Draft for a protoco= l and
> data format for retrieving configuration and policy information for dr= iving
> data collection and analysis for consideration as standards-track RFC<= br> >
> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol an= d data
> format for collecting actual endpoint posture for consideration as sta= ndards-
> track RFC
>
> > -----Original Message-----
> > From: sacm-bounces@ietf.= org [mailto:sacm-bounces@ietf.= org] On Behalf
> > Of Adam Montville
> > Sent: Friday, June 07, 2013 10:24 AM
> > To: Sean Turner
> > Cc: Gunnar Engelbach; Adam W. Montville; Waltermire, David A.; > > sacm@ietf.org
> > Subject: Re: [sacm] Updated Candidate Charter Text
> >
> > Dan, I assume you're going to make those updates?
> >
> > > -----Original Message-----
> > > From: Sean Turner [mailto:turners@ieca.com]
> > > Sent: Friday, June 07, 2013 9:21 AM
> > > To: Adam Montville
> > > Cc: Waltermire, David A.; Gunnar Engelbach; Adam W. Montvill= e;
> > > sacm@ietf.org
> > > Subject: Re: [sacm] Updated Candidate Charter Text
> > >
> > > Okay so this looks like it's going to work. =A0Let's= make the changes
> > > in the draft charter.
> > >
> > > spt
> > >
> > > On 6/7/13 12:00 PM, Adam Montville wrote:
> > > > [snip]
> > > >>> To be more generic, we can take the list and tu= rn it into
> > > >>> something like this
> > > >> (I think Sean had not wanted this list to be modifi= ed, but...):
> > > >>>
> > > >>> 1. Identify endpoints
> > > >>> 2. Determine specific endpoint elements to asse= ss 3. Collect
> > > >>> actual value of elements 4. Compare actual elem= ent values to
> > > >>> expected element values 5. Report results
> > > > [snip]
> > > >> The charter need not to go in to gory detail and we= can only
> > > >> guess what other people who haven't been involv= ed will say when
> > > >> the charter goes out for external review. =A0I'= m good with the
> > > >> existing bullet list or this shortened one as long = as you can
> > > >> capture that this can supports policy-driven and/or= asset- driven
> models.
> > > >>
> > > >> spt
> > > >
> > > > If we're going to "capture" that this sup= ports
> > > > policy-/asset-driven models,
> > > then the abbreviated list is better with some explanatory te= xt that
> > > simply makes that claim. =A0What if we simply preface the li= st with
> > > something
> > like this:
> > > >
> > > > "The following general steps accommodate both poli= cy-driven and
> > > > asset-
> > > driven assessment."
> > > >
> > > > Adam
> > > >
> > > > This message and attachments may contain confidential i= nformation.
> > > > If it
> > > appears that this message was sent to you by mistake, any re= tention,
> > > dissemination, distribution or copying of this message and > > > attachments is strictly prohibited. =A0Please notify the sen= der
> > > immediately and permanently delete the message and any attac= hments.
> > > >
> > >
> > > ...
> >
> > This message and attachments may contain confidential information= . =A0If
> > 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. =A0Please notify the sender > > immediately and permanently delete the message and any attachment= s.
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org
> > https://www.ietf.org/mailman/listinfo/sacm
> >
> > ...
>
> This message and attachments may contain confidential information. =A0= 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. =A0Please notify the sender immediately and perma= nently
> delete the message and any attachments.
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>
> ...

This message and attachments may contain confidential information. =A0If it= appears that this message was sent to you by mistake, any retention, disse= mination, distribution or copying of this message and attachments is strict= ly prohibited. =A0Please notify the sender immediately and permanently dele= te the message and any attachments.
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm



--
=

John P. Field |=A0Security Architect |=A0Pivotal

Direct: (908) 962-3394 | jfield@gopivotal.com=A0 <= /span>

3D"cid=

goPivotal.com
--089e01184b0e460aff04de957ddf-- --089e01184b0e460b0104de957de0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 5b082271dab5eed9_0.1 iVBORw0KGgoAAAANSUhEUgAAAFIAAAAaCAYAAAAkJwuaAAAEJGlDQ1BJQ0MgUHJvZmlsZQAAOBGF Vd9v21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8 AUDZAw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWa GVWIlquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJP wG4VHX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzY Zi+3YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0 HPBLsF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgj ONd1ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyo Bc3SOjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrY BbueF9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiE hcPLYTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrB DgUKcm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfS Pqdraz/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1c AdMlDetv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0n fS/9TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8e k6fkvfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWW ing6noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8O okmrdtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/ wjvrVmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83 Gv+uNxo7XyL/FtFl8z9ZAHF4bBsrEwAABs9JREFUaAXtWX1oFEcUf2/3voQW24ggBAQhIAj5SylY hELEIggVQa4QPcFWkygUi1CwtFSEglIptFSaxI8SEiNNEKTSP6SCIA0UpKIQGioECoIghF4UCt4l t/v6m5n9vL29XBobi83A7cy8ee/NzG/nfcweiwitlKUjkFEq+FCpg9hdnVBn8ZwMXp5M0CMEPlRs I85u0CRrfkYGxx9Ghl/KJh/et1lvjMmR86P3VVsDiedXxPauRrvmIweIRJ5ibIjmqV8ujTyI8dm5 nWRZo4Zm9aM+Ght/GTsZ+1e9LYPLa6pttbRP5tXEfIxy/DuAPd2SzAtk4t7ieu7r3sp9+zct1zLM iYzOJnIJxn5Hk9hdS8Lr0d9FTO0e2wnuOzAtA8PgQ7FkGif2vG6LTOj6BT74SOlbsgpH9BJcUdYx tRzLaQTkLRkcuRKdnIvFHLUVhgHmu5rOcgK1BlL6RxXoBvio0P+snQSyAQAyPj7H7xU/oFx+L0zc xgntUOajAosOVBnu0mJSm5LBKxN8sLiO8oV3AlUO3ZQLw38E/boGHz6wgWzaocmOc1cujN6tYyGt s5BdTw7N+Q6+nifRt3gbrMeJ0WuVq3JxvBylYS9wXZlNCBmdOCwbSMis1a09ILc2Wc8flfXbLQGp mOW78RksSgWdNi1sZdehfki2vAFwBzWNbRVsJiiXQRZAhqYGMnQGz49Vs2HJUA/o6pSj2NtNjddV LNr0ev44WfwRFQprzTDoKgCS3CJXPlwgq+jGOrp9fUY+9wvqAEju3Q+ewjfgM/tSTKw5sRTAgx/2 /Yik8mazjKS1YKN0K/MmCVOkGs5GWhH+C0N34TvnNItIw4wgFJe9XnuGnlZuq7Y+gW35ewDxC3QN iB6TqWAFzPe4r3Q8Rl5Ex/hTZBwBiPIM4rAGiWcmOj7kwr03mKPlE0lrCurNwqxRFEDW/LRuN3h4 prcFJ0elRXjj3KkiqAxcTjh+nIhOpE8dRo1chRsxL6hQ+B60Tk/9bZjYpzRbu0+v5tspI3ug8xR+ eLn0JcCckoGRGx5vWCHYwN8rK0kUuJMuyrAJSiqNYTko/ZevRRlxEn8GyNuitLR2UyC173CzHdho FxKlz4IzzzwmA+PKzJsXR8bIZmNaQspnJoCE3ogvdcaUQgCzAyC9pZULXEW5sj0AmEidljPcU5rC a/1B8zB/jjoJpB5MedgCED0bFgA+EAcxRSqVnGra2MyPSCOekEo+tXnxK1qLyCT9WTmaqjE68KR6 00vmsWarsXkLm0yA6DE9qU144jsDNQ6djIAYkOX8yHV0/KC0WbuCYLSFBrM5aUKP4GdjWUoL0gmW VCATnCTwe9JP1erb2JjygQsW8D3DyVIbRpGtiPwxX6ciP8aN+boRsyZC7uoVp5J+RRU3HMtk/TzX l0ytdRAjUsESL7jOH6ZKNR9IN22GqYiahJECyGNyqxOtpAGJ6VyYt8UlAGZTFukTUcRn5f3TCLIx a09+VaAnSyZgBYRIg/lZ0LMklAmIKY3XyViXGhYKdaSwt0JOBVL6R861omBBntnqDSTzZR0ZmZR5 h0AyG/8oSKNmayotWZ4yC/DWBFOpgLXksgjT/mdzGf8mJhoydcGs9MkxPk22Gq1yLeYHmcNAZkVO T2IJ+AbgF5Ny+b2mNeaaC313xI00lWo++K8D6U0/ZmpeRW05E3RyeZXCeOmUczW2TKEwtXKyXbEx r2P8HC4Dqog4xPOpNydPpL7yrrW8kXu7W0px6hVE+8sDZLl6C5PO6InZ2mNqL+2BWatrZXRRNC9X NDiKaNmn64OU5m3LfQL/3eHJXcetw5xioTAQMqX7TZEhT1bNcVFfdQPC4hupPnLxqtIllNniFoFT hwQYtxzu2Vci2zJ5Ikn8NEKN+uaJ9GsIzffhW9txb/+Ne0tn0b5PrrsOsrjzW17+iduIyMlwdgRH vzCdgp6NflfXNTorF0emaXZuDJeMHtCwDt5IWbmHNd5B8FFfs84tcPWMqVSd5TmRaiYsDj+YIPya bQ9j8avQh6+qfq2GE6VcPYpx/YUJY2t1Lsv8kyfrByncgWl3bNPlCtwIPu3pgtyXuSf2sx2d9mif 7FZ2g9dLz1SerK+dAFd9Olxc8U+kmtgkt8zlRakw/EbWlYdpsup6iJN4ELckfCDQQQKmrq5wjf+a 0AGB6BD81xC+3p+A3k2Qw5cZgM88SS7Ss9nKGfCFpgwm1Ud+uoU4dwyAtIPX/C3gLywSlDx3sFv7 SLbhbwVffyzktY4X7HT6Z9yDE0m1QqyCuXnlzy8f4aXVy2faS1vnf156Bcjn9IpWgFwB8jkh8JzU /A3WyVI+PC3NMwAAAABJRU5ErkJggg== --089e01184b0e460b0104de957de0-- From Adam.Montville@cisecurity.org Fri Jun 7 15:35:57 2013 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 2379521F99A9 for ; Fri, 7 Jun 2013 15:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KioXHCUyldEZ for ; Fri, 7 Jun 2013 15:35:51 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) by ietfa.amsl.com (Postfix) with ESMTP id 76EA221F99A6 for ; Fri, 7 Jun 2013 15:35:41 -0700 (PDT) Received: from [216.82.250.19:55522] by server-15.bemta-12.messagelabs.com id 41/4E-30971-C3062B15; Fri, 07 Jun 2013 22:35:40 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-11.tower-87.messagelabs.com!1370644538!18455968!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 10791 invoked from network); 7 Jun 2013 22:35:39 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-11.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 7 Jun 2013 22:35:39 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 18:35:32 -0400 From: Adam Montville To: John Field Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAASVeA///unPA= Date: Fri, 7 Jun 2013 22:35:32 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , Sean Turner , "Adam W. Montville" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 22:35:57 -0000 Thanks John. I've modified the "ROLIE paragraph" by truncating the last f= ew sentences. Also, changed Boolean to predicate. Are there any further nits or really bad oversights in this copy of the ch= arter? If you like it as it stands, +1 it. For me, +1 --------------------------------------------- Securing information and the systems that store, process, and transmit tha= t information is a challenging task for organizations of all sizes, and ma= ny security practitioners spend much of their time on manual processes. St= andardized processes to collect, verify, and update security system config= urations would allow easier automation of the processes. Automating these = routine tasks would free security practitioners to focus on high priority = tasks, and should improve operators' ability to prioritize risk based on t= imely information about threats and vulnerabilities. This working group wi= ll define security automation protocols and data format standards in suppo= rt of information security processes and practices. These standards will h= elp security practitioners to be more effective by automating routine task= s related to client and server security, freeing them to focus on more adv= anced tasks. The initial focus of this work is to address enterprise use c= ases pertaining to the assessment of endpoint posture (using the definitio= ns of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing p= rotocols, mechanisms, information and data models. Of particular interest = to this working group are existing industry standards, preferably IETF sta= ndards, that could support automation of asset, change, configuration, and= vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area = of focus provides for necessary language and data format specifications. 2. A set of standards for interacting with repositories of content related= to assessment of endpoint posture. Assessment of endpoint posture assessment entails the following general st= eps, which accommodate policy-driven and asset-driven assessment: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to = be evaluated based on a single data collection activity. Policies will be = evaluated by comparing available endpoint posture data according to rules = expressed in the policy. Typically, these rules will compare the actual va= lue against an expected value or range for specific posture elements. In s= ome cases, the posture element may pertain to software installation state,= in which case the actual and expected values may be "installed" or "not i= nstalled." Evaluation of multiple posture elements may be combined using p= redicate logic. Repository protocols are needed to store, update, and retrieve configurati= on checks and other types of content required for posture assessment (see = step 2 above). A content repository is expected to house specific version= s of checklists (i.e. benchmarks), may be required to satisfy different us= e cases (i.e. asset inventory, configuration settings, or vulnerabilities)= . In addition, content repositories are expected to store up-to-date dict= ionary of specific enumerations, such as those used for configuration elem= ent identifiers, asset classifications, vulnerability identifiers, and so = on. This working group will achieve the following deliverables: - An Informational document on Use Cases - An Informational document on Requirements - An Informational document on SACM Architecture - A standards-track document specifying a protocol and data format for ret= rieving configuration and policy information for driving data collection a= nd analysis - A standards-track document specifying a protocol and data format for col= lecting actual endpoint posture=20 The working group will create an overview of related standards work Intern= et-Draft which will document existing work in the IETF or in other SDOs wh= ich can be used as-is or as a starting point for developing solutions to t= he SACM requirements. The working group may decide to make of this documen= t an Informational RFC, but this is not a mandatory deliverable. =20 The working group will work in close coordination with other WGs in the IE= TF (including, but not limited to MILE and NEA) in order to create solutio= ns that do not overlap and can be used or re-used to meet the goals of mor= e than one working group.=20 In accordance with existing IETF processes, the group will communicate wit= h and invite participation from other relevant standards bodies and regula= tory organizations, and if necessary reuse existing liaison relationships = or request the establishment of new liaison relationships. SACM-related efforts are largely aligned, and may overlap, with other IETF= (and non-IETF) standardization efforts. There are common "problems" foun= d in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF,= SYSLOG, NEA, MILE, and potentially others. Of particular interest to SAC= M is understanding and respecting the distinctions between itself and NEA = and MILE. One way the NEA protocols can be used is as the transport for data collect= ed on the endpoint to an external service or data repository for further a= nalysis and action. NEA may also serve the purpose of carrying data-colle= ction instructions. The MILE data formats provide a format to describe incident, threat-relate= d incident, and indicator information. SACM data formats provide ways to = understand what endpoints are in your environment, whether they meet polic= y requirements, and their current configuration state. The data exchanged= in MILE, supplementing the SACM data, creates enhanced situational awaren= ess, thus enabling increased understanding of current threats and mitigati= ons. After the work items in the current charter have been submitted to and app= roved by the IESG, the WG will recharter or close. =20 Goals and Milestones Sep. 2013 - Initial submission of an Internet-Draft on Use Cases=20 Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking= into consideration RFC5706 and RFC3535 Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture=20= Nov. 2013 - Initial submission of an Internet-Draft on overview of related= standards work=20 Jan. 2014 - Initial submission of an Internet-Draft for a protocol and dat= a format for retrieving configuration and policy information for driving d= ata collection and analysis Jan. 2014 - Initial submission of an Internet-Draft for a protocol and dat= a format for collecting actual endpoint posture=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for = consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements f= or consideration as Informational RFC=20 Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM Architect= ure for consideration as Informational RFC=20 Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol an= d data format for retrieving configuration and policy information for driv= ing data collection and analysis for consideration as standards-track RFC=20= Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and da= ta format for collecting actual endpoint posture for consideration as stan= dards-track RFC 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 david.waltermire@nist.gov Mon Jun 10 12:20:31 2013 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 D44C521F9AA2 for ; Mon, 10 Jun 2013 12:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 4L1cQnMVTmBD for ; Mon, 10 Jun 2013 12:20:24 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17721F9A9E for ; Mon, 10 Jun 2013 12:20:20 -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.3.123.3; Mon, 10 Jun 2013 15:20:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 10 Jun 2013 15:20:17 -0400 From: "Waltermire, David A." To: Adam Montville , John Field Date: Mon, 10 Jun 2013 15:20:16 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAASVeA///unPAAkC8MwA== Message-ID: References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> 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: Gunnar Engelbach , Sean Turner , "Adam W. Montville" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:20:32 -0000 +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, David > A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the last few > sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit that > information is a challenging task for organizations of all sizes, and many > security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. Automating > these routine tasks would free security practitioners to focus on high priority > tasks, and should improve operators' ability to prioritize risk based on timely > information about threats and vulnerabilities. This working group will define > security automation protocols and data format standards in support of > information security processes and practices. These standards will help > security practitioners to be more effective by automating routine tasks > related to client and server security, freeing them to focus on more > advanced tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the > definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse existing > protocols, mechanisms, information and data models. Of particular interest > to this working group are existing industry standards, preferably IETF > standards, that could support automation of asset, change, configuration, > and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This area of > focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content related to > assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following general > steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies to be > evaluated based on a single data collection activity. Policies will be evaluated > by comparing available endpoint posture data according to rules expressed in > the policy. Typically, these rules will compare the actual value against an > expected value or range for specific posture elements. In some cases, the > posture element may pertain to software installation state, in which case the > actual and expected values may be "installed" or "not installed." Evaluation > of multiple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve configuration > checks and other types of content required for posture assessment (see > step 2 above). A content repository is expected to house specific versions of > checklists (i.e. benchmarks), may be required to satisfy different use cases > (i.e. asset inventory, configuration settings, or vulnerabilities). In addition, > content repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, > asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data collection and > analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in other SDOs > which can be used as-is or as a starting point for developing solutions to the > SACM requirements. The working group may decide to make of this > document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in the IETF > (including, but not limited to MILE and NEA) in order to create solutions that > do not overlap and can be used or re-used to meet the goals of more than > one working group. > > In accordance with existing IETF processes, the group will communicate with > and invite participation from other relevant standards bodies and regulatory > organizations, and if necessary reuse existing liaison relationships or request > the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other IETF > (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest > to SACM is understanding and respecting the distinctions between itself and > NEA and MILE. > > One way the NEA protocols can be used is as the transport for data collected > on the endpoint to an external service or data repository for further analysis > and action. NEA may also serve the purpose of carrying data-collection > instructions. > > The MILE data formats provide a format to describe incident, threat-related > incident, and indicator information. SACM data formats provide ways to > understand what endpoints are in your environment, whether they meet > policy requirements, and their current configuration state. The data > exchanged in MILE, supplementing the SACM data, creates enhanced > situational awareness, thus enabling increased understanding of current > threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements taking > into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of related > standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data > format for retrieving configuration and policy information for driving data > collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and data > format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for > consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements for > consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol and > data format for retrieving configuration and policy information for driving > data collection and analysis for consideration as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and data > format for collecting actual endpoint posture for consideration as standards- > track RFC > > 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 jfield@gopivotal.com Mon Jun 10 12:34:43 2013 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 20B4C21F99E9 for ; Mon, 10 Jun 2013 12:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yklwm20i-941 for ; Mon, 10 Jun 2013 12:34:41 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98521F99CF for ; Mon, 10 Jun 2013 12:34:41 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so1912687oag.26 for ; Mon, 10 Jun 2013 12:34:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pi6OslePbNz6ad416aStV0mVXmH8nBEmCvvavJhcY7Y=; b=HlUJ02HWL2p25Dp3TEsVOU2QGGVmvRd2Bzon50baYK9jdDO1d4f7v1h5jcdQTm/dh3 XibT9DgKiox/WUE+QVIjpJ3CnkyD4xS0DdPkfl4Bn+MAj9nOvDWnAi5M1yKNrCWoRNGm wDghaBfGYomyhXE8i5eiNoMKeeIahLDHhpFs1HNdVznq2Nplf8CSJg0Wadyem4lxucn6 LcLYSVncn/2CKfaKq59E5MbpUQ9cfGdXLjBiBTtdcVQGDnvRxxD+VFZ3QQj+x4isQCkx BU4HZIGPMZXuuptG4apu3BT8G6REwGe+2UBtNCcnEI5IAXW3OERHBOECxBlIhYr9pGbU aVUA== MIME-Version: 1.0 X-Received: by 10.60.38.230 with SMTP id j6mr7149253oek.110.1370892880789; Mon, 10 Jun 2013 12:34:40 -0700 (PDT) Received: by 10.76.152.195 with HTTP; Mon, 10 Jun 2013 12:34:40 -0700 (PDT) In-Reply-To: References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> Date: Mon, 10 Jun 2013 15:34:40 -0400 Message-ID: From: John Field To: "Waltermire, David A." Content-Type: multipart/related; boundary=089e0149c0ea2f9e9f04ded1dfc0 X-Gm-Message-State: ALoCoQlbQT6rqLcJYVHrcho+uHxD4zf+jzTR/ZFB0h9YAEHtENOvEZw+QeCtQ/8480EPKtRr1rzM Cc: Gunnar Engelbach , "Adam W. Montville" , Sean Turner , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:34:43 -0000 --089e0149c0ea2f9e9f04ded1dfc0 Content-Type: multipart/alternative; boundary=089e0149c0ea2f9e9d04ded1dfbf --089e0149c0ea2f9e9d04ded1dfbf Content-Type: text/plain; charset=ISO-8859-1 +1 On Mon, Jun 10, 2013 at 3:20 PM, Waltermire, David A. < david.waltermire@nist.gov> wrote: > +1 for me. Are we good with handing this off to Sean today? > > Sincerely, > Dave > > > -----Original Message----- > > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > > Sent: Friday, June 07, 2013 6:36 PM > > To: John Field > > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, David > > A.; sacm@ietf.org > > Subject: RE: [sacm] Updated Candidate Charter Text > > > > Thanks John. I've modified the "ROLIE paragraph" by truncating the last > few > > sentences. Also, changed Boolean to predicate. > > > > Are there any further nits or really bad oversights in this copy of the > charter? > > > > If you like it as it stands, +1 it. > > > > For me, +1 > > > > --------------------------------------------- > > > > Securing information and the systems that store, process, and transmit > that > > information is a challenging task for organizations of all sizes, and > many > > security practitioners spend much of their time on manual processes. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. Automating > > these routine tasks would free security practitioners to focus on high > priority > > tasks, and should improve operators' ability to prioritize risk based on > timely > > information about threats and vulnerabilities. This working group will > define > > security automation protocols and data format standards in support of > > information security processes and practices. These standards will help > > security practitioners to be more effective by automating routine tasks > > related to client and server security, freeing them to focus on more > > advanced tasks. The initial focus of this work is to address enterprise > use > > cases pertaining to the assessment of endpoint posture (using the > > definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse existing > > protocols, mechanisms, information and data models. Of particular > interest > > to this working group are existing industry standards, preferably IETF > > standards, that could support automation of asset, change, configuration, > > and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > area of > > focus provides for necessary language and data format specifications. > > > > 2. A set of standards for interacting with repositories of content > related to > > assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following general > > steps, which accommodate policy-driven and asset-driven assessment: > > > > 1. Identify endpoints > > > > 2. Determine specific endpoint elements to assess > > > > 3. Collect actual value of elements > > > > 4. Compare actual element values to expected element values > > > > 5. Report results > > > > This approach to endpoint posture collection enables multiple policies > to be > > evaluated based on a single data collection activity. Policies will be > evaluated > > by comparing available endpoint posture data according to rules > expressed in > > the policy. Typically, these rules will compare the actual value against > an > > expected value or range for specific posture elements. In some cases, the > > posture element may pertain to software installation state, in which > case the > > actual and expected values may be "installed" or "not installed." > Evaluation > > of multiple posture elements may be combined using predicate logic. > > > > Repository protocols are needed to store, update, and retrieve > configuration > > checks and other types of content required for posture assessment (see > > step 2 above). A content repository is expected to house specific > versions of > > checklists (i.e. benchmarks), may be required to satisfy different use > cases > > (i.e. asset inventory, configuration settings, or vulnerabilities). In > addition, > > content repositories are expected to store up-to-date dictionary of > specific > > enumerations, such as those used for configuration element identifiers, > > asset classifications, vulnerability identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format for > > retrieving configuration and policy information for driving data > collection and > > analysis > > - A standards-track document specifying a protocol and data format for > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in other > SDOs > > which can be used as-is or as a starting point for developing solutions > to the > > SACM requirements. The working group may decide to make of this > > document an Informational RFC, but this is not a mandatory deliverable. > > > > The working group will work in close coordination with other WGs in the > IETF > > (including, but not limited to MILE and NEA) in order to create > solutions that > > do not overlap and can be used or re-used to meet the goals of more than > > one working group. > > > > In accordance with existing IETF processes, the group will communicate > with > > and invite participation from other relevant standards bodies and > regulatory > > organizations, and if necessary reuse existing liaison relationships or > request > > the establishment of new liaison relationships. > > > > SACM-related efforts are largely aligned, and may overlap, with other > IETF > > (and non-IETF) standardization efforts. There are common "problems" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest > > to SACM is understanding and respecting the distinctions between itself > and > > NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > collected > > on the endpoint to an external service or data repository for further > analysis > > and action. NEA may also serve the purpose of carrying data-collection > > instructions. > > > > The MILE data formats provide a format to describe incident, > threat-related > > incident, and indicator information. SACM data formats provide ways to > > understand what endpoints are in your environment, whether they meet > > policy requirements, and their current configuration state. The data > > exchanged in MILE, supplementing the SACM data, creates enhanced > > situational awareness, thus enabling increased understanding of current > > threats and mitigations. > > > > After the work items in the current charter have been submitted to and > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking > > into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related > > standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data > > format for retrieving configuration and policy information for driving > data > > collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data > > format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases for > > consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements > for > > consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol > and > > data format for retrieving configuration and policy information for > driving > > data collection and analysis for consideration as standards-track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and > data > > format for collecting actual endpoint posture for consideration as > standards- > > track RFC > > > > 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. > -- John P. Field | Security Architect | Pivotal Direct: (908) 962-3394 | jfield@gopivotal.com *[image: cid:332B1A9B-BFB1-42CC-8C13-5949BB4B8266]* *goPivotal.com * --089e0149c0ea2f9e9d04ded1dfbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Mon, Jun 10, 2013 at 3:20 PM, Waltermire, David A. <david.waltermire@nist.gov> wrote:
+1 for me. =A0Are we good with handing this = off to Sean today?

Sincerely,
Dave

> -----Original Message-----
> From: Adam Montville [mailto:Adam.Montville@cisecurity.org]
> Sent: Friday, June 07, 2013 6:36 PM
> To: John Field
> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, Davi= d
> A.; sacm@ietf.org
> Subject: RE: [sacm] Upda= ted Candidate Charter Text
>
> Thanks John. =A0I've modified the "ROLIE paragraph" by t= runcating the last few
> sentences. =A0Also, changed Boolean to predicate.
>
> Are there any further nits or really bad oversights in this copy of th= e charter?
>
> If you like it as it stands, +1 it.
>
> For me, +1
>
> ---------------------------------------------
>
> Securing information and the systems that store, process, and transmit= that
> information is a challenging task for organizations of all sizes, and = many
> security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system<= br> > configurations would allow easier automation of the processes. Automat= ing
> these routine tasks would free security practitioners to focus on high= priority
> tasks, and should improve operators' ability to prioritize risk ba= sed on timely
> information about threats and vulnerabilities. This working group will= define
> security automation protocols and data format standards in support of<= br> > information security processes and practices. These standards will hel= p
> security practitioners to be more effective by automating routine task= s
> related to client and server security, freeing them to focus on more > advanced tasks. The initial focus of this work is to address enterpris= e use
> cases pertaining to the assessment of endpoint posture (using the
> definitions of Endpoint and Posture from RFC 5209).
>
> The working group will, whenever reasonable and possible, reuse existi= ng
> protocols, mechanisms, information and data models. Of particular inte= rest
> to this working group are existing industry standards, preferably IETF=
> standards, that could support automation of asset, change, configurati= on,
> and vulnerability management.
>
> The working group will define:
>
> 1. A set of standards to enable assessment of endpoint posture. This a= rea of
> focus provides for necessary language and data format specifications.<= br> >
> 2. A set of standards for interacting with repositories of content rel= ated to
> assessment of endpoint posture.
>
> Assessment of endpoint posture assessment entails the following genera= l
> steps, which accommodate policy-driven and asset-driven assessment: >
> 1. Identify endpoints
>
> 2. Determine specific endpoint elements to assess
>
> 3. Collect actual value of elements
>
> 4. Compare actual element values to expected element values
>
> 5. Report results
>
> This approach to endpoint posture collection enables multiple policies= to be
> evaluated based on a single data collection activity. Policies will be= evaluated
> by comparing available endpoint posture data according to rules expres= sed in
> the policy. Typically, these rules will compare the actual value again= st an
> expected value or range for specific posture elements. In some cases, = the
> posture element may pertain to software installation state, in which c= ase the
> actual and expected values may be "installed" or "not i= nstalled." Evaluation
> of multiple posture elements may be combined using predicate logic. >
> Repository protocols are needed to store, update, and retrieve configu= ration
> checks and other types of content required for posture assessment (see=
> step 2 above). =A0A content repository is expected to house specific v= ersions of
> checklists (i.e. benchmarks), may be required to satisfy different use= cases
> (i.e. asset inventory, configuration settings, or vulnerabilities). = =A0In addition,
> content repositories are expected to store up-to-date dictionary of sp= ecific
> enumerations, such as those used for configuration element identifiers= ,
> asset classifications, vulnerability identifiers, and so on.
>
> This working group will achieve the following deliverables:
>
> - An Informational document on Use Cases
> - An Informational document on Requirements
> - An Informational document on SACM Architecture
> - A standards-track document specifying a protocol and data format for=
> retrieving configuration and policy information for driving data colle= ction and
> analysis
> - A standards-track document specifying a protocol and data format for=
> collecting actual endpoint posture
>
> The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in oth= er SDOs
> which can be used as-is or as a starting point for developing solution= s to the
> SACM requirements. The working group may decide to make of this
> document an Informational RFC, but this is not a mandatory deliverable= .
>
> The working group will work in close coordination with other WGs in th= e IETF
> (including, but not limited to MILE and NEA) in order to create soluti= ons that
> do not overlap and can be used or re-used to meet the goals of more th= an
> one working group.
>
> In accordance with existing IETF processes, the group will communicate= with
> and invite participation from other relevant standards bodies and regu= latory
> organizations, and if necessary reuse existing liaison relationships o= r request
> the establishment of new liaison relationships.
>
> SACM-related efforts are largely aligned, and may overlap, with other = IETF
> (and non-IETF) standardization efforts. =A0There are common "prob= lems"
> found in SACM, that may be addressed by the work done in SNMP, IPFIX,<= br> > NETCONF, SYSLOG, NEA, MILE, and potentially others. =A0Of particular i= nterest
> to SACM is understanding and respecting the distinctions between itsel= f and
> NEA and MILE.
>
> One way the NEA protocols can be used is as the transport for data col= lected
> on the endpoint to an external service or data repository for further = analysis
> and action. =A0NEA may also serve the purpose of carrying data-collect= ion
> instructions.
>
> The MILE data formats provide a format to describe incident, threat-re= lated
> incident, and indicator information. =A0SACM data formats provide ways= to
> understand what endpoints are in your environment, whether they meet > policy requirements, and their current configuration state. =A0The dat= a
> exchanged in MILE, supplementing the SACM data, creates enhanced
> situational awareness, thus enabling increased understanding of curren= t
> threats and mitigations.
>
> After the work items in the current charter have been submitted to and=
> approved by the IESG, the WG will recharter or close.
>
> Goals and Milestones
>
> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases
>
> Oct. 2013 - Initial submission of an Internet-Draft on Requirements ta= king
> into consideration RFC5706 and RFC3535
>
> Oct. 2013 - Initial submission of an Internet-Draft on SACM Architectu= re
>
> Nov. 2013 - Initial submission of an Internet-Draft on overview of rel= ated
> standards work
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= data
> format for retrieving configuration and policy information for driving= data
> collection and analysis
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= data
> format for collecting actual endpoint posture
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases = for
> consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on Requiremen= ts for
> consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM
> Architecture for consideration as Informational RFC
>
> Oct. 2014 - Submission to the IESG of the Internet-Draft for a protoco= l and
> data format for retrieving configuration and policy information for dr= iving
> data collection and analysis for consideration as standards-track RFC<= br> >
> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol an= d data
> format for collecting actual endpoint posture for consideration as sta= ndards-
> track RFC
>
> This message and attachments may contain confidential information. =A0= 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. =A0Please notify the sender immediately and perma= nently
> delete the message and any attachments.



--
=

John P. Field |=A0Security Architect |=A0Pivotal

Direct: (908) 962-3394 | jfield@gopivotal.com=A0 <= /span>

3D"cid=

goPivotal.com
--089e0149c0ea2f9e9d04ded1dfbf-- --089e0149c0ea2f9e9f04ded1dfc0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 5b082271dab5eed9_0.1 iVBORw0KGgoAAAANSUhEUgAAAFIAAAAaCAYAAAAkJwuaAAAEJGlDQ1BJQ0MgUHJvZmlsZQAAOBGF Vd9v21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8 AUDZAw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWa GVWIlquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJP wG4VHX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzY Zi+3YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0 HPBLsF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgj ONd1ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyo Bc3SOjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrY BbueF9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiE hcPLYTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrB DgUKcm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfS Pqdraz/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1c AdMlDetv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0n fS/9TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8e k6fkvfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWW ing6noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8O okmrdtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/ wjvrVmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83 Gv+uNxo7XyL/FtFl8z9ZAHF4bBsrEwAABs9JREFUaAXtWX1oFEcUf2/3voQW24ggBAQhIAj5SylY hELEIggVQa4QPcFWkygUi1CwtFSEglIptFSaxI8SEiNNEKTSP6SCIA0UpKIQGioECoIghF4UCt4l t/v6m5n9vL29XBobi83A7cy8ee/NzG/nfcweiwitlKUjkFEq+FCpg9hdnVBn8ZwMXp5M0CMEPlRs I85u0CRrfkYGxx9Ghl/KJh/et1lvjMmR86P3VVsDiedXxPauRrvmIweIRJ5ibIjmqV8ujTyI8dm5 nWRZo4Zm9aM+Ght/GTsZ+1e9LYPLa6pttbRP5tXEfIxy/DuAPd2SzAtk4t7ieu7r3sp9+zct1zLM iYzOJnIJxn5Hk9hdS8Lr0d9FTO0e2wnuOzAtA8PgQ7FkGif2vG6LTOj6BT74SOlbsgpH9BJcUdYx tRzLaQTkLRkcuRKdnIvFHLUVhgHmu5rOcgK1BlL6RxXoBvio0P+snQSyAQAyPj7H7xU/oFx+L0zc xgntUOajAosOVBnu0mJSm5LBKxN8sLiO8oV3AlUO3ZQLw38E/boGHz6wgWzaocmOc1cujN6tYyGt s5BdTw7N+Q6+nifRt3gbrMeJ0WuVq3JxvBylYS9wXZlNCBmdOCwbSMis1a09ILc2Wc8flfXbLQGp mOW78RksSgWdNi1sZdehfki2vAFwBzWNbRVsJiiXQRZAhqYGMnQGz49Vs2HJUA/o6pSj2NtNjddV LNr0ev44WfwRFQprzTDoKgCS3CJXPlwgq+jGOrp9fUY+9wvqAEju3Q+ewjfgM/tSTKw5sRTAgx/2 /Yik8mazjKS1YKN0K/MmCVOkGs5GWhH+C0N34TvnNItIw4wgFJe9XnuGnlZuq7Y+gW35ewDxC3QN iB6TqWAFzPe4r3Q8Rl5Ex/hTZBwBiPIM4rAGiWcmOj7kwr03mKPlE0lrCurNwqxRFEDW/LRuN3h4 prcFJ0elRXjj3KkiqAxcTjh+nIhOpE8dRo1chRsxL6hQ+B60Tk/9bZjYpzRbu0+v5tspI3ug8xR+ eLn0JcCckoGRGx5vWCHYwN8rK0kUuJMuyrAJSiqNYTko/ZevRRlxEn8GyNuitLR2UyC173CzHdho FxKlz4IzzzwmA+PKzJsXR8bIZmNaQspnJoCE3ogvdcaUQgCzAyC9pZULXEW5sj0AmEidljPcU5rC a/1B8zB/jjoJpB5MedgCED0bFgA+EAcxRSqVnGra2MyPSCOekEo+tXnxK1qLyCT9WTmaqjE68KR6 00vmsWarsXkLm0yA6DE9qU144jsDNQ6djIAYkOX8yHV0/KC0WbuCYLSFBrM5aUKP4GdjWUoL0gmW VCATnCTwe9JP1erb2JjygQsW8D3DyVIbRpGtiPwxX6ciP8aN+boRsyZC7uoVp5J+RRU3HMtk/TzX l0ytdRAjUsESL7jOH6ZKNR9IN22GqYiahJECyGNyqxOtpAGJ6VyYt8UlAGZTFukTUcRn5f3TCLIx a09+VaAnSyZgBYRIg/lZ0LMklAmIKY3XyViXGhYKdaSwt0JOBVL6R861omBBntnqDSTzZR0ZmZR5 h0AyG/8oSKNmayotWZ4yC/DWBFOpgLXksgjT/mdzGf8mJhoydcGs9MkxPk22Gq1yLeYHmcNAZkVO T2IJ+AbgF5Ny+b2mNeaaC313xI00lWo++K8D6U0/ZmpeRW05E3RyeZXCeOmUczW2TKEwtXKyXbEx r2P8HC4Dqog4xPOpNydPpL7yrrW8kXu7W0px6hVE+8sDZLl6C5PO6InZ2mNqL+2BWatrZXRRNC9X NDiKaNmn64OU5m3LfQL/3eHJXcetw5xioTAQMqX7TZEhT1bNcVFfdQPC4hupPnLxqtIllNniFoFT hwQYtxzu2Vci2zJ5Ikn8NEKN+uaJ9GsIzffhW9txb/+Ne0tn0b5PrrsOsrjzW17+iduIyMlwdgRH vzCdgp6NflfXNTorF0emaXZuDJeMHtCwDt5IWbmHNd5B8FFfs84tcPWMqVSd5TmRaiYsDj+YIPya bQ9j8avQh6+qfq2GE6VcPYpx/YUJY2t1Lsv8kyfrByncgWl3bNPlCtwIPu3pgtyXuSf2sx2d9mif 7FZ2g9dLz1SerK+dAFd9Olxc8U+kmtgkt8zlRakw/EbWlYdpsup6iJN4ELckfCDQQQKmrq5wjf+a 0AGB6BD81xC+3p+A3k2Qw5cZgM88SS7Ss9nKGfCFpgwm1Ud+uoU4dwyAtIPX/C3gLywSlDx3sFv7 SLbhbwVffyzktY4X7HT6Z9yDE0m1QqyCuXnlzy8f4aXVy2faS1vnf156Bcjn9IpWgFwB8jkh8JzU /A3WyVI+PC3NMwAAAABJRU5ErkJggg== --089e0149c0ea2f9e9f04ded1dfc0-- From Kent_Landfield@mcafee.com Mon Jun 10 12:36:06 2013 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 07C9521F9AE8 for ; Mon, 10 Jun 2013 12:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1IN4zMWnB7c for ; Mon, 10 Jun 2013 12:36:01 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id A138C21F9A44 for ; Mon, 10 Jun 2013 12:36:01 -0700 (PDT) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 7a7d_4f8b_964ab378_97fb_4495_9d3c_b4d97649c1db; Mon, 10 Jun 2013 14:35:47 -0500 Received: from MIVEXAPP1N3.corp.nai.org (10.48.48.63) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 10 Jun 2013 15:35:22 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAPP1N3.corp.nai.org ([169.254.3.112]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 15:35:22 -0400 From: To: Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6xNalvQ89Okyx82eII/CXtpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAABAsA Date: Mon, 10 Jun 2013 19:35:21 +0000 Message-ID: References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <9E97ABFB4E30644F995B09CBDE1BB6DA@McAfee.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: adam@stoicsecurity.com, sacm@ietf.org, jfield@gopivotal.com, Gunnar.Engelbach@threatguard.com, turners@ieca.com, Adam.Montville@cisecurity.org Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:36:06 -0000 +1 for me. Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026=20 On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." wrote: > +1 for me. Are we good with handing this off to Sean today? >=20 > Sincerely, > Dave >=20 >> -----Original Message----- >> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >> Sent: Friday, June 07, 2013 6:36 PM >> To: John Field >> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, David >> A.; sacm@ietf.org >> Subject: RE: [sacm] Updated Candidate Charter Text >>=20 >> Thanks John. I've modified the "ROLIE paragraph" by truncating the last= few >> sentences. Also, changed Boolean to predicate. >>=20 >> Are there any further nits or really bad oversights in this copy of the = charter? >>=20 >> If you like it as it stands, +1 it. >>=20 >> For me, +1 >>=20 >> --------------------------------------------- >>=20 >> Securing information and the systems that store, process, and transmit t= hat >> information is a challenging task for organizations of all sizes, and ma= ny >> security practitioners spend much of their time on manual processes. >> Standardized processes to collect, verify, and update security system >> configurations would allow easier automation of the processes. Automatin= g >> these routine tasks would free security practitioners to focus on high p= riority >> tasks, and should improve operators' ability to prioritize risk based on= timely >> information about threats and vulnerabilities. This working group will d= efine >> security automation protocols and data format standards in support of >> information security processes and practices. These standards will help >> security practitioners to be more effective by automating routine tasks >> related to client and server security, freeing them to focus on more >> advanced tasks. The initial focus of this work is to address enterprise = use >> cases pertaining to the assessment of endpoint posture (using the >> definitions of Endpoint and Posture from RFC 5209). >>=20 >> The working group will, whenever reasonable and possible, reuse existing >> protocols, mechanisms, information and data models. Of particular intere= st >> to this working group are existing industry standards, preferably IETF >> standards, that could support automation of asset, change, configuration= , >> and vulnerability management. >>=20 >> The working group will define: >>=20 >> 1. A set of standards to enable assessment of endpoint posture. This are= a of >> focus provides for necessary language and data format specifications. >>=20 >> 2. A set of standards for interacting with repositories of content relat= ed to >> assessment of endpoint posture. >>=20 >> Assessment of endpoint posture assessment entails the following general >> steps, which accommodate policy-driven and asset-driven assessment: >>=20 >> 1. Identify endpoints >>=20 >> 2. Determine specific endpoint elements to assess >>=20 >> 3. Collect actual value of elements >>=20 >> 4. Compare actual element values to expected element values >>=20 >> 5. Report results >>=20 >> This approach to endpoint posture collection enables multiple policies t= o be >> evaluated based on a single data collection activity. Policies will be e= valuated >> by comparing available endpoint posture data according to rules expresse= d in >> the policy. Typically, these rules will compare the actual value against= an >> expected value or range for specific posture elements. In some cases, th= e >> posture element may pertain to software installation state, in which cas= e the >> actual and expected values may be "installed" or "not installed." Evalua= tion >> of multiple posture elements may be combined using predicate logic. >>=20 >> Repository protocols are needed to store, update, and retrieve configura= tion >> checks and other types of content required for posture assessment (see >> step 2 above). A content repository is expected to house specific versi= ons of >> checklists (i.e. benchmarks), may be required to satisfy different use c= ases >> (i.e. asset inventory, configuration settings, or vulnerabilities). In = addition, >> content repositories are expected to store up-to-date dictionary of spec= ific >> enumerations, such as those used for configuration element identifiers, >> asset classifications, vulnerability identifiers, and so on. >>=20 >> This working group will achieve the following deliverables: >>=20 >> - An Informational document on Use Cases >> - An Informational document on Requirements >> - An Informational document on SACM Architecture >> - A standards-track document specifying a protocol and data format for >> retrieving configuration and policy information for driving data collect= ion and >> analysis >> - A standards-track document specifying a protocol and data format for >> collecting actual endpoint posture >>=20 >> The working group will create an overview of related standards work >> Internet-Draft which will document existing work in the IETF or in other= SDOs >> which can be used as-is or as a starting point for developing solutions = to the >> SACM requirements. The working group may decide to make of this >> document an Informational RFC, but this is not a mandatory deliverable. >>=20 >> The working group will work in close coordination with other WGs in the = IETF >> (including, but not limited to MILE and NEA) in order to create solution= s that >> do not overlap and can be used or re-used to meet the goals of more than >> one working group. >>=20 >> In accordance with existing IETF processes, the group will communicate w= ith >> and invite participation from other relevant standards bodies and regula= tory >> organizations, and if necessary reuse existing liaison relationships or = request >> the establishment of new liaison relationships. >>=20 >> SACM-related efforts are largely aligned, and may overlap, with other IE= TF >> (and non-IETF) standardization efforts. There are common "problems" >> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular inter= est >> to SACM is understanding and respecting the distinctions between itself = and >> NEA and MILE. >>=20 >> One way the NEA protocols can be used is as the transport for data colle= cted >> on the endpoint to an external service or data repository for further an= alysis >> and action. NEA may also serve the purpose of carrying data-collection >> instructions. >>=20 >> The MILE data formats provide a format to describe incident, threat-rela= ted >> incident, and indicator information. SACM data formats provide ways to >> understand what endpoints are in your environment, whether they meet >> policy requirements, and their current configuration state. The data >> exchanged in MILE, supplementing the SACM data, creates enhanced >> situational awareness, thus enabling increased understanding of current >> threats and mitigations. >>=20 >> After the work items in the current charter have been submitted to and >> approved by the IESG, the WG will recharter or close. >>=20 >> Goals and Milestones >>=20 >> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>=20 >> Oct. 2013 - Initial submission of an Internet-Draft on Requirements taki= ng >> into consideration RFC5706 and RFC3535 >>=20 >> Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture >>=20 >> Nov. 2013 - Initial submission of an Internet-Draft on overview of relat= ed >> standards work >>=20 >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata >> format for retrieving configuration and policy information for driving d= ata >> collection and analysis >>=20 >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata >> format for collecting actual endpoint posture >>=20 >> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases fo= r >> consideration as Informational RFC >>=20 >> Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements= for >> consideration as Informational RFC >>=20 >> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >> Architecture for consideration as Informational RFC >>=20 >> Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol = and >> data format for retrieving configuration and policy information for driv= ing >> data collection and analysis for consideration as standards-track RFC >>=20 >> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and = data >> format for collecting actual endpoint posture for consideration as stand= ards- >> track RFC >>=20 >> This message and attachments may contain confidential information. If i= t >> appears that this message was sent to you by mistake, any retention, >> dissemination, distribution or copying of this message and attachments i= s >> strictly prohibited. Please notify the sender immediately and permanent= ly >> delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Mon Jun 10 12:51:12 2013 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 1D9AC21F8EAE for ; Mon, 10 Jun 2013 12:51:12 -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 Mf-Y42A96Jmk for ; Mon, 10 Jun 2013 12:51:07 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id ADE8521F8607 for ; Mon, 10 Jun 2013 12:51:07 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5AJoxl6007425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 15:51:01 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 10 Jun 2013 15:50:54 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5AJoo0W022014; Mon, 10 Jun 2013 15:50:52 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub33.corp.emc.com ([::1]) with mapi; Mon, 10 Jun 2013 15:50:49 -0400 From: "Moriarty, Kathleen" To: "Kent_Landfield@McAfee.com" , "david.waltermire@nist.gov" Date: Mon, 10 Jun 2013 15:50:48 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6xNalvQ89Okyx82eII/CXtpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAABAsA///BB9A= Message-ID: References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "adam@stoicsecurity.com" , "sacm@ietf.org" , "Field, John \(Pivotal\)" , "Gunnar.Engelbach@threatguard.com" , "turners@ieca.com" , "Adam.Montville@cisecurity.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:51:12 -0000 I am mostly a +1, but would add one sentence at the end of the MILE descrip= tion to tie in options for ROLIE and other transports. Transports from MILE may be used by SACM. Thank you, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, June 10, 2013 3:35 PM To: david.waltermire@nist.gov Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); Gunnar.En= gelbach@threatguard.com; turners@ieca.com; Adam.Montville@cisecurity.org Subject: Re: [sacm] Updated Candidate Charter Text +1 for me. Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026=20 On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." wrote: > +1 for me. Are we good with handing this off to Sean today? >=20 > Sincerely, > Dave >=20 >> -----Original Message----- >> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >> Sent: Friday, June 07, 2013 6:36 PM >> To: John Field >> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, David >> A.; sacm@ietf.org >> Subject: RE: [sacm] Updated Candidate Charter Text >>=20 >> Thanks John. I've modified the "ROLIE paragraph" by truncating the last= few >> sentences. Also, changed Boolean to predicate. >>=20 >> Are there any further nits or really bad oversights in this copy of the = charter? >>=20 >> If you like it as it stands, +1 it. >>=20 >> For me, +1 >>=20 >> --------------------------------------------- >>=20 >> Securing information and the systems that store, process, and transmit t= hat >> information is a challenging task for organizations of all sizes, and ma= ny >> security practitioners spend much of their time on manual processes. >> Standardized processes to collect, verify, and update security system >> configurations would allow easier automation of the processes. Automatin= g >> these routine tasks would free security practitioners to focus on high p= riority >> tasks, and should improve operators' ability to prioritize risk based on= timely >> information about threats and vulnerabilities. This working group will d= efine >> security automation protocols and data format standards in support of >> information security processes and practices. These standards will help >> security practitioners to be more effective by automating routine tasks >> related to client and server security, freeing them to focus on more >> advanced tasks. The initial focus of this work is to address enterprise = use >> cases pertaining to the assessment of endpoint posture (using the >> definitions of Endpoint and Posture from RFC 5209). >>=20 >> The working group will, whenever reasonable and possible, reuse existing >> protocols, mechanisms, information and data models. Of particular intere= st >> to this working group are existing industry standards, preferably IETF >> standards, that could support automation of asset, change, configuration= , >> and vulnerability management. >>=20 >> The working group will define: >>=20 >> 1. A set of standards to enable assessment of endpoint posture. This are= a of >> focus provides for necessary language and data format specifications. >>=20 >> 2. A set of standards for interacting with repositories of content relat= ed to >> assessment of endpoint posture. >>=20 >> Assessment of endpoint posture assessment entails the following general >> steps, which accommodate policy-driven and asset-driven assessment: >>=20 >> 1. Identify endpoints >>=20 >> 2. Determine specific endpoint elements to assess >>=20 >> 3. Collect actual value of elements >>=20 >> 4. Compare actual element values to expected element values >>=20 >> 5. Report results >>=20 >> This approach to endpoint posture collection enables multiple policies t= o be >> evaluated based on a single data collection activity. Policies will be e= valuated >> by comparing available endpoint posture data according to rules expresse= d in >> the policy. Typically, these rules will compare the actual value against= an >> expected value or range for specific posture elements. In some cases, th= e >> posture element may pertain to software installation state, in which cas= e the >> actual and expected values may be "installed" or "not installed." Evalua= tion >> of multiple posture elements may be combined using predicate logic. >>=20 >> Repository protocols are needed to store, update, and retrieve configura= tion >> checks and other types of content required for posture assessment (see >> step 2 above). A content repository is expected to house specific versi= ons of >> checklists (i.e. benchmarks), may be required to satisfy different use c= ases >> (i.e. asset inventory, configuration settings, or vulnerabilities). In = addition, >> content repositories are expected to store up-to-date dictionary of spec= ific >> enumerations, such as those used for configuration element identifiers, >> asset classifications, vulnerability identifiers, and so on. >>=20 >> This working group will achieve the following deliverables: >>=20 >> - An Informational document on Use Cases >> - An Informational document on Requirements >> - An Informational document on SACM Architecture >> - A standards-track document specifying a protocol and data format for >> retrieving configuration and policy information for driving data collect= ion and >> analysis >> - A standards-track document specifying a protocol and data format for >> collecting actual endpoint posture >>=20 >> The working group will create an overview of related standards work >> Internet-Draft which will document existing work in the IETF or in other= SDOs >> which can be used as-is or as a starting point for developing solutions = to the >> SACM requirements. The working group may decide to make of this >> document an Informational RFC, but this is not a mandatory deliverable. >>=20 >> The working group will work in close coordination with other WGs in the = IETF >> (including, but not limited to MILE and NEA) in order to create solution= s that >> do not overlap and can be used or re-used to meet the goals of more than >> one working group. >>=20 >> In accordance with existing IETF processes, the group will communicate w= ith >> and invite participation from other relevant standards bodies and regula= tory >> organizations, and if necessary reuse existing liaison relationships or = request >> the establishment of new liaison relationships. >>=20 >> SACM-related efforts are largely aligned, and may overlap, with other IE= TF >> (and non-IETF) standardization efforts. There are common "problems" >> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular inter= est >> to SACM is understanding and respecting the distinctions between itself = and >> NEA and MILE. >>=20 >> One way the NEA protocols can be used is as the transport for data colle= cted >> on the endpoint to an external service or data repository for further an= alysis >> and action. NEA may also serve the purpose of carrying data-collection >> instructions. >>=20 >> The MILE data formats provide a format to describe incident, threat-rela= ted >> incident, and indicator information. SACM data formats provide ways to >> understand what endpoints are in your environment, whether they meet >> policy requirements, and their current configuration state. The data >> exchanged in MILE, supplementing the SACM data, creates enhanced >> situational awareness, thus enabling increased understanding of current >> threats and mitigations. >>=20 >> After the work items in the current charter have been submitted to and >> approved by the IESG, the WG will recharter or close. >>=20 >> Goals and Milestones >>=20 >> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>=20 >> Oct. 2013 - Initial submission of an Internet-Draft on Requirements taki= ng >> into consideration RFC5706 and RFC3535 >>=20 >> Oct. 2013 - Initial submission of an Internet-Draft on SACM Architecture >>=20 >> Nov. 2013 - Initial submission of an Internet-Draft on overview of relat= ed >> standards work >>=20 >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata >> format for retrieving configuration and policy information for driving d= ata >> collection and analysis >>=20 >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and d= ata >> format for collecting actual endpoint posture >>=20 >> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases fo= r >> consideration as Informational RFC >>=20 >> Apr. 2014 - Submission to the IESG of the Internet-Draft on Requirements= for >> consideration as Informational RFC >>=20 >> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >> Architecture for consideration as Informational RFC >>=20 >> Oct. 2014 - Submission to the IESG of the Internet-Draft for a protocol = and >> data format for retrieving configuration and policy information for driv= ing >> data collection and analysis for consideration as standards-track RFC >>=20 >> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol and = data >> format for collecting actual endpoint posture for consideration as stand= ards- >> track RFC >>=20 >> This message and attachments may contain confidential information. If i= t >> appears that this message was sent to you by mistake, any retention, >> dissemination, distribution or copying of this message and attachments i= s >> strictly prohibited. Please notify the sender immediately and permanent= ly >> delete the message and any attachments. > _______________________________________________ > 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 Adam.Montville@cisecurity.org Mon Jun 10 13:33:02 2013 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 BC15221F826B for ; Mon, 10 Jun 2013 13:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzcCEThecHxj for ; Mon, 10 Jun 2013 13:32:58 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.102]) by ietfa.amsl.com (Postfix) with ESMTP id AE02221F9A28 for ; Mon, 10 Jun 2013 13:32:57 -0700 (PDT) Received: from [216.82.253.227:30936] by server-6.bemta-7.messagelabs.com id FD/19-21879-8F736B15; Mon, 10 Jun 2013 20:32:56 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-7.tower-170.messagelabs.com!1370896373!24909460!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 25605 invoked from network); 10 Jun 2013 20:32:55 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-7.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2013 20:32:55 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 16:32:41 -0400 From: Adam Montville To: "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" , "david.waltermire@nist.gov" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAASVeA///unPAAkC8MwAAI+H2AAACKIgAACBQQoA== Date: Mon, 10 Jun 2013 20:32:41 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Gunnar.Engelbach@threatguard.com" , "turners@ieca.com" , "Field, John \(Pivotal\)" , "adam@stoicsecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:33:02 -0000 I don't have an objection to adding that sentence. Other opinions? > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Monday, June 10, 2013 12:51 PM > To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov > Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville > Subject: RE: [sacm] Updated Candidate Charter Text >=20 > I am mostly a +1, but would add one sentence at the end of the MILE > description to tie in options for ROLIE and other transports. >=20 > Transports from MILE may be used by SACM. >=20 > Thank you, > Kathleen >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Kent_Landfield@McAfee.com > Sent: Monday, June 10, 2013 3:35 PM > To: david.waltermire@nist.gov > Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > Gunnar.Engelbach@threatguard.com; turners@ieca.com; > Adam.Montville@cisecurity.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > +1 for me. >=20 > Kent Landfield > McAfee Labs > Kent_Landfield@McAfee.com > +1.817.637.8026 >=20 > On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." > wrote: >=20 > > +1 for me. Are we good with handing this off to Sean today? > > > > Sincerely, > > Dave > > > >> -----Original Message----- > >> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > >> Sent: Friday, June 07, 2013 6:36 PM > >> To: John Field > >> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > >> David A.; sacm@ietf.org > >> Subject: RE: [sacm] Updated Candidate Charter Text > >> > >> Thanks John. I've modified the "ROLIE paragraph" by truncating the > >> last few sentences. Also, changed Boolean to predicate. > >> > >> Are there any further nits or really bad oversights in this copy of t= he > charter? > >> > >> If you like it as it stands, +1 it. > >> > >> For me, +1 > >> > >> --------------------------------------------- > >> > >> Securing information and the systems that store, process, and > >> transmit that information is a challenging task for organizations of > >> all sizes, and many security practitioners spend much of their time o= n > manual processes. > >> Standardized processes to collect, verify, and update security system= > >> configurations would allow easier automation of the processes. > >> Automating these routine tasks would free security practitioners to > >> focus on high priority tasks, and should improve operators' ability > >> to prioritize risk based on timely information about threats and > >> vulnerabilities. This working group will define security automation > >> protocols and data format standards in support of information > >> security processes and practices. These standards will help security > >> practitioners to be more effective by automating routine tasks > >> related to client and server security, freeing them to focus on more > >> advanced tasks. The initial focus of this work is to address > >> enterprise=20use cases pertaining to the assessment of endpoint postu= re > (using the definitions of Endpoint and Posture from RFC 5209). > >> > >> The working group will, whenever reasonable and possible, reuse > >> existing protocols, mechanisms, information and data models. Of > >> particular interest to this working group are existing industry > >> standards, preferably IETF standards, that could support automation > >> of asset, change, configuration, and vulnerability management. > >> > >> The working group will define: > >> > >> 1. A set of standards to enable assessment of endpoint posture. This > >> area of focus provides for necessary language and data format > specifications. > >> > >> 2. A set of standards for interacting with repositories of content > >> related to assessment of endpoint posture. > >> > >> Assessment of endpoint posture assessment entails the following > >> general steps, which accommodate policy-driven and asset-driven > assessment: > >> > >> 1. Identify endpoints > >> > >> 2. Determine specific endpoint elements to assess > >> > >> 3. Collect actual value of elements > >> > >> 4. Compare actual element values to expected element values > >> > >> 5. Report results > >> > >> This approach to endpoint posture collection enables multiple > >> policies to be evaluated based on a single data collection activity. > >> Policies will be evaluated by comparing available endpoint posture > >> data according to rules expressed in the policy. Typically, these > >> rules will compare the actual value against an expected value or > >> range for specific posture elements. In some cases, the posture > >> element may pertain to software installation state, in which case the= > >> actual and expected values may be "installed" or "not installed." > Evaluation of multiple posture elements may be combined using predicate > logic. > >> > >> Repository protocols are needed to store, update, and retrieve > >> configuration checks and other types of content required for posture > >> assessment (see step 2 above). A content repository is expected to > >> house specific versions of checklists (i.e. benchmarks), may be > >> required to satisfy different use cases (i.e. asset inventory, > >> configuration settings, or vulnerabilities). In addition, content > >> repositories are expected to store up-to-date dictionary of specific > >> enumerations, such as those used for configuration element identifier= s, > asset classifications, vulnerability identifiers, and so on. > >> > >> This working group will achieve the following deliverables: > >> > >> - An Informational document on Use Cases > >> - An Informational document on Requirements > >> - An Informational document on SACM Architecture > >> - A standards-track document specifying a protocol and data format > >> for retrieving configuration and policy information for driving data > >> collection and analysis > >> - A standards-track document specifying a protocol and data format > >> for collecting actual endpoint posture > >> > >> The working group will create an overview of related standards work > >> Internet-Draft which will document existing work in the IETF or in > >> other SDOs which can be used as-is or as a starting point for > >> developing solutions to the SACM requirements. The working group may > >> decide to make of this document an Informational RFC, but this is not= a > mandatory deliverable. > >> > >> The working group will work in close coordination with other WGs in > >> the IETF (including, but not limited to MILE and NEA) in order to > >> create solutions that do not overlap and can be used or re-used to > >> meet the goals of more than one working group. > >> > >> In accordance with existing IETF processes, the group will > >> communicate with and invite participation from other relevant > >> standards bodies and regulatory organizations, and if necessary reuse= > >> existing liaison relationships or request the establishment of new li= aison > relationships. > >> > >> SACM-related efforts are largely aligned, and may overlap, with other= > >> IETF (and non-IETF) standardization efforts. There are common > "problems" > >> found in SACM, that may be addressed by the work done in SNMP, IPFIX,= > >> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > >> interest to SACM is understanding and respecting the distinctions > >> between itself and NEA and MILE. > >> > >> One way the NEA protocols can be used is as the transport for data > >> collected on the endpoint to an external service or data repository > >> for further analysis and action. NEA may also serve the purpose of > >> carrying data-collection instructions. > >> > >> The MILE data formats provide a format to describe incident, > >> threat-related incident, and indicator information. SACM data > >> formats provide ways to understand what endpoints are in your > >> environment, whether they meet policy requirements, and their current= > >> configuration state. The data exchanged in MILE, supplementing the > >> SACM data, creates enhanced situational awareness, thus enabling > >> increased understanding of current threats and mitigations. > >> > >> After the work items in the current charter have been submitted to > >> and approved by the IESG, the WG will recharter or close. > >> > >> Goals and Milestones > >> > >> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > >> > >> Oct. 2013 - Initial submission of an Internet-Draft on Requirements > >> taking into consideration RFC5706 and RFC3535 > >> > >> Oct. 2013 - Initial submission of an Internet-Draft on SACM > >> Architecture > >> > >> Nov. 2013 - Initial submission of an Internet-Draft on overview of > >> related standards work > >> > >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol > >> and data format for retrieving configuration and policy information > >> for driving data collection and analysis > >> > >> Jan. 2014 - Initial submission of an Internet-Draft for a protocol > >> and data format for collecting actual endpoint posture > >> > >> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases= > >> for consideration as Informational RFC > >> > >> Apr. 2014 - Submission to the IESG of the Internet-Draft on > >> Requirements for consideration as Informational RFC > >> > >> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > >> Architecture for consideration as Informational RFC > >> > >> Oct. 2014 - Submission to the IESG of the Internet-Draft for a > >> protocol and data format for retrieving configuration and policy > >> information for driving data collection and analysis for > >> consideration as standards-track RFC > >> > >> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > >> and data format for collecting actual endpoint posture for > >> consideration as standards- track RFC > >> > >> 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. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... 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 Adam.Montville@cisecurity.org Mon Jun 10 13:33:07 2013 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 03A6A21F826B for ; Mon, 10 Jun 2013 13:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-yPdiKYuYHv for ; Mon, 10 Jun 2013 13:33:01 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEFE21F9A47 for ; Mon, 10 Jun 2013 13:33:00 -0700 (PDT) Received: from [216.82.253.243:62582] by server-2.bemta-7.messagelabs.com id 10/85-32713-CF736B15; Mon, 10 Jun 2013 20:33:00 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-171.messagelabs.com!1370896378!9568294!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 11413 invoked from network); 10 Jun 2013 20:32:59 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2013 20:32:59 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 16:32:46 -0400 From: Adam Montville To: "Waltermire, David A." , John Field Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAASVeA///unPAAkC8MwAABckzw Date: Mon, 10 Jun 2013 20:32:46 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F4F64@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , Sean Turner , "Adam W. Montville" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:33:07 -0000 I think once we add the sentence Kathleen would like to see, we're probabl= y good. Any objections to that? > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Monday, June 10, 2013 12:20 PM > To: Adam Montville; John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text >=20 > +1 for me. Are we good with handing this off to Sean today? >=20 > Sincerely, > Dave >=20 > > -----Original Message----- > > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > > Sent: Friday, June 07, 2013 6:36 PM > > To: John Field > > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > > David A.; sacm@ietf.org > > Subject: RE: [sacm] Updated Candidate Charter Text > > > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > > last few sentences. Also, changed Boolean to predicate. > > > > Are there any further nits or really bad oversights in this copy of th= e > charter? > > > > If you like it as it stands, +1 it. > > > > For me, +1 > > > > --------------------------------------------- > > > > Securing information and the systems that store, process, and transmit= > > that information is a challenging task for organizations of all sizes,= > > and many security practitioners spend much of their time on manual > processes. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. > > Automating these routine tasks would free security practitioners to > > focus on high priority tasks, and should improve operators' ability to= > > prioritize risk based on timely information about threats and > > vulnerabilities. This working group will define security automation > > protocols and data format standards in support of information security= > > processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks related= > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > > cases pertaining to the assessment of endpoint posture (using the > definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse > > existing protocols, mechanisms, information and data models. Of > > particular interest to this working group are existing industry > > standards, preferably IETF standards, that could support automation of= > > asset, change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area of focus provides for necessary language and data format > specifications. > > > > 2. A set of standards for interacting with repositories of content > > related to assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following > > general steps, which accommodate policy-driven and asset-driven > assessment: > > > > 1. Identify endpoints > > > > 2. Determine specific endpoint elements to assess > > > > 3. Collect actual value of elements > > > > 4. Compare actual element values to expected element values > > > > 5. Report results > > > > This approach to endpoint posture collection enables multiple policies= > > to be evaluated based on a single data collection activity. Policies > > will be evaluated by comparing available endpoint posture data > > according to rules expressed in the policy. Typically, these rules > > will compare the actual value against an expected value or range for > > specific posture elements. In some cases, the posture element may > > pertain to software installation state, in which case the actual and > > expected values may be "installed" or "not installed." Evaluation of m= ultiple > posture elements may be combined using predicate logic. > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. asset inventory, > > configuration settings, or vulnerabilities). In addition, content > > repositories are expected to store up-to-date dictionary of specific > > enumerations, such as those used for configuration element identifiers= , > asset classifications, vulnerability identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format for= > > retrieving configuration and policy information for driving data > > collection and analysis > > - A standards-track document specifying a protocol and data format for= > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > > other SDOs which can be used as-is or as a starting point for > > developing solutions to the SACM requirements. The working group may > > decide to make of this document an Informational RFC, but this is not = a > mandatory deliverable. > > > > The working group will work in close coordination with other WGs in > > the IETF (including, but not limited to MILE and NEA) in order to > > create solutions that do not overlap and can be used or re-used to > > meet the goals of more than one working group. > > > > In accordance with existing IETF processes, the group will communicate= > > with and invite participation from other relevant standards bodies and= > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison relationship= s. > > > > SACM-related efforts are largely aligned, and may overlap, with other > > IETF (and non-IETF) standardization efforts. There are common "proble= ms" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > > interest to SACM is understanding and respecting the distinctions > > between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data-collection instructions. > > > > The MILE data formats provide a format to describe incident, > > threat-related incident, and indicator information. SACM data formats= > > provide ways to understand what endpoints are in your environment, > > whether they meet policy requirements, and their current configuration= > > state. The data exchanged in MILE, supplementing the SACM data, > > creates enhanced situational awareness, thus enabling increased > > understanding of current threats and mitigations. > > > > After the work items in the current charter have been submitted to and= > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > taking into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > related standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= > > data format for retrieving configuration and policy information for > > driving data collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= > > data format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > Requirements for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > protocol and data format for retrieving configuration and policy > > information for driving data collection and analysis for consideration= > > as standards-track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > and data format for collecting actual endpoint posture for > > consideration as standards- track RFC > > > > 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. >=20 > ... 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 Kent_Landfield@mcafee.com Mon Jun 10 13:43:26 2013 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 E0F3D21F9AB0 for ; Mon, 10 Jun 2013 13:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06UpRNWNxMUO for ; Mon, 10 Jun 2013 13:43:22 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 95A5B21F9AB9 for ; Mon, 10 Jun 2013 13:43:17 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 7a83_cff5_49a4f466_62cf_4e70_92f9_22c7c3fb2801; Mon, 10 Jun 2013 15:43:05 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER1N2.corp.nai.org ([169.254.3.103]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 16:42:12 -0400 From: To: , , Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6xNalvQ89Okyx82eII/CXtpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAAFEIA//+uz4A= Date: Mon, 10 Jun 2013 20:42:12 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF28F692@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F4F64@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF28F692MIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: Gunnar.Engelbach@threatguard.com, turners@ieca.com, adam@stoicsecurity.com, sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:43:27 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF28F692MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the sentence is "Transports from MILE may be used by SACM." I have no pr= oblem with it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, June 10, 2013 3:32 PM To: David Waltermire >, John Field > Cc: Gunnar Engelbach >, Sean Turner >, "Adam W. Montville" >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text I think once we add the sentence Kathleen would like to see, we're probably= good. Any objections to that? -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, June 10, 2013 12:20 PM To: Adam Montville; John Field Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org Subject: RE: [sacm] Updated Candidate Charter Text +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > David A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > last few sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are existing industry > standards, preferably IETF standards, that could support automation of > asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of mult= iple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in > the IETF (including, but not limited to MILE and NEA) in order to > create solutions that do not overlap and can be used or re-used to > meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, > creates enhanced situational awareness, thus enabling increased > understanding of current threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol and data format for retrieving configuration and policy > information for driving data collection and analysis for consideration > as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and data format for collecting actual endpoint posture for > consideration as standards- track RFC > > 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. ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF28F692MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
If the sentence is "Transports from MILE = may be used by SACM." I have no problem with it.

Kent Landfield

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

From: Adam Montville <Adam.Montville@cisecurity.org>= ;
Date: Monday, June 10, 2013 3:32 PM=
To: David Waltermire <david.waltermire@nist.gov>, John = Field <jfield@gopivotal.com&= gt;
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com<= /a>>, Sean Turner <turners@ieca.c= om>, "Adam W. Montville" <adam@stoicsecurity.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Updated Candida= te Charter Text

I think once we add the sentence Kathleen would like to see, we're pro= bably good.

Any objections to that?

-----Original Message-----
From: Waltermire, David A. [mailto:david.waltermire@nist.gov]
Sent: Monday, June 10, 2013 12:20 PM
To: Adam Montville; John Field
Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org
Subject: RE: [sacm] Updated Candidate Charter Text
+1 for me.  Are we good with handing this off to Sean to= day?
Sincerely,
Dave
> -----Original Message-----
> From: Adam Montville [mailto:Adam.Montville@cisecurity.org]
> Sent: Friday, June 07, 2013 6:36 PM
> To: John Field
> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire,=
> David A.; sacm@ietf.org
> Subject: RE: [sacm] Updated Candidate Charter Text
>
> Thanks John.  I've modified the "ROLIE paragraph&q= uot; by truncating the
> last few sentences.  Also, changed Boolean to predicate= .
>
> Are there any further nits or really bad oversights in this copy = of the
charter?
>
> If you like it as it stands, +1 it.
>
> For me, +1
>
> ---------------------------------------------
>
> Securing information and the systems that store, process, and tra= nsmit
> that information is a challenging task for organizations of all s= izes,
> and many security practitioners spend much of their time on manua= l
processes.
> Standardized processes to collect, verify, and update security sy= stem
> configurations would allow easier automation of the processes.
> Automating these routine tasks would free security practitioners = to
> focus on high priority tasks, and should improve operators' abili= ty to
> prioritize risk based on timely information about threats and
> vulnerabilities. This working group will define security automati= on
> protocols and data format standards in support of information sec= urity
> processes and practices. These standards will help security
> practitioners to be more effective by automating routine tasks re= lated
> to client and server security, freeing them to focus on more adva= nced
> tasks. The initial focus of this work is to address enterprise us= e
> cases pertaining to the assessment of endpoint posture (using the=
definitions of Endpoint and Posture from RFC 5209).
>
> The working group will, whenever reasonable and possible, reuse
> existing protocols, mechanisms, information and data models. Of
> particular interest to this working group are existing industry
> standards, preferably IETF standards, that could support automati= on of
> asset, change, configuration, and vulnerability management.
>
> The working group will define:
>
> 1. A set of standards to enable assessment of endpoint posture. T= his
> area of focus provides for necessary language and data format
specifications.
>
> 2. A set of standards for interacting with repositories of conten= t
> related to assessment of endpoint posture.
>
> Assessment of endpoint posture assessment entails the following
> general steps, which accommodate policy-driven and asset-driven
assessment:
>
> 1. Identify endpoints
>
> 2. Determine specific endpoint elements to assess
>
> 3. Collect actual value of elements
>
> 4. Compare actual element values to expected element values
>
> 5. Report results
>
> This approach to endpoint posture collection enables multiple pol= icies
> to be evaluated based on a single data collection activity. Polic= ies
> will be evaluated by comparing available endpoint posture data
> according to rules expressed in the policy. Typically, these rule= s
> will compare the actual value against an expected value or range = for
> specific posture elements. In some cases, the posture element may=
> pertain to software installation state, in which case the actual = and
> expected values may be "installed" or "not install= ed." Evaluation of multiple
posture elements may be combined using predicate logic.
>
> Repository protocols are needed to store, update, and retrieve
> configuration checks and other types of content required for post= ure
> assessment (see step 2 above).  A content repository is= expected to
> house specific versions of checklists (i.e. benchmarks), may be
> required to satisfy different use cases (i.e. asset inventory,
> configuration settings, or vulnerabilities).  In additi= on, content
> repositories are expected to store up-to-date dictionary of speci= fic
> enumerations, such as those used for configuration element identi= fiers,
asset classifications, vulnerability identifiers, and so on.
>
> This working group will achieve the following deliverables:
>
> - An Informational document on Use Cases
> - An Informational document on Requirements
> - An Informational document on SACM Architecture
> - A standards-track document specifying a protocol and data forma= t for
> retrieving configuration and policy information for driving data<= /div>
> collection and analysis
> - A standards-track document specifying a protocol and data forma= t for
> collecting actual endpoint posture
>
> The working group will create an overview of related standards wo= rk
> Internet-Draft which will document existing work in the IETF or i= n
> other SDOs which can be used as-is or as a starting point for
> developing solutions to the SACM requirements. The working group = may
> decide to make of this document an Informational RFC, but this is= not a
mandatory deliverable.
>
> The working group will work in close coordination with other WGs = in
> the IETF (including, but not limited to MILE and NEA) in order to=
> create solutions that do not overlap and can be used or re-used t= o
> meet the goals of more than one working group.
>
> In accordance with existing IETF processes, the group will commun= icate
> with and invite participation from other relevant standards bodie= s and
> regulatory organizations, and if necessary reuse existing liaison=
> relationships or request the establishment of new liaison relatio= nships.
>
> SACM-related efforts are largely aligned, and may overlap, with o= ther
> IETF (and non-IETF) standardization efforts.  There are= common "problems"
> found in SACM, that may be addressed by the work done in SNMP, IP= FIX,
> NETCONF, SYSLOG, NEA, MILE, and potentially others.  Of= particular
> interest to SACM is understanding and respecting the distinctions=
> between itself and NEA and MILE.
>
> One way the NEA protocols can be used is as the transport for dat= a
> collected on the endpoint to an external service or data reposito= ry
> for further analysis and action.  NEA may also serve th= e purpose of
> carrying data-collection instructions.
>
> The MILE data formats provide a format to describe incident,
> threat-related incident, and indicator information.  SA= CM data formats
> provide ways to understand what endpoints are in your environment= ,
> whether they meet policy requirements, and their current configur= ation
> state.  The data exchanged in MILE, supplementing the S= ACM data,
> creates enhanced situational awareness, thus enabling increased
> understanding of current threats and mitigations.
>
> After the work items in the current charter have been submitted t= o and
> approved by the IESG, the WG will recharter or close.
>
> Goals and Milestones
>
> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases<= /div>
>
> Oct. 2013 - Initial submission of an Internet-Draft on Requiremen= ts
> taking into consideration RFC5706 and RFC3535
>
> Oct. 2013 - Initial submission of an Internet-Draft on SACM
> Architecture
>
> Nov. 2013 - Initial submission of an Internet-Draft on overview o= f
> related standards work
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protoco= l and
> data format for retrieving configuration and policy information f= or
> driving data collection and analysis
>
> Jan. 2014 - Initial submission of an Internet-Draft for a protoco= l and
> data format for collecting actual endpoint posture
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use C= ases
> for consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on
> Requirements for consideration as Informational RFC
>
> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM<= /div>
> Architecture for consideration as Informational RFC
>
> Oct. 2014 - Submission to the IESG of the Internet-Draft for a
> protocol and data format for retrieving configuration and policy<= /div>
> information for driving data collection and analysis for consider= ation
> as standards-track RFC
>
> Oct. 2014 - Submission to the IESG of the Internet-Draft a protoc= ol
> and data format for collecting actual endpoint posture for
> consideration as standards- track RFC
>
> 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 attachment= s.
...

This message and attachments may contain confidential information.&nbs= p; If it appears that this message was sent to you by mistake, any ret= ention, dissemination, distribution or copying of this message and attachme= nts is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachme= nts.
_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF28F692MIVEXAMER1N1corpn_-- From david.waltermire@nist.gov Mon Jun 10 13:53:57 2013 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 DFBF121F995B for ; Mon, 10 Jun 2013 13:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.284 X-Spam-Level: X-Spam-Status: No, score=-5.284 tagged_above=-999 required=5 tests=[AWL=-0.439, 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 rVydzV1nmool for ; Mon, 10 Jun 2013 13:53:51 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8721F9631 for ; Mon, 10 Jun 2013 13:53:50 -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.3.123.3; Mon, 10 Jun 2013 16:53: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, 10 Jun 2013 16:53:49 -0400 From: "Waltermire, David A." To: "Kent_Landfield@McAfee.com" , "Adam.Montville@cisecurity.org" , "jfield@gopivotal.com" Date: Mon, 10 Jun 2013 16:53:48 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6xNalvQ89Okyx82eII/CXtpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAAFEIA//+uz4CAABJCcA== Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D66F4F64@CISEXCHANGE1.msisac.org.local> <3CBA099FBA0AB843895D72474092B8CF28F692@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF28F692@MIVEXAMER1N1.corp.nai.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_D7A0423E5E193F40BE6E94126930C4930C04839E87MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "Gunnar.Engelbach@threatguard.com" , "turners@ieca.com" , "adam@stoicsecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:53:58 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930C04839E87MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Kent's sentence is fine with me, although it is covered by the other text in the charter: "The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models." "There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others." Unless I am missing something, I think we have already said as much in the existing text. Dave From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 4:42 PM To: Adam.Montville@cisecurity.org; Waltermire, David A.; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text If the sentence is "Transports from MILE may be used by SACM." I have no problem with it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, June 10, 2013 3:32 PM To: David Waltermire >, John Field > Cc: Gunnar Engelbach >, Sean Turner >, "Adam W. Montville" >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text I think once we add the sentence Kathleen would like to see, we're probably good. Any objections to that? -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, June 10, 2013 12:20 PM To: Adam Montville; John Field Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org Subject: RE: [sacm] Updated Candidate Charter Text +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > David A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > last few sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are existing industry > standards, preferably IETF standards, that could support automation of > asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in > the IETF (including, but not limited to MILE and NEA) in order to > create solutions that do not overlap and can be used or re-used to > meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, > creates enhanced situational awareness, thus enabling increased > understanding of current threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol and data format for retrieving configuration and policy > information for driving data collection and analysis for consideration > as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and data format for collecting actual endpoint posture for > consideration as standards- track RFC > > 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. ... 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. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_D7A0423E5E193F40BE6E94126930C4930C04839E87MBCLUSTERxcha_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1 cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5LZW50JiM4MjE3O3Mgc2VudGVuY2UgaXMgZmluZSB3aXRoIG1lLCBhbHRo b3VnaCBpdCBpcyBjb3ZlcmVkIGJ5IHRoZSBvdGhlciB0ZXh0IGluIHRoZSBjaGFydGVyOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+JiM4MjIwO1RoZSB3b3JraW5nIGdyb3VwIHdpbGwsIHdoZW5ldmVyIHJl YXNvbmFibGUgYW5kIHBvc3NpYmxlLCByZXVzZSBleGlzdGluZyBwcm90b2NvbHMsIG1lY2hhbmlz bXMsIGluZm9ybWF0aW9uIGFuZCBkYXRhIG1vZGVscy4mIzgyMjE7PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiYjODIyMDtUaGVy ZSBhcmUgY29tbW9uICZxdW90O3Byb2JsZW1zJnF1b3Q7IGZvdW5kIGluIFNBQ00sIHRoYXQgbWF5 IGJlIGFkZHJlc3NlZCBieSB0aGUgd29yayBkb25lIGluIFNOTVAsIElQRklYLCBORVRDT05GLCBT WVNMT0csIE5FQSwgTUlMRSwgYW5kIHBvdGVudGlhbGx5IG90aGVycy4mIzgyMjE7PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5Vbmxlc3MgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgSSB0aGluayB3ZSBoYXZl IGFscmVhZHkgc2FpZCBhcyBtdWNoIGluIHRoZSBleGlzdGluZyB0ZXh0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBLZW50X0xhbmRmaWVsZEBNY0FmZWUu Y29tIFttYWlsdG86S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBN b25kYXksIEp1bmUgMTAsIDIwMTMgNDo0MiBQTTxicj48Yj5Ubzo8L2I+IEFkYW0uTW9udHZpbGxl QGNpc2VjdXJpdHkub3JnOyBXYWx0ZXJtaXJlLCBEYXZpZCBBLjsgamZpZWxkQGdvcGl2b3RhbC5j b208YnI+PGI+Q2M6PC9iPiBHdW5uYXIuRW5nZWxiYWNoQHRocmVhdGd1YXJkLmNvbTsgdHVybmVy c0BpZWNhLmNvbTsgYWRhbUBzdG9pY3NlY3VyaXR5LmNvbTsgc2FjbUBpZXRmLm9yZzxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBVcGRhdGVkIENhbmRpZGF0ZSBDaGFydGVyIFRleHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6Q29uc29sYXMnPklmIHRoZSBzZW50ZW5jZSBpcyAmcXVvdDtUcmFuc3Bv cnRzIGZyb20gTUlMRSBtYXkgYmUgdXNlZCBieSBTQUNNLiZxdW90OyZuYnNwO0kmbmJzcDtoYXZl IG5vJm5ic3A7cHJvYmxlbSZuYnNwO3dpdGggaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjA2QTcxJz5LZW50IExhbmRm aWVsZDwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPjxicj48YnI+PHN0cm9uZz48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPk1jQWZlZSB8IEFu IEludGVsIENvbXBhbnk8L3NwYW4+PC9zdHJvbmc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxl LXNwYW4+RGlyZWN0OiArMS45NzIuOTYzLjcwOTYmbmJzcDs8L3NwYW4+PGJyPjxzcGFuIGNsYXNz PWFwcGxlLXN0eWxlLXNwYW4+TW9iaWxlOiArMS44MTcuNjM3LjgwMjY8L3NwYW4+PGJyPjxzdHJv bmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5XZWI6Jm5i c3A7PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PGEgaHJlZj0i aHR0cDovL3d3dy5tY2FmZWUuY29tLyI+d3d3Lm1jYWZlZS5jb208L2E+PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp bic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+QWRhbSBNb250dmlsbGUgJmx0OzxhIGhyZWY9Im1h aWx0bzpBZGFtLk1vbnR2aWxsZUBjaXNlY3VyaXR5Lm9yZyI+QWRhbS5Nb250dmlsbGVAY2lzZWN1 cml0eS5vcmc8L2E+Jmd0Ozxicj48Yj5EYXRlOiA8L2I+TW9uZGF5LCBKdW5lIDEwLCAyMDEzIDM6 MzIgUE08YnI+PGI+VG86IDwvYj5EYXZpZCBXYWx0ZXJtaXJlICZsdDs8YSBocmVmPSJtYWlsdG86 ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiI+ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjwvYT4m Z3Q7LCBKb2huIEZpZWxkICZsdDs8YSBocmVmPSJtYWlsdG86amZpZWxkQGdvcGl2b3RhbC5jb20i PmpmaWVsZEBnb3Bpdm90YWwuY29tPC9hPiZndDs8YnI+PGI+Q2M6IDwvYj5HdW5uYXIgRW5nZWxi YWNoICZsdDs8YSBocmVmPSJtYWlsdG86Z3VubmFyLmVuZ2VsYmFjaEB0aHJlYXRndWFyZC5jb20i Pmd1bm5hci5lbmdlbGJhY2hAdGhyZWF0Z3VhcmQuY29tPC9hPiZndDssIFNlYW4gVHVybmVyICZs dDs8YSBocmVmPSJtYWlsdG86dHVybmVyc0BpZWNhLmNvbSI+dHVybmVyc0BpZWNhLmNvbTwvYT4m Z3Q7LCAmcXVvdDtBZGFtIFcuIE1vbnR2aWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFk YW1Ac3RvaWNzZWN1cml0eS5jb20iPmFkYW1Ac3RvaWNzZWN1cml0eS5jb208L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPjxiPlN1YmplY3Q6IDwvYj5SZTogW3NhY21dIFVwZGF0ZWQgQ2FuZGlkYXRlIENoYXJ0ZXIg VGV4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRE RiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tcmlnaHQ6MGluJyBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ SSB0aGluayBvbmNlIHdlIGFkZCB0aGUgc2VudGVuY2UgS2F0aGxlZW4gd291bGQgbGlrZSB0byBz ZWUsIHdlJ3JlIHByb2JhYmx5IGdvb2QuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+QW55IG9iamVjdGlvbnMgdG8gdGhhdD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbicgaWQ9Ik1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5Gcm9tOiBXYWx0ZXJtaXJlLCBEYXZpZCBBLiBbPGEgaHJlZj0ibWFpbHRv OmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3YiPm1haWx0bzpkYXZpZC53YWx0ZXJtaXJlQG5pc3Qu Z292PC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TZW50OiBNb25kYXksIEp1bmUgMTAsIDIwMTMg MTI6MjAgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbzogQWRhbSBNb250dmlsbGU7IEpvaG4gRmll bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5DYzogU2VhbiBUdXJuZXI7IEd1bm5hciBFbmdlbGJhY2g7 IEFkYW0gVy4gTW9udHZpbGxlOyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TdWJqZWN0OiBSRTogW3NhY21dIFVwZGF0 ZWQgQ2FuZGlkYXRlIENoYXJ0ZXIgVGV4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPisxIGZvciBtZS4m bmJzcDsmbmJzcDtBcmUgd2UgZ29vZCB3aXRoIGhhbmRpbmcgdGhpcyBvZmYgdG8gU2VhbiB0b2Rh eT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TaW5jZXJlbHksPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RGF2 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IEZyb206IEFkYW0gTW9udHZpbGxlIFs8YSBocmVmPSJtYWls dG86QWRhbS5Nb250dmlsbGVAY2lzZWN1cml0eS5vcmciPm1haWx0bzpBZGFtLk1vbnR2aWxsZUBj aXNlY3VyaXR5Lm9yZzwvYT5dPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBTZW50OiBGcmlkYXks IEp1bmUgMDcsIDIwMTMgNjozNiBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgVG86IEpvaG4g RmllbGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IENjOiBTZWFuIFR1cm5lcjsgR3VubmFyIEVu Z2VsYmFjaDsgQWRhbSBXLiBNb250dmlsbGU7IFdhbHRlcm1pcmUsPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jmd0OyBEYXZpZCBBLjsgPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0 Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBTdWJqZWN0OiBSRTogW3NhY21dIFVw ZGF0ZWQgQ2FuZGlkYXRlIENoYXJ0ZXIgVGV4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IFRoYW5rcyBKb2huLiZuYnNwOyZuYnNwO0kndmUg bW9kaWZpZWQgdGhlICZxdW90O1JPTElFIHBhcmFncmFwaCZxdW90OyBieSB0cnVuY2F0aW5nIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgbGFzdCBmZXcgc2VudGVuY2VzLiZuYnNwOyZuYnNw O0Fsc28sIGNoYW5nZWQgQm9vbGVhbiB0byBwcmVkaWNhdGUuPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgQXJlIHRoZXJlIGFueSBmdXJ0aGVy IG5pdHMgb3IgcmVhbGx5IGJhZCBvdmVyc2lnaHRzIGluIHRoaXMgY29weSBvZiB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5jaGFydGVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IElmIHlvdSBsaWtlIGl0IGFzIGl0IHN0YW5kcywgKzEgaXQu PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsg Rm9yIG1lLCArMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IFNl Y3VyaW5nIGluZm9ybWF0aW9uIGFuZCB0aGUgc3lzdGVtcyB0aGF0IHN0b3JlLCBwcm9jZXNzLCBh bmQgdHJhbnNtaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHRoYXQgaW5mb3JtYXRpb24gaXMg YSBjaGFsbGVuZ2luZyB0YXNrIGZvciBvcmdhbml6YXRpb25zIG9mIGFsbCBzaXplcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mZ3Q7IGFuZCBtYW55IHNlY3VyaXR5IHByYWN0aXRpb25lcnMgc3BlbmQg bXVjaCBvZiB0aGVpciB0aW1lIG9uIG1hbnVhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnByb2Nlc3Nl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IFN0YW5kYXJkaXplZCBwcm9jZXNzZXMgdG8gY29s bGVjdCwgdmVyaWZ5LCBhbmQgdXBkYXRlIHNlY3VyaXR5IHN5c3RlbTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZndDsgY29uZmlndXJhdGlvbnMgd291bGQgYWxsb3cgZWFzaWVyIGF1dG9tYXRpb24gb2Yg dGhlIHByb2Nlc3Nlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IEF1dG9tYXRpbmcgdGhlc2Ug cm91dGluZSB0YXNrcyB3b3VsZCBmcmVlIHNlY3VyaXR5IHByYWN0aXRpb25lcnMgdG88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mZ3Q7IGZvY3VzIG9uIGhpZ2ggcHJpb3JpdHkgdGFza3MsIGFuZCBzaG91 bGQgaW1wcm92ZSBvcGVyYXRvcnMnIGFiaWxpdHkgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7 IHByaW9yaXRpemUgcmlzayBiYXNlZCBvbiB0aW1lbHkgaW5mb3JtYXRpb24gYWJvdXQgdGhyZWF0 cyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHZ1bG5lcmFiaWxpdGllcy4gVGhpcyB3b3Jr aW5nIGdyb3VwIHdpbGwgZGVmaW5lIHNlY3VyaXR5IGF1dG9tYXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mZ3Q7IHByb3RvY29scyBhbmQgZGF0YSBmb3JtYXQgc3RhbmRhcmRzIGluIHN1cHBvcnQg b2YgaW5mb3JtYXRpb24gc2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHByb2Nlc3Nl cyBhbmQgcHJhY3RpY2VzLiBUaGVzZSBzdGFuZGFyZHMgd2lsbCBoZWxwIHNlY3VyaXR5PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jmd0OyBwcmFjdGl0aW9uZXJzIHRvIGJlIG1vcmUgZWZmZWN0aXZlIGJ5 IGF1dG9tYXRpbmcgcm91dGluZSB0YXNrcyByZWxhdGVkPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0 OyB0byBjbGllbnQgYW5kIHNlcnZlciBzZWN1cml0eSwgZnJlZWluZyB0aGVtIHRvIGZvY3VzIG9u IG1vcmUgYWR2YW5jZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHRhc2tzLiBUaGUgaW5pdGlh bCBmb2N1cyBvZiB0aGlzIHdvcmsgaXMgdG8gYWRkcmVzcyBlbnRlcnByaXNlIHVzZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZndDsgY2FzZXMgcGVydGFpbmluZyB0byB0aGUgYXNzZXNzbWVudCBvZiBl bmRwb2ludCBwb3N0dXJlICh1c2luZyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5kZWZpbml0aW9u cyBvZiBFbmRwb2ludCBhbmQgUG9zdHVyZSBmcm9tIFJGQyA1MjA5KS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBUaGUgd29ya2luZyBncm91 cCB3aWxsLCB3aGVuZXZlciByZWFzb25hYmxlIGFuZCBwb3NzaWJsZSwgcmV1c2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mZ3Q7IGV4aXN0aW5nIHByb3RvY29scywgbWVjaGFuaXNtcywgaW5mb3JtYXRp b24gYW5kIGRhdGEgbW9kZWxzLiBPZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgcGFydGljdWxh ciBpbnRlcmVzdCB0byB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIGV4aXN0aW5nIGluZHVzdHJ5PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBzdGFuZGFyZHMsIHByZWZlcmFibHkgSUVURiBzdGFuZGFy ZHMsIHRoYXQgY291bGQgc3VwcG9ydCBhdXRvbWF0aW9uIG9mPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jmd0OyBhc3NldCwgY2hhbmdlLCBjb25maWd1cmF0aW9uLCBhbmQgdnVsbmVyYWJpbGl0eSBtYW5h Z2VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mZ3Q7IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGVmaW5lOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IDEuIEEgc2V0IG9mIHN0YW5kYXJk cyB0byBlbmFibGUgYXNzZXNzbWVudCBvZiBlbmRwb2ludCBwb3N0dXJlLiBUaGlzPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jmd0OyBhcmVhIG9mIGZvY3VzIHByb3ZpZGVzIGZvciBuZWNlc3NhcnkgbGFu Z3VhZ2UgYW5kIGRhdGEgZm9ybWF0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+c3BlY2lmaWNhdGlvbnMu PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsg Mi4gQSBzZXQgb2Ygc3RhbmRhcmRzIGZvciBpbnRlcmFjdGluZyB3aXRoIHJlcG9zaXRvcmllcyBv ZiBjb250ZW50PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyByZWxhdGVkIHRvIGFzc2Vzc21lbnQg b2YgZW5kcG9pbnQgcG9zdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jmd0OyBBc3Nlc3NtZW50IG9mIGVuZHBvaW50IHBvc3R1cmUgYXNzZXNz bWVudCBlbnRhaWxzIHRoZSBmb2xsb3dpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGdlbmVy YWwgc3RlcHMsIHdoaWNoIGFjY29tbW9kYXRlIHBvbGljeS1kcml2ZW4gYW5kIGFzc2V0LWRyaXZl bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPmFzc2Vzc21lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgMS4gSWRlbnRpZnkgZW5kcG9pbnRzPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgMi4g RGV0ZXJtaW5lIHNwZWNpZmljIGVuZHBvaW50IGVsZW1lbnRzIHRvIGFzc2VzczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IDMuIENvbGxlY3Qg YWN0dWFsIHZhbHVlIG9mIGVsZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZndDsgNC4gQ29tcGFyZSBhY3R1YWwgZWxlbWVudCB2YWx1ZXMg dG8gZXhwZWN0ZWQgZWxlbWVudCB2YWx1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyA1LiBSZXBvcnQgcmVzdWx0czxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IFRoaXMgYXBwcm9hY2gg dG8gZW5kcG9pbnQgcG9zdHVyZSBjb2xsZWN0aW9uIGVuYWJsZXMgbXVsdGlwbGUgcG9saWNpZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHRvIGJlIGV2YWx1YXRlZCBiYXNlZCBvbiBhIHNpbmds ZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkuIFBvbGljaWVzPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jmd0OyB3aWxsIGJlIGV2YWx1YXRlZCBieSBjb21wYXJpbmcgYXZhaWxhYmxlIGVuZHBvaW50IHBv c3R1cmUgZGF0YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgYWNjb3JkaW5nIHRvIHJ1bGVzIGV4 cHJlc3NlZCBpbiB0aGUgcG9saWN5LiBUeXBpY2FsbHksIHRoZXNlIHJ1bGVzPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jmd0OyB3aWxsIGNvbXBhcmUgdGhlIGFjdHVhbCB2YWx1ZSBhZ2FpbnN0IGFuIGV4 cGVjdGVkIHZhbHVlIG9yIHJhbmdlIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgc3BlY2lm aWMgcG9zdHVyZSBlbGVtZW50cy4gSW4gc29tZSBjYXNlcywgdGhlIHBvc3R1cmUgZWxlbWVudCBt YXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHBlcnRhaW4gdG8gc29mdHdhcmUgaW5zdGFsbGF0 aW9uIHN0YXRlLCBpbiB3aGljaCBjYXNlIHRoZSBhY3R1YWwgYW5kPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jmd0OyBleHBlY3RlZCB2YWx1ZXMgbWF5IGJlICZxdW90O2luc3RhbGxlZCZxdW90OyBvciAm cXVvdDtub3QgaW5zdGFsbGVkLiZxdW90OyBFdmFsdWF0aW9uIG9mIG11bHRpcGxlPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+cG9zdHVyZSBlbGVtZW50cyBtYXkgYmUgY29tYmluZWQgdXNpbmcgcHJlZGlj YXRlIGxvZ2ljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mZ3Q7IFJlcG9zaXRvcnkgcHJvdG9jb2xzIGFyZSBuZWVkZWQgdG8gc3RvcmUsIHVwZGF0 ZSwgYW5kIHJldHJpZXZlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBjb25maWd1cmF0aW9uIGNo ZWNrcyBhbmQgb3RoZXIgdHlwZXMgb2YgY29udGVudCByZXF1aXJlZCBmb3IgcG9zdHVyZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZndDsgYXNzZXNzbWVudCAoc2VlIHN0ZXAgMiBhYm92ZSkuJm5ic3A7 Jm5ic3A7QSBjb250ZW50IHJlcG9zaXRvcnkgaXMgZXhwZWN0ZWQgdG88bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mZ3Q7IGhvdXNlIHNwZWNpZmljIHZlcnNpb25zIG9mIGNoZWNrbGlzdHMgKGkuZS4gYmVu Y2htYXJrcyksIG1heSBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgcmVxdWlyZWQgdG8gc2F0 aXNmeSBkaWZmZXJlbnQgdXNlIGNhc2VzIChpLmUuIGFzc2V0IGludmVudG9yeSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mZ3Q7IGNvbmZpZ3VyYXRpb24gc2V0dGluZ3MsIG9yIHZ1bG5lcmFiaWxpdGll cykuJm5ic3A7Jm5ic3A7SW4gYWRkaXRpb24sIGNvbnRlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m Z3Q7IHJlcG9zaXRvcmllcyBhcmUgZXhwZWN0ZWQgdG8gc3RvcmUgdXAtdG8tZGF0ZSBkaWN0aW9u YXJ5IG9mIHNwZWNpZmljPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBlbnVtZXJhdGlvbnMsIHN1 Y2ggYXMgdGhvc2UgdXNlZCBmb3IgY29uZmlndXJhdGlvbiBlbGVtZW50IGlkZW50aWZpZXJzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPmFzc2V0IGNsYXNzaWZpY2F0aW9ucywgdnVsbmVyYWJpbGl0eSBp ZGVudGlmaWVycywgYW5kIHNvIG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IFRoaXMgd29ya2luZyBncm91cCB3aWxsIGFjaGlldmUgdGhl IGZvbGxvd2luZyBkZWxpdmVyYWJsZXM6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZndDsgLSBBbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IG9uIFVz ZSBDYXNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgLSBBbiBJbmZvcm1hdGlvbmFsIGRvY3Vt ZW50IG9uIFJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgLSBBbiBJbmZvcm1h dGlvbmFsIGRvY3VtZW50IG9uIFNBQ00gQXJjaGl0ZWN0dXJlPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jmd0OyAtIEEgc3RhbmRhcmRzLXRyYWNrIGRvY3VtZW50IHNwZWNpZnlpbmcgYSBwcm90b2NvbCBh bmQgZGF0YSBmb3JtYXQgZm9yPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyByZXRyaWV2aW5nIGNv bmZpZ3VyYXRpb24gYW5kIHBvbGljeSBpbmZvcm1hdGlvbiBmb3IgZHJpdmluZyBkYXRhPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jmd0OyBjb2xsZWN0aW9uIGFuZCBhbmFseXNpczxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZndDsgLSBBIHN0YW5kYXJkcy10cmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIGEgcHJv dG9jb2wgYW5kIGRhdGEgZm9ybWF0IGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgY29sbGVj dGluZyBhY3R1YWwgZW5kcG9pbnQgcG9zdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY3JlYXRl IGFuIG92ZXJ2aWV3IG9mIHJlbGF0ZWQgc3RhbmRhcmRzIHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mZ3Q7IEludGVybmV0LURyYWZ0IHdoaWNoIHdpbGwgZG9jdW1lbnQgZXhpc3Rpbmcgd29yayBp biB0aGUgSUVURiBvciBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgb3RoZXIgU0RPcyB3aGlj aCBjYW4gYmUgdXNlZCBhcy1pcyBvciBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZndDsgZGV2ZWxvcGluZyBzb2x1dGlvbnMgdG8gdGhlIFNBQ00gcmVxdWlyZW1l bnRzLiBUaGUgd29ya2luZyBncm91cCBtYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGRlY2lk ZSB0byBtYWtlIG9mIHRoaXMgZG9jdW1lbnQgYW4gSW5mb3JtYXRpb25hbCBSRkMsIGJ1dCB0aGlz IGlzIG5vdCBhPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+bWFuZGF0b3J5IGRlbGl2ZXJhYmxlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IFRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgd29yayBpbiBjbG9zZSBjb29yZGluYXRpb24gd2l0aCBvdGhlciBX R3MgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHRoZSBJRVRGIChpbmNsdWRpbmcsIGJ1dCBu b3QgbGltaXRlZCB0byBNSUxFIGFuZCBORUEpIGluIG9yZGVyIHRvPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jmd0OyBjcmVhdGUgc29sdXRpb25zIHRoYXQgZG8gbm90IG92ZXJsYXAgYW5kIGNhbiBiZSB1 c2VkIG9yIHJlLXVzZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IG1lZXQgdGhlIGdvYWxz IG9mIG1vcmUgdGhhbiBvbmUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBJbiBhY2NvcmRhbmNlIHdpdGggZXhpc3Rp bmcgSUVURiBwcm9jZXNzZXMsIHRoZSBncm91cCB3aWxsIGNvbW11bmljYXRlPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jmd0OyB3aXRoIGFuZCBpbnZpdGUgcGFydGljaXBhdGlvbiBmcm9tIG90aGVyIHJl bGV2YW50IHN0YW5kYXJkcyBib2RpZXMgYW5kPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyByZWd1 bGF0b3J5IG9yZ2FuaXphdGlvbnMsIGFuZCBpZiBuZWNlc3NhcnkgcmV1c2UgZXhpc3RpbmcgbGlh aXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgcmVsYXRpb25zaGlwcyBvciByZXF1ZXN0IHRo ZSBlc3RhYmxpc2htZW50IG9mIG5ldyBsaWFpc29uIHJlbGF0aW9uc2hpcHMuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgU0FDTS1yZWxhdGVk IGVmZm9ydHMgYXJlIGxhcmdlbHkgYWxpZ25lZCwgYW5kIG1heSBvdmVybGFwLCB3aXRoIG90aGVy PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBJRVRGIChhbmQgbm9uLUlFVEYpIHN0YW5kYXJkaXph dGlvbiBlZmZvcnRzLiZuYnNwOyZuYnNwO1RoZXJlIGFyZSBjb21tb24gJnF1b3Q7cHJvYmxlbXMm cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGZvdW5kIGluIFNBQ00sIHRoYXQgbWF5IGJl IGFkZHJlc3NlZCBieSB0aGUgd29yayBkb25lIGluIFNOTVAsIElQRklYLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZndDsgTkVUQ09ORiwgU1lTTE9HLCBORUEsIE1JTEUsIGFuZCBwb3RlbnRpYWxseSBv dGhlcnMuJm5ic3A7Jm5ic3A7T2YgcGFydGljdWxhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsg aW50ZXJlc3QgdG8gU0FDTSBpcyB1bmRlcnN0YW5kaW5nIGFuZCByZXNwZWN0aW5nIHRoZSBkaXN0 aW5jdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGJldHdlZW4gaXRzZWxmIGFuZCBORUEg YW5kIE1JTEUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZndDsgT25lIHdheSB0aGUgTkVBIHByb3RvY29scyBjYW4gYmUgdXNlZCBpcyBhcyB0aGUg dHJhbnNwb3J0IGZvciBkYXRhPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBjb2xsZWN0ZWQgb24g dGhlIGVuZHBvaW50IHRvIGFuIGV4dGVybmFsIHNlcnZpY2Ugb3IgZGF0YSByZXBvc2l0b3J5PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBmb3IgZnVydGhlciBhbmFseXNpcyBhbmQgYWN0aW9uLiZu YnNwOyZuYnNwO05FQSBtYXkgYWxzbyBzZXJ2ZSB0aGUgcHVycG9zZSBvZjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZndDsgY2FycnlpbmcgZGF0YS1jb2xsZWN0aW9uIGluc3RydWN0aW9ucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBUaGUgTUlM RSBkYXRhIGZvcm1hdHMgcHJvdmlkZSBhIGZvcm1hdCB0byBkZXNjcmliZSBpbmNpZGVudCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHRocmVhdC1yZWxhdGVkIGluY2lkZW50LCBhbmQgaW5kaWNh dG9yIGluZm9ybWF0aW9uLiZuYnNwOyZuYnNwO1NBQ00gZGF0YSBmb3JtYXRzPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jmd0OyBwcm92aWRlIHdheXMgdG8gdW5kZXJzdGFuZCB3aGF0IGVuZHBvaW50cyBh cmUgaW4geW91ciBlbnZpcm9ubWVudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHdoZXRoZXIg dGhleSBtZWV0IHBvbGljeSByZXF1aXJlbWVudHMsIGFuZCB0aGVpciBjdXJyZW50IGNvbmZpZ3Vy YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHN0YXRlLiZuYnNwOyZuYnNwO1RoZSBkYXRh IGV4Y2hhbmdlZCBpbiBNSUxFLCBzdXBwbGVtZW50aW5nIHRoZSBTQUNNIGRhdGEsPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jmd0OyBjcmVhdGVzIGVuaGFuY2VkIHNpdHVhdGlvbmFsIGF3YXJlbmVzcywg dGh1cyBlbmFibGluZyBpbmNyZWFzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHVuZGVyc3Rh bmRpbmcgb2YgY3VycmVudCB0aHJlYXRzIGFuZCBtaXRpZ2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBBZnRlciB0aGUgd29yayBp dGVtcyBpbiB0aGUgY3VycmVudCBjaGFydGVyIGhhdmUgYmVlbiBzdWJtaXR0ZWQgdG8gYW5kPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBhcHByb3ZlZCBieSB0aGUgSUVTRywgdGhlIFdHIHdpbGwg cmVjaGFydGVyIG9yIGNsb3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mZ3Q7IEdvYWxzIGFuZCBNaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgU2VwLiAyMDEzIC0gSW5pdGlh bCBzdWJtaXNzaW9uIG9mIGFuIEludGVybmV0LURyYWZ0IG9uIFVzZSBDYXNlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IE9jdC4gMjAxMyAt IEluaXRpYWwgc3VibWlzc2lvbiBvZiBhbiBJbnRlcm5ldC1EcmFmdCBvbiBSZXF1aXJlbWVudHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHRha2luZyBpbnRvIGNvbnNpZGVyYXRpb24gUkZDNTcw NiBhbmQgUkZDMzUzNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mZ3Q7IE9jdC4gMjAxMyAtIEluaXRpYWwgc3VibWlzc2lvbiBvZiBhbiBJbnRlcm5l dC1EcmFmdCBvbiBTQUNNPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBBcmNoaXRlY3R1cmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBOb3Yu IDIwMTMgLSBJbml0aWFsIHN1Ym1pc3Npb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgb24gb3ZlcnZp ZXcgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IHJlbGF0ZWQgc3RhbmRhcmRzIHdvcms8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBKYW4u IDIwMTQgLSBJbml0aWFsIHN1Ym1pc3Npb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgZm9yIGEgcHJv dG9jb2wgYW5kPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBkYXRhIGZvcm1hdCBmb3IgcmV0cmll dmluZyBjb25maWd1cmF0aW9uIGFuZCBwb2xpY3kgaW5mb3JtYXRpb24gZm9yPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jmd0OyBkcml2aW5nIGRhdGEgY29sbGVjdGlvbiBhbmQgYW5hbHlzaXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBKYW4uIDIw MTQgLSBJbml0aWFsIHN1Ym1pc3Npb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgZm9yIGEgcHJvdG9j b2wgYW5kPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBkYXRhIGZvcm1hdCBmb3IgY29sbGVjdGlu ZyBhY3R1YWwgZW5kcG9pbnQgcG9zdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IEFwci4gMjAxNCAtIFN1Ym1pc3Npb24gdG8gdGhlIElF U0cgb2YgdGhlIEludGVybmV0LURyYWZ0IG9uIFVzZSBDYXNlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZndDsgZm9yIGNvbnNpZGVyYXRpb24gYXMgSW5mb3JtYXRpb25hbCBSRkM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBBcHIuIDIwMTQgLSBT dWJtaXNzaW9uIHRvIHRoZSBJRVNHIG9mIHRoZSBJbnRlcm5ldC1EcmFmdCBvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZndDsgUmVxdWlyZW1lbnRzIGZvciBjb25zaWRlcmF0aW9uIGFzIEluZm9ybWF0 aW9uYWwgUkZDPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZndDsgQXByLiAyMDE0IC0gU3VibWlzc2lvbiB0byB0aGUgSUVTRyBvZiB0aGUgSW50ZXJu ZXQtRHJhZnQgb24gU0FDTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgQXJjaGl0ZWN0dXJlIGZv ciBjb25zaWRlcmF0aW9uIGFzIEluZm9ybWF0aW9uYWwgUkZDPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgT2N0LiAyMDE0IC0gU3VibWlzc2lv biB0byB0aGUgSUVTRyBvZiB0aGUgSW50ZXJuZXQtRHJhZnQgZm9yIGE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mZ3Q7IHByb3RvY29sIGFuZCBkYXRhIGZvcm1hdCBmb3IgcmV0cmlldmluZyBjb25maWd1 cmF0aW9uIGFuZCBwb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGluZm9ybWF0aW9uIGZv ciBkcml2aW5nIGRhdGEgY29sbGVjdGlvbiBhbmQgYW5hbHlzaXMgZm9yIGNvbnNpZGVyYXRpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGFzIHN0YW5kYXJkcy10cmFjayBSRkM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBPY3QuIDIwMTQg LSBTdWJtaXNzaW9uIHRvIHRoZSBJRVNHIG9mIHRoZSBJbnRlcm5ldC1EcmFmdCBhIHByb3RvY29s PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBhbmQgZGF0YSBmb3JtYXQgZm9yIGNvbGxlY3Rpbmcg YWN0dWFsIGVuZHBvaW50IHBvc3R1cmUgZm9yPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBjb25z aWRlcmF0aW9uIGFzIHN0YW5kYXJkcy0gdHJhY2sgUkZDPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgVGhpcyBtZXNzYWdlIGFuZCBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uJm5ic3A7Jm5ic3A7SWY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGl0IGFwcGVhcnMgdGhhdCB0aGlzIG1lc3NhZ2Ugd2Fz IHNlbnQgdG8geW91IGJ5IG1pc3Rha2UsIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgcmV0 ZW50aW9uLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIG1l c3NhZ2UgYW5kPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmd0OyBhdHRhY2htZW50cyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiZuYnNwOyZuYnNwO1BsZWFzZSBub3RpZnkgdGhlIHNlbmRlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZndDsgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUg bWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPi4uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5U aGlzIG1lc3NhZ2UgYW5kIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbi4mbmJzcDsmbmJzcDtJZiBpdCBhcHBlYXJzIHRoYXQgdGhpcyBtZXNzYWdlIHdhcyBz ZW50IHRvIHlvdSBieSBtaXN0YWtlLCBhbnkgcmV0ZW50aW9uLCBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIG1lc3NhZ2UgYW5kIGF0dGFjaG1lbnRzIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7Jm5ic3A7UGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnNhY20gbWFpbGluZyBsaXN0 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21A aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930C04839E87MBCLUSTERxcha_-- From Kent_Landfield@mcafee.com Mon Jun 10 13:59:53 2013 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 1A55B21E80A3 for ; Mon, 10 Jun 2013 13:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViD1RgTyb5ed for ; Mon, 10 Jun 2013 13:59:48 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1D27721E80A7 for ; Mon, 10 Jun 2013 13:59:45 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 7a6e_968d_22dd1a07_a9a9_42cd_93cb_c23a81598bf7; Mon, 10 Jun 2013 15:59:30 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER1N2.corp.nai.org ([169.254.3.103]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 16:58:42 -0400 From: To: , , Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6xNalvQ89Okyx82eII/CXtpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAAFEIA//+uz4CAABJCcP//8lkA Date: Mon, 10 Jun 2013 20:58:41 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF28FA5D@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF28FA5DMIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: Gunnar.Engelbach@threatguard.com, turners@ieca.com, adam@stoicsecurity.com, sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:59:53 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF28FA5DMIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think that was the sentence Kathleen said she wanted. Just wanted to ver= ify=85 I agree it is already covered but if it is a bit more useful by bei= ng called out directly, I am ok with that too. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Monday, June 10, 2013 3:53 PM To: Kent Landfield >, "Adam.Montville@cisecurity.org= " >, "j= field@gopivotal.com" > Cc: Gunnar Engelbach >, Sean Turner >, "adam@stoicsecurity.com" >, "sacm@ietf.org" > Subject: RE: [sacm] Updated Candidate Charter Text Kent=92s sentence is fine with me, although it is covered by the other text= in the charter: =93The working group will, whenever reasonable and possible, reuse existing= protocols, mechanisms, information and data models.=94 =93There are common "problems" found in SACM, that may be addressed by the = work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially other= s.=94 Unless I am missing something, I think we have already said as much in the = existing text. Dave From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 4:42 PM To: Adam.Montville@cisecurity.org; Wa= ltermire, David A.; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text If the sentence is "Transports from MILE may be used by SACM." I have no pr= oblem with it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, June 10, 2013 3:32 PM To: David Waltermire >, John Field > Cc: Gunnar Engelbach >, Sean Turner >, "Adam W. Montville" >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text I think once we add the sentence Kathleen would like to see, we're probably= good. Any objections to that? -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, June 10, 2013 12:20 PM To: Adam Montville; John Field Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org Subject: RE: [sacm] Updated Candidate Charter Text +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > David A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > last few sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are existing industry > standards, preferably IETF standards, that could support automation of > asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of mult= iple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in > the IETF (including, but not limited to MILE and NEA) in order to > create solutions that do not overlap and can be used or re-used to > meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, > creates enhanced situational awareness, thus enabling increased > understanding of current threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol and data format for retrieving configuration and policy > information for driving data collection and analysis for consideration > as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and data format for collecting actual endpoint posture for > consideration as standards- track RFC > > 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. ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF28FA5DMIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I think that was the sentence Kathleen said she wanted.  Just wan= ted to verify=85  I agree it is already covered but if it is a bit mor= e useful by being called out directly, I am ok with that too.

Kent Landfield

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

From: <Waltermire>, David Wal= termire <david.waltermire@n= ist.gov>
Date: Monday, June 10, 2013 3:53 PM=
To: Kent Landfield <Kent_Landfield@McAfee.com>, "<= a href=3D"mailto:Adam.Montville@cisecurity.org">Adam.Montville@cisecurity.o= rg" <Adam.Mont= ville@cisecurity.org>, "jfield@gopivotal.com&quo= t; <jfield@gopivotal.com>=
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com<= /a>>, Sean Turner <turners@ieca.c= om>, "adam@stoicsecur= ity.com" <adam@stoicsecurity.com&g= t;, "sacm@ietf.org" <sacm@ietf.org>
Subject: RE: [sacm] Updated Candida= te Charter Text

Kent=92s sentence is fine with me,= although it is covered by the other text in the charter:=

 

=93The working group will, wheneve= r reasonable and possible, reuse existing protocols, mechanisms, informatio= n and data models.=94

=93There are common "problems= " found in SACM, that may be addressed by the work done in SNMP, IPFIX= , NETCONF, SYSLOG, NEA, MILE, and potentially others.=94<= /p>

 

Unless I am missing something, I t= hink we have already said as much in the existing text.

 

Dave

 

 

 

 

 =

From: Adam Montville <Adam.Montville@cisecurity.org>
Date: Monday, June 10, 2013 3:32 PM
To: David Waltermire <david.waltermire@nist.gov>, John Field <jfield@gopivotal.com>
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com>, Sean Turner <turners@ieca.com>, "Adam W. Montvi= lle" <adam@stoicsecurity.= com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Updated Candidate Charter Text=

 =

I think once we add the = sentence Kathleen would like to see, we're probably good.=

 =

Any objections to that?<= o:p>

 =

-----Original Message---= --

From: Waltermire, David = A. [mailto:david.waltermire@ni= st.gov]

Sent: Monday, June 10, 2= 013 12:20 PM

To: Adam Montville; John= Field

Cc: Sean Turner; Gunnar = Engelbach; Adam W. Montville; sacm@ietf.org

Subject: RE: [sacm] Upda= ted Candidate Charter Text

+1 for me. &nbs= p;Are we good with handing this off to Sean today?

Sincerely,

Dave

> -----Original Messa= ge-----

> From: Adam Montvill= e [mailto:Adam.Montville@c= isecurity.org]

> Sent: Friday, June = 07, 2013 6:36 PM

> To: John Field=

> Cc: Sean Turner; Gu= nnar Engelbach; Adam W. Montville; Waltermire,

> David A.; sacm@ietf.org

> Subject: RE: [sacm]= Updated Candidate Charter Text

> 

> Thanks John. &= nbsp;I've modified the "ROLIE paragraph" by truncating the

> last few sentences.=   Also, changed Boolean to predicate.

> 

> Are there any furth= er nits or really bad oversights in this copy of the

charter?

> 

> If you like it as i= t stands, +1 it.

> 

> For me, +1=

> 

> -------------------= --------------------------

> 

> Securing informatio= n and the systems that store, process, and transmit

> that information is= a challenging task for organizations of all sizes,

> and many security p= ractitioners spend much of their time on manual

processes.

> Standardized proces= ses to collect, verify, and update security system

> configurations woul= d allow easier automation of the processes.

> Automating these ro= utine tasks would free security practitioners to

> focus on high prior= ity tasks, and should improve operators' ability to

> prioritize risk bas= ed on timely information about threats and

> vulnerabilities. Th= is working group will define security automation

> protocols and data = format standards in support of information security

> processes and pract= ices. These standards will help security

> practitioners to be= more effective by automating routine tasks related

> to client and serve= r security, freeing them to focus on more advanced

> tasks. The initial = focus of this work is to address enterprise use

> cases pertaining to= the assessment of endpoint posture (using the

definitions of Endpoint = and Posture from RFC 5209).

> 

> The working group w= ill, whenever reasonable and possible, reuse

> existing protocols,= mechanisms, information and data models. Of

> particular interest= to this working group are existing industry

> standards, preferab= ly IETF standards, that could support automation of

> asset, change, conf= iguration, and vulnerability management.

> 

> The working group w= ill define:

> 

> 1. A set of standar= ds to enable assessment of endpoint posture. This

> area of focus provi= des for necessary language and data format

specifications.

> 

> 2. A set of standar= ds for interacting with repositories of content

> related to assessme= nt of endpoint posture.

> 

> Assessment of endpo= int posture assessment entails the following

> general steps, whic= h accommodate policy-driven and asset-driven

assessment:

> 

> 1. Identify endpoin= ts

> 

> 2. Determine specif= ic endpoint elements to assess

> 

> 3. Collect actual v= alue of elements

> 

> 4. Compare actual e= lement values to expected element values

> 

> 5. Report results

> 

> This approach to en= dpoint posture collection enables multiple policies

> to be evaluated bas= ed on a single data collection activity. Policies

> will be evaluated b= y comparing available endpoint posture data

> according to rules = expressed in the policy. Typically, these rules

> will compare the ac= tual value against an expected value or range for

> specific posture el= ements. In some cases, the posture element may

> pertain to software= installation state, in which case the actual and

> expected values may= be "installed" or "not installed." Evaluation of multi= ple

posture elements may be = combined using predicate logic.

> 

> Repository protocol= s are needed to store, update, and retrieve

> configuration check= s and other types of content required for posture

> assessment (see ste= p 2 above).  A content repository is expected to

> house specific vers= ions of checklists (i.e. benchmarks), may be

> required to satisfy= different use cases (i.e. asset inventory,

> configuration setti= ngs, or vulnerabilities).  In addition, content=

> repositories are ex= pected to store up-to-date dictionary of specific

> enumerations, such = as those used for configuration element identifiers,

asset classifications, v= ulnerability identifiers, and so on.

> 

> This working group = will achieve the following deliverables:

> 

> - An Informational = document on Use Cases

> - An Informational = document on Requirements

> - An Informational = document on SACM Architecture

> - A standards-track= document specifying a protocol and data format for

> retrieving configur= ation and policy information for driving data

> collection and anal= ysis

> - A standards-track= document specifying a protocol and data format for

> collecting actual e= ndpoint posture

> 

> The working group w= ill create an overview of related standards work

> Internet-Draft whic= h will document existing work in the IETF or in

> other SDOs which ca= n be used as-is or as a starting point for

> developing solution= s to the SACM requirements. The working group may

> decide to make of t= his document an Informational RFC, but this is not a

mandatory deliverable.

> 

> The working group w= ill work in close coordination with other WGs in

> the IETF (including= , but not limited to MILE and NEA) in order to

> create solutions th= at do not overlap and can be used or re-used to

> meet the goals of m= ore than one working group.

> 

> In accordance with = existing IETF processes, the group will communicate

> with and invite par= ticipation from other relevant standards bodies and

> regulatory organiza= tions, and if necessary reuse existing liaison

> relationships or re= quest the establishment of new liaison relationships.

> 

> SACM-related effort= s are largely aligned, and may overlap, with other

> IETF (and non-IETF)= standardization efforts.  There are common "problems"<= o:p>

> found in SACM, that= may be addressed by the work done in SNMP, IPFIX,

> NETCONF, SYSLOG, NE= A, MILE, and potentially others.  Of particular=

> interest to SACM is= understanding and respecting the distinctions

> between itself and = NEA and MILE.

> 

> One way the NEA pro= tocols can be used is as the transport for data

> collected on the en= dpoint to an external service or data repository

> for further analysi= s and action.  NEA may also serve the purpose of

> carrying data-colle= ction instructions.

> 

> The MILE data forma= ts provide a format to describe incident,

> threat-related inci= dent, and indicator information.  SACM data formats

> provide ways to und= erstand what endpoints are in your environment,

> whether they meet p= olicy requirements, and their current configuration

> state.  T= he data exchanged in MILE, supplementing the SACM data,

> creates enhanced si= tuational awareness, thus enabling increased

> understanding of cu= rrent threats and mitigations.

> 

> After the work item= s in the current charter have been submitted to and

> approved by the IES= G, the WG will recharter or close.

> 

> Goals and Milestone= s

> 

> Sep. 2013 - Initial= submission of an Internet-Draft on Use Cases

> 

> Oct. 2013 - Initial= submission of an Internet-Draft on Requirements

> taking into conside= ration RFC5706 and RFC3535

> 

> Oct. 2013 - Initial= submission of an Internet-Draft on SACM

> Architecture

> 

> Nov. 2013 - Initial= submission of an Internet-Draft on overview of

> related standards w= ork

> 

> Jan. 2014 - Initial= submission of an Internet-Draft for a protocol and

> data format for ret= rieving configuration and policy information for

> driving data collec= tion and analysis

> 

> Jan. 2014 - Initial= submission of an Internet-Draft for a protocol and

> data format for col= lecting actual endpoint posture

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on Use Cases

> for consideration a= s Informational RFC

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on

> Requirements for co= nsideration as Informational RFC

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on SACM

> Architecture for co= nsideration as Informational RFC

> 

> Oct. 2014 - Submiss= ion to the IESG of the Internet-Draft for a

> protocol and data f= ormat for retrieving configuration and policy

> information for dri= ving data collection and analysis for consideration

> as standards-track = RFC

> 

> Oct. 2014 - Submiss= ion to the IESG of the Internet-Draft a protocol

> and data format for= collecting actual endpoint posture for

> consideration as st= andards- track RFC

> 

> This message and at= tachments may contain confidential information.  If

> it appears that thi= s message was sent to you by mistake, any

> retention, dissemin= ation, distribution or copying of this message and

> attachments is stri= ctly prohibited.  Please notify the sender

> immediately and per= manently delete the message and any attachments.

...

 =

This message and attachm= ents may contain confidential information.  If it appears that th= is message was sent to you by mistake, any retention, dissemination, distri= bution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately an= d permanently delete the message and any attachments.

________________________= _______________________

sacm mailing list

 =

--_000_3CBA099FBA0AB843895D72474092B8CF28FA5DMIVEXAMER1N1corpn_-- From Adam.Montville@cisecurity.org Mon Jun 10 14:13:17 2013 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 A0AFC21F96DF for ; Mon, 10 Jun 2013 14:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsGq0ma5dKEd for ; Mon, 10 Jun 2013 14:13:08 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1B421F8F5C for ; Mon, 10 Jun 2013 14:13:07 -0700 (PDT) Received: from [216.82.253.227:35133] by server-15.bemta-7.messagelabs.com id E8/2A-24154-26146B15; Mon, 10 Jun 2013 21:13:06 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-2.tower-170.messagelabs.com!1370898784!24939828!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 31732 invoked from network); 10 Jun 2013 21:13:05 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-2.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2013 21:13:05 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 17:12:52 -0400 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "david.waltermire@nist.gov" , "jfield@gopivotal.com" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAASVeA///unPAAkC8MwAABckzwAAnb4QAAAGe2AAAAK6mAAAfkHfA= Date: Mon, 10 Jun 2013 21:12:51 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F4FE0@CISEXCHANGE1.msisac.org.local> References: <3CBA099FBA0AB843895D72474092B8CF28FA5D@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF28FA5D@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D66F4FE0CISEXCHANGE1msisa_" MIME-Version: 1.0 Cc: "Gunnar.Engelbach@threatguard.com" , "turners@ieca.com" , "adam@stoicsecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:13:18 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D66F4FE0CISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that it is already covered, but because the additional sentence do= esn't mention any specific transport or data format, I don't think there i= s any harm by including it. Adam From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 1:59 PM To: david.waltermire@nist.gov; Adam Montville; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity= .com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I think that was the sentence Kathleen said she wanted. Just wanted to ve= rify... I agree it is already covered but if it is a bit more useful by b= eing called out directly, I am ok with that too. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Monday, June 10, 2013 3:53 PM To: Kent Landfield >, "Adam.Montville@cisecurity.org" >,= "jfield@gopivotal.com" > Cc: Gunnar Engelbach >, Sean Turner >, "adam@stoicsecurity.com" >, "sacm@ietf.org" > Subject: RE: [sacm] Updated Candidate Charter Text Kent's sentence is fine with me, although it is covered by the other text = in the charter: "The working group will, whenever reasonable and possible, reuse existing = protocols, mechanisms, information and data models." "There are common "problems" found in SACM, that may be addressed by the w= ork done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially other= s." Unless I am missing something, I think we have already said as much in the= existing text. Dave From: Kent_Landfield@McAfee.com [mailto:= Kent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 4:42 PM To: Adam.Montville@cisecurity.org; W= altermire, David A.; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text If the sentence is "Transports from MILE may be used by SACM." I have no p= roblem with it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, June 10, 2013 3:32 PM To: David Waltermire >, John Field > Cc: Gunnar Engelbach >, Sean Turner >, "Adam W. Montville" >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text I think once we add the sentence Kathleen would like to see, we're probabl= y good. Any objections to that? -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, June 10, 2013 12:20 PM To: Adam Montville; John Field Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org Subject: RE: [sacm] Updated Candidate Charter Text +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > David A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > last few sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are existing industry > standards, preferably IETF standards, that could support automation of > asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of mul= tiple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in > the IETF (including, but not limited to MILE and NEA) in order to > create solutions that do not overlap and can be used or re-used to > meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships.= > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems= " > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, > creates enhanced situational awareness, thus enabling increased > understanding of current threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol and data format for retrieving configuration and policy > information for driving data collection and analysis for consideration > as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and data format for collecting actual endpoint posture for > consideration as standards- track RFC > > 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. ... 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. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... 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. --_000_05BCCEB107AF88469B9F99783D47C1D66F4FE0CISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that it is alre= ady covered, but because the additional sentence doesn’t mention any= specific transport or data format, I don’t think there is any harm by including it.

 

Adam<= /p>

 

From: Kent_= Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]
Sent: Monday, June 10, 2013 1:59 PM
To: david.waltermire@nist.gov; Adam Montville; jfield@gopivotal.com=
Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoics= ecurity.com; sacm@ietf.org
Subject: Re: [sacm] Updated Candidate Charter Text

 

 

From: <Waltermire>, David Waltermire = <david.waltermire@nist.gov= >
Date: Monday, June 10, 2013 3:53 PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, "Adam.Montville@cisecurity.org" <Adam.Montville@cisecurity.org>,= "jfield@gopivotal.com&qu= ot; <jfield@gopivotal.com&g= t;
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com>, Sean Turner <turners@ieca.com>, "adam@stoicsecurity.com" <adam@stoicsecurity.com&= gt;, "sacm@ietf.org" <sacm@ietf.org>
Subject: RE: [sacm] Updated Candidate Charter Text

 

Kent’s sentence i= s fine with me, although it is covered by the other text in the charter:

 

“The working grou= p will, whenever reasonable and possible, reuse existing protocols, mechan= isms, information and data models.”

“There are common= "problems" found in SACM, that may be addressed by the work don= e in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.̶= 1;

 

Unless I am missing som= ething, I think we have already said as much in the existing text.<= span style=3D"color:black">

 

Dave

 

 

 

From: Kent_Landfield@McAfee.com= [mailto:Kent_Landfield@McAfe= e.com]
Sent: Monday, June 10, 2013 4:42 PM
To: Adam.Montville= @cisecurity.org; Waltermire, David A.; jfield@gopivotal.com
Cc: Gunnar.Enge= lbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org=
Subject: Re: [sacm] Updated Candidate Charter Text

 

If= the sentence is "Transports from MILE may be used by SACM."&nbs= p;I have no problem with it.

 

Kent Landfield

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

 

From: Adam Montville <Adam.Montville@cisecurity.org>
Date: Monday, June 10, 2013 3:32 PM
To: David Waltermire <david.waltermire@nist.gov>, John Field <jfield@gopivotal.com>
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com>, Sean Turner <turners@ieca.com>, "Adam W. Mont= ville" <adam@stoicsecuri= ty.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Updated Candidate Charter Text

 

I think once we add the= sentence Kathleen would like to see, we're probably good.

 

Any objections to that?=

 

-----Original Message--= ---

From: Waltermire, David= A. [mailto:david.waltermire@= nist.gov]

Sent: Monday, June 10, = 2013 12:20 PM

To: Adam Montville; Joh= n Field

Cc: Sean Turner; Gunnar= Engelbach; Adam W. Montville; sacm@ietf.org

Subject: RE: [sacm] Upd= ated Candidate Charter Text

+1 for me. &nb= sp;Are we good with handing this off to Sean today?

Sincerely,

Dave<= /p>

> -----Original Mess= age-----

> From: Adam Montvil= le [mailto:Adam.Montville= @cisecurity.org]

> Sent: Friday, June= 07, 2013 6:36 PM

> To: John Field

> Cc: Sean Turner; G= unnar Engelbach; Adam W. Montville; Waltermire,

> David A.; sacm@ietf.org

> Subject: RE: [sacm= ] Updated Candidate Charter Text

> 

> Thanks John. =  I've modified the "ROLIE paragraph" by truncating the=

> last few sentences= .  Also, changed Boolean to predicate.

> 

> Are there any furt= her nits or really bad oversights in this copy of the

charter?

> 

> If you like it as = it stands, +1 it.

> 

> For me, +1

> 

> ------------------= ---------------------------

> 

> Securing informati= on and the systems that store, process, and transmit

=

> that information i= s a challenging task for organizations of all sizes,

=

> and many security = practitioners spend much of their time on manual

processes.

> Standardized proce= sses to collect, verify, and update security system

> configurations wou= ld allow easier automation of the processes.

> Automating these r= outine tasks would free security practitioners to

> focus on high prio= rity tasks, and should improve operators' ability to

=

> prioritize risk ba= sed on timely information about threats and

> vulnerabilities. T= his working group will define security automation

> protocols and data= format standards in support of information security

=

> processes and prac= tices. These standards will help security

> practitioners to b= e more effective by automating routine tasks related

=

> to client and serv= er security, freeing them to focus on more advanced

> tasks. The initial= focus of this work is to address enterprise use

> cases pertaining t= o the assessment of endpoint posture (using the

definitions of Endpoint= and Posture from RFC 5209).

> 

> The working group = will, whenever reasonable and possible, reuse

> existing protocols= , mechanisms, information and data models. Of

> particular interes= t to this working group are existing industry

> standards, prefera= bly IETF standards, that could support automation of

=

> asset, change, con= figuration, and vulnerability management.

> 

> The working group = will define:

> 

> 1. A set of standa= rds to enable assessment of endpoint posture. This

> area of focus prov= ides for necessary language and data format

specifications.

> 

> 2. A set of standa= rds for interacting with repositories of content

> related to assessm= ent of endpoint posture.

> 

> Assessment of endp= oint posture assessment entails the following

> general steps, whi= ch accommodate policy-driven and asset-driven

assessment:<= /span>

> 

> 1. Identify endpoi= nts

> 

> 2. Determine speci= fic endpoint elements to assess

> 

> 3. Collect actual = value of elements

> 

> 4. Compare actual = element values to expected element values

> 

> 5. Report results<= o:p>

> 

> This approach to e= ndpoint posture collection enables multiple policies

=

> to be evaluated ba= sed on a single data collection activity. Policies

> will be evaluated = by comparing available endpoint posture data

> according to rules= expressed in the policy. Typically, these rules

> will compare the a= ctual value against an expected value or range for

> specific posture e= lements. In some cases, the posture element may

> pertain to softwar= e installation state, in which case the actual and

> expected values ma= y be "installed" or "not installed." Evaluation of mul= tiple

posture elements may be= combined using predicate logic.

> 

> Repository protoco= ls are needed to store, update, and retrieve

> configuration chec= ks and other types of content required for posture

> assessment (see st= ep 2 above).  A content repository is expected to

> house specific ver= sions of checklists (i.e. benchmarks), may be

> required to satisf= y different use cases (i.e. asset inventory,

> configuration sett= ings, or vulnerabilities).  In addition, content

> repositories are e= xpected to store up-to-date dictionary of specific

> enumerations, such= as those used for configuration element identifiers,

asset classifications, = vulnerability identifiers, and so on.

> 

> This working group= will achieve the following deliverables:

> 

> - An Informational= document on Use Cases

> - An Informational= document on Requirements

> - An Informational= document on SACM Architecture

> - A standards-trac= k document specifying a protocol and data format for

=

> retrieving configu= ration and policy information for driving data

> collection and ana= lysis

> - A standards-trac= k document specifying a protocol and data format for

=

> collecting actual = endpoint posture

> 

> The working group = will create an overview of related standards work

> Internet-Draft whi= ch will document existing work in the IETF or in

> other SDOs which c= an be used as-is or as a starting point for

> developing solutio= ns to the SACM requirements. The working group may

> decide to make of = this document an Informational RFC, but this is not a

mandatory deliverable.<= o:p>

> 

> The working group = will work in close coordination with other WGs in

> the IETF (includin= g, but not limited to MILE and NEA) in order to

> create solutions t= hat do not overlap and can be used or re-used to

> meet the goals of = more than one working group.

> 

> In accordance with= existing IETF processes, the group will communicate

=

> with and invite pa= rticipation from other relevant standards bodies and

=

> regulatory organiz= ations, and if necessary reuse existing liaison

> relationships or r= equest the establishment of new liaison relationships.

> 

> SACM-related effor= ts are largely aligned, and may overlap, with other

> IETF (and non-IETF= ) standardization efforts.  There are common "problems"= ;

> found in SACM, tha= t may be addressed by the work done in SNMP, IPFIX,

> NETCONF, SYSLOG, N= EA, MILE, and potentially others.  Of particular

> interest to SACM i= s understanding and respecting the distinctions

> between itself and= NEA and MILE.

> 

> One way the NEA pr= otocols can be used is as the transport for data

> collected on the e= ndpoint to an external service or data repository

> for further analys= is and action.  NEA may also serve the purpose of

> carrying data-coll= ection instructions.

> 

> The MILE data form= ats provide a format to describe incident,

> threat-related inc= ident, and indicator information.  SACM data formats<= /span>

> provide ways to un= derstand what endpoints are in your environment,

> whether they meet = policy requirements, and their current configuration

=

> state.  = The data exchanged in MILE, supplementing the SACM data,=

> creates enhanced s= ituational awareness, thus enabling increased

> understanding of c= urrent threats and mitigations.

> 

> After the work ite= ms in the current charter have been submitted to and

=

> approved by the IE= SG, the WG will recharter or close.

> 

> Goals and Mileston= es

> 

> Sep. 2013 - Initia= l submission of an Internet-Draft on Use Cases

> 

> Oct. 2013 - Initia= l submission of an Internet-Draft on Requirements

> taking into consid= eration RFC5706 and RFC3535

> 

> Oct. 2013 - Initia= l submission of an Internet-Draft on SACM

> Architecture<= /o:p>

> 

> Nov. 2013 - Initia= l submission of an Internet-Draft on overview of

> related standards = work

> 

> Jan. 2014 - Initia= l submission of an Internet-Draft for a protocol and

=

> data format for re= trieving configuration and policy information for

> driving data colle= ction and analysis

> 

> Jan. 2014 - Initia= l submission of an Internet-Draft for a protocol and

=

> data format for co= llecting actual endpoint posture

> 

> Apr. 2014 - Submis= sion to the IESG of the Internet-Draft on Use Cases

> for consideration = as Informational RFC

> 

> Apr. 2014 - Submis= sion to the IESG of the Internet-Draft on

> Requirements for c= onsideration as Informational RFC

> 

> Apr. 2014 - Submis= sion to the IESG of the Internet-Draft on SACM

> Architecture for c= onsideration as Informational RFC

> 

> Oct. 2014 - Submis= sion to the IESG of the Internet-Draft for a

> protocol and data = format for retrieving configuration and policy

> information for dr= iving data collection and analysis for consideration

=

> as standards-track= RFC

> 

> Oct. 2014 - Submis= sion to the IESG of the Internet-Draft a protocol

> and data format fo= r collecting actual endpoint posture for

> consideration as s= tandards- track RFC

> 

> This message and a= ttachments may contain confidential information.  If<= /span>

> it appears that th= is message was sent to you by mistake, any

> retention, dissemi= nation, distribution=20or copying of this message and

> attachments is str= ictly prohibited.  Please notify the sender

> immediately and pe= rmanently delete the message and any attachments.

...

 

This message and attach= ments may contain confidential information.  If it appears that = this message was sent to you by mistake, any retention, dissemination, dis= tribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately a= nd permanently delete the message and any attachments.

_______________________= ________________________

sacm mailing list<= /o:p>

 


...


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.
--_000_05BCCEB107AF88469B9F99783D47C1D66F4FE0CISEXCHANGE1msisa_-- From Adam.Montville@cisecurity.org Mon Jun 10 14:13:57 2013 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 2679421F894E for ; Mon, 10 Jun 2013 14:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIENnyEPxab7 for ; Mon, 10 Jun 2013 14:13:44 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.108]) by ietfa.amsl.com (Postfix) with ESMTP id 170BC21F8628 for ; Mon, 10 Jun 2013 14:13:42 -0700 (PDT) Received: from [216.82.253.243:22568] by server-12.bemta-7.messagelabs.com id EE/B2-28531-58146B15; Mon, 10 Jun 2013 21:13:41 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-171.messagelabs.com!1370898820!19065888!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 3955 invoked from network); 10 Jun 2013 21:13:41 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2013 21:13:41 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 17:13:27 -0400 From: Adam Montville To: "Waltermire, David A." , John Field Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAASVeA///unPAAkC8MwAAEBrEg Date: Mon, 10 Jun 2013 21:13:27 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F4FEC@CISEXCHANGE1.msisac.org.local> References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , Sean Turner , "Adam W. Montville" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:13:57 -0000 Sean, are you good with the charter (either before or after adding the sen= tence proposed by Kathleen)? > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Monday, June 10, 2013 12:20 PM > To: Adam Montville; John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text >=20 > +1 for me. Are we good with handing this off to Sean today? >=20 > Sincerely, > Dave >=20 > > -----Original Message----- > > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > > Sent: Friday, June 07, 2013 6:36 PM > > To: John Field > > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > > David A.; sacm@ietf.org > > Subject: RE: [sacm] Updated Candidate Charter Text > > > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > > last few sentences. Also, changed Boolean to predicate. > > > > Are there any further nits or really bad oversights in this copy of th= e > charter? > > > > If you like it as it stands, +1 it. > > > > For me, +1 > > > > --------------------------------------------- > > > > Securing information and the systems that store, process, and transmit= > > that information is a challenging task for organizations of all sizes,= > > and many security practitioners spend much of their time on manual > processes. > > Standardized processes to collect, verify, and update security system > > configurations would allow easier automation of the processes. > > Automating these routine tasks would free security practitioners to > > focus on high priority tasks, and should improve operators' ability to= > > prioritize risk based on timely information about threats and > > vulnerabilities. This working group will define security automation > > protocols and data format standards in support of information security= > > processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks related= > > to client and server security, freeing them to focus on more advanced > > tasks. The initial focus of this work is to address enterprise use > > cases pertaining to the assessment of endpoint posture (using the > definitions of Endpoint and Posture from RFC 5209). > > > > The working group will, whenever reasonable and possible, reuse > > existing protocols, mechanisms, information and data models. Of > > particular interest to this working group are existing industry > > standards, preferably IETF standards, that could support automation of= > > asset, change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area of focus provides for necessary language and data format > specifications. > > > > 2. A set of standards for interacting with repositories of content > > related to assessment of endpoint posture. > > > > Assessment of endpoint posture assessment entails the following > > general steps, which accommodate policy-driven and asset-driven > assessment: > > > > 1. Identify endpoints > > > > 2. Determine specific endpoint elements to assess > > > > 3. Collect actual value of elements > > > > 4. Compare actual element values to expected element values > > > > 5. Report results > > > > This approach to endpoint posture collection enables multiple policies= > > to be evaluated based on a single data collection activity. Policies > > will be evaluated by comparing available endpoint posture data > > according to rules expressed in the policy. Typically, these rules > > will compare the actual value against an expected value or range for > > specific posture elements. In some cases, the posture element may > > pertain to software installation state, in which case the actual and > > expected values may be "installed" or "not installed." Evaluation of m= ultiple > posture elements may be combined using predicate logic. > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. asset inventory, > > configuration settings, or vulnerabilities). In addition, content > > repositories are expected to store up-to-date dictionary of specific > > enumerations, such as those used for configuration element identifiers= , > asset classifications, vulnerability identifiers, and so on. > > > > This working group will achieve the following deliverables: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > - A standards-track document specifying a protocol and data format for= > > retrieving configuration and policy information for driving data > > collection and analysis > > - A standards-track document specifying a protocol and data format for= > > collecting actual endpoint posture > > > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in > > other SDOs which can be used as-is or as a starting point for > > developing solutions to the SACM requirements. The working group may > > decide to make of this document an Informational RFC, but this is not = a > mandatory deliverable. > > > > The working group will work in close coordination with other WGs in > > the IETF (including, but not limited to MILE and NEA) in order to > > create solutions that do not overlap and can be used or re-used to > > meet the goals of more than one working group. > > > > In accordance with existing IETF processes, the group will communicate= > > with and invite participation from other relevant standards bodies and= > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison relationship= s. > > > > SACM-related efforts are largely aligned, and may overlap, with other > > IETF (and non-IETF) standardization efforts. There are common "proble= ms" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > > interest to SACM is understanding and respecting the distinctions > > between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data-collection instructions. > > > > The MILE data formats provide a format to describe incident, > > threat-related incident, and indicator information. SACM data formats= > > provide ways to understand what endpoints are in your environment, > > whether they meet policy requirements, and their current configuration= > > state. The data exchanged in MILE, supplementing the SACM data, > > creates enhanced situational awareness, thus enabling increased > > understanding of current threats and mitigations. > > > > After the work items in the current charter have been submitted to and= > > approved by the IESG, the WG will recharter or close. > > > > Goals and Milestones > > > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > > taking into consideration RFC5706 and RFC3535 > > > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > > Architecture > > > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > > related standards work > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= > > data format for retrieving configuration and policy information for > > driving data collection and analysis > > > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and= > > data format for collecting actual endpoint posture > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > > for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > > Requirements for consideration as Informational RFC > > > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > > Architecture for consideration as Informational RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > protocol and data format for retrieving configuration and policy > > information for driving data collection and analysis for consideration= > > as standards-track RFC > > > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > > and data format for collecting actual endpoint posture for > > consideration as standards- track RFC > > > > 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. >=20 > ... 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 shanna@juniper.net Mon Jun 10 14:26:51 2013 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 8B05721F9A3A for ; Mon, 10 Jun 2013 14:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 07Cb-aAYqf5G for ; Mon, 10 Jun 2013 14:26:44 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id D123F21F9A38 for ; Mon, 10 Jun 2013 14:26:40 -0700 (PDT) Received: from mail114-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Jun 2013 21:26:40 +0000 Received: from mail114-co1 (localhost [127.0.0.1]) by mail114-co1-R.bigfish.com (Postfix) with ESMTP id 41D7FA6042B for ; Mon, 10 Jun 2013 21:26:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: PS-37(zz9371I1431J9f17Rc85fh542I1432I1418I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1c8fb4h18602eh8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail114-co1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=shanna@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail114-co1 (localhost.localdomain [127.0.0.1]) by mail114-co1 (MessageSwitch) id 1370899566471807_29469; Mon, 10 Jun 2013 21:26:06 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.254]) by mail114-co1.bigfish.com (Postfix) with ESMTP id 6FBD8CC00CE for ; Mon, 10 Jun 2013 21:26:06 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.52) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Jun 2013 21:26:03 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Jun 2013 14:25:57 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 10 Jun 2013 14:25:56 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 10 Jun 2013 14:37:28 -0700 Received: from mail30-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Jun 2013 21:25:56 +0000 Received: from mail30-ch1 (localhost [127.0.0.1]) by mail30-ch1-R.bigfish.com (Postfix) with ESMTP id D4D241601AE for ; Mon, 10 Jun 2013 21:25:55 +0000 (UTC) Received: from mail30-ch1 (localhost.localdomain [127.0.0.1]) by mail30-ch1 (MessageSwitch) id 1370899499856588_25976; Mon, 10 Jun 2013 21:24:59 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail30-ch1.bigfish.com (Postfix) with ESMTP id B68F8180396; Mon, 10 Jun 2013 21:24:59 +0000 (UTC) Received: from SN2PRD0510HT003.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Jun 2013 21:24:59 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.13]) by SN2PRD0510HT003.namprd05.prod.outlook.com ([10.255.116.38]) with mapi id 14.16.0311.000; Mon, 10 Jun 2013 21:24:58 +0000 From: Stephen Hanna To: Adam Montville , "Kent_Landfield@McAfee.com" , "david.waltermire@nist.gov" , "jfield@gopivotal.com" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6sTB6NtW1w0unBSJfMGLGYpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAAZTgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAAFEEAgAACowCAAAM+AIAAAV2AgAAD9YCAAALaoA== Date: Mon, 10 Jun 2013 21:24:57 +0000 Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF28FA5D@MIVEXAMER1N1.corp.nai.org> <05BCCEB107AF88469B9F99783D47C1D66F4FE0@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F4FE0@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C0A1SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISECURITY.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MCAFEE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NIST.GOV$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GOPIVOTAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%THREATGUARD.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%STOICSECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "Gunnar.Engelbach@threatguard.com" , "turners@ieca.com" , "adam@stoicsecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:26:51 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C0A1SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let's not add redundant text. Otherwise, we'll need to add more sentences s= aying that transports and data formats may come from NEA and so forth. Either way, I'm +1 on sending the revised charter to Sean. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Monday, June 10, 2013 5:13 PM To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov; jfield@gopivotal.= com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.= com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I agree that it is already covered, but because the additional sentence doe= sn't mention any specific transport or data format, I don't think there is = any harm by including it. Adam From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 1:59 PM To: david.waltermire@nist.gov; Adam Montv= ille; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I think that was the sentence Kathleen said she wanted. Just wanted to ver= ify... I agree it is already covered but if it is a bit more useful by bei= ng called out directly, I am ok with that too. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Monday, June 10, 2013 3:53 PM To: Kent Landfield >, "Adam.Montville@cisecurity.org= " >, "j= field@gopivotal.com" > Cc: Gunnar Engelbach >, Sean Turner >, "adam@stoicsecurity.com" >, "sacm@ietf.org" > Subject: RE: [sacm] Updated Candidate Charter Text Kent's sentence is fine with me, although it is covered by the other text i= n the charter: "The working group will, whenever reasonable and possible, reuse existing p= rotocols, mechanisms, information and data models." "There are common "problems" found in SACM, that may be addressed by the wo= rk done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.= " Unless I am missing something, I think we have already said as much in the = existing text. Dave From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 4:42 PM To: Adam.Montville@cisecurity.org; Wa= ltermire, David A.; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text If the sentence is "Transports from MILE may be used by SACM." I have no pr= oblem with it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, June 10, 2013 3:32 PM To: David Waltermire >, John Field > Cc: Gunnar Engelbach >, Sean Turner >, "Adam W. Montville" >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text I think once we add the sentence Kathleen would like to see, we're probably= good. Any objections to that? -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, June 10, 2013 12:20 PM To: Adam Montville; John Field Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org Subject: RE: [sacm] Updated Candidate Charter Text +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > David A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > last few sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are existing industry > standards, preferably IETF standards, that could support automation of > asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of mult= iple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in > the IETF (including, but not limited to MILE and NEA) in order to > create solutions that do not overlap and can be used or re-used to > meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, > creates enhanced situational awareness, thus enabling increased > understanding of current threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol and data format for retrieving configuration and policy > information for driving data collection and analysis for consideration > as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and data format for collecting actual endpoint posture for > consideration as standards- track RFC > > 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. ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. --_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C0A1SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let’s not add redun= dant text. Otherwise, we’ll need to add more sentences saying that tr= ansports and data formats may come from NEA and so forth.=

 <= /p>

Either way, I’m = 3;1 on sending the revised charter to Sean.

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Monday, June 10, 2013 5:13 PM
To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov; jfield@gop= ivotal.com
Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicse= curity.com; sacm@ietf.org
Subject: Re: [sacm] Updated Candidate Charter Text=

 

I agree that it is alread= y covered, but because the additional sentence doesn’t mention any sp= ecific transport or data format, I don’t think there is any harm by including it.

 <= /p>

Adam

 <= /p>

 

 =

 =

Kent’s sentence is = fine with me, although it is covered by the other text in the charter:

 

“The working group = will, whenever reasonable and possible, reuse existing protocols, mechanism= s, information and data models.”

“There are common &= quot;problems" found in SACM, that may be addressed by the work done i= n SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.”

 

Unless I am missing somet= hing, I think we have already said as much in the existing text.

 

Dave

 =

 

 

 =

 =

From: Adam Montville <Adam.Montville@cisecurity.org>
Date: Monday, June 10, 2013 3:32 PM
To: David Waltermire <david.waltermire@nist.gov>, John Field <jfield@gopivotal.com>
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com>, Sean Turner <turners@ieca.com>, "Adam W. Montvi= lle" <adam@stoicsecurity.= com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Updated Candidate Charter Text

 =

I think once we add the = sentence Kathleen would like to see, we're probably good.=

 =

Any objections to that?<= o:p>

 =

-----Original Message---= --

From: Waltermire, David = A. [mailto:david.waltermire@ni= st.gov]

Sent: Monday, June 10, 2= 013 12:20 PM

To: Adam Montville; John= Field

Cc: Sean Turner; Gunnar = Engelbach; Adam W. Montville; sacm@ietf.org

Subject: RE: [sacm] Upda= ted Candidate Charter Text

+1 for me. &nbs= p;Are we good with handing this off to Sean today?

Sincerely,

Dave

> -----Original Messa= ge-----

> From: Adam Montvill= e [mailto:Adam.Montville@c= isecurity.org]

> Sent: Friday, June = 07, 2013 6:36 PM

> To: John Field=

> Cc: Sean Turner; Gu= nnar Engelbach; Adam W. Montville; Waltermire,

> David A.; sacm@ietf.org

> Subject: RE: [sacm]= Updated Candidate Charter Text

> 

> Thanks John. &= nbsp;I've modified the "ROLIE paragraph" by truncating the

> last few sentences.=   Also, changed Boolean to predicate.

> 

> Are there any furth= er nits or really bad oversights in this copy of the

charter?

> 

> If you like it as i= t stands, +1 it.

> 

> For me, +1=

> 

> -------------------= --------------------------

> 

> Securing informatio= n and the systems that store, process, and transmit

> that information is= a challenging task for organizations of all sizes,

> and many security p= ractitioners spend much of their time on manual

processes.

> Standardized proces= ses to collect, verify, and update security system

> configurations woul= d allow easier automation of the processes.

> Automating these ro= utine tasks would free security practitioners to

> focus on high prior= ity tasks, and should improve operators' ability to

> prioritize risk bas= ed on timely information about threats and

> vulnerabilities. Th= is working group will define security automation

> protocols and data = format standards in support of information security

> processes and pract= ices. These standards will help security

> practitioners to be= more effective by automating routine tasks related

> to client and serve= r security, freeing them to focus on more advanced

> tasks. The initial = focus of this work is to address enterprise use

> cases pertaining to= the assessment of endpoint posture (using the

definitions of Endpoint = and Posture from RFC 5209).

> 

> The working group w= ill, whenever reasonable and possible, reuse

> existing protocols,= mechanisms, information and data models. Of

> particular interest= to this working group are existing industry

> standards, preferab= ly IETF standards, that could support automation of

> asset, change, conf= iguration, and vulnerability management.

> 

> The working group w= ill define:

> 

> 1. A set of standar= ds to enable assessment of endpoint posture. This

> area of focus provi= des for necessary language and data format

specifications.

> 

> 2. A set of standar= ds for interacting with repositories of content

> related to assessme= nt of endpoint posture.

> 

> Assessment of endpo= int posture assessment entails the following

> general steps, whic= h accommodate policy-driven and asset-driven

assessment:

> 

> 1. Identify endpoin= ts

> 

> 2. Determine specif= ic endpoint elements to assess

> 

> 3. Collect actual v= alue of elements

> 

> 4. Compare actual e= lement values to expected element values

> 

> 5. Report results

> 

> This approach to en= dpoint posture collection enables multiple policies

> to be evaluated bas= ed on a single data collection activity. Policies

> will be evaluated b= y comparing available endpoint posture data

> according to rules = expressed in the policy. Typically, these rules

> will compare the ac= tual value against an expected value or range for

> specific posture el= ements. In some cases, the posture element may

> pertain to software= installation state, in which case the actual and

> expected values may= be "installed" or "not installed." Evaluation of multi= ple

posture elements may be = combined using predicate logic.

> 

> Repository protocol= s are needed to store, update, and retrieve

> configuration check= s and other types of content required for posture

> assessment (see ste= p 2 above).  A content repository is expected to

> house specific vers= ions of checklists (i.e. benchmarks), may be

> required to satisfy= different use cases (i.e. asset inventory,

> configuration setti= ngs, or vulnerabilities).  In addition, content=

> repositories are ex= pected to store up-to-date dictionary of specific

> enumerations, such = as those used for configuration element identifiers,

asset classifications, v= ulnerability identifiers, and so on.

> 

> This working group = will achieve the following deliverables:

> 

> - An Informational = document on Use Cases

> - An Informational = document on Requirements

> - An Informational = document on SACM Architecture

> - A standards-track= document specifying a protocol and data format for

> retrieving configur= ation and policy information for driving data

> collection and anal= ysis

> - A standards-track= document specifying a protocol and data format for

> collecting actual e= ndpoint posture

> 

> The working group w= ill create an overview of related standards work

> Internet-Draft whic= h will document existing work in the IETF or in

> other SDOs which ca= n be used as-is or as a starting point for

> developing solution= s to the SACM requirements. The working group may

> decide to make of t= his document an Informational RFC, but this is not a

mandatory deliverable.

> 

> The working group w= ill work in close coordination with other WGs in

> the IETF (including= , but not limited to MILE and NEA) in order to

> create solutions th= at do not overlap and can be used or re-used to

> meet the goals of m= ore than one working group.

> 

> In accordance with = existing IETF processes, the group will communicate

> with and invite par= ticipation from other relevant standards bodies and

> regulatory organiza= tions, and if necessary reuse existing liaison

> relationships or re= quest the establishment of new liaison relationships.

> 

> SACM-related effort= s are largely aligned, and may overlap, with other

> IETF (and non-IETF)= standardization efforts.  There are common "problems"<= o:p>

> found in SACM, that= may be addressed by the work done in SNMP, IPFIX,

> NETCONF, SYSLOG, NE= A, MILE, and potentially others.  Of particular=

> interest to SACM is= understanding and respecting the distinctions

> between itself and = NEA and MILE.

> 

> One way the NEA pro= tocols can be used is as the transport for data

> collected on the en= dpoint to an external service or data repository

> for further analysi= s and action.  NEA may also serve the purpose of

> carrying data-colle= ction instructions.

> 

> The MILE data forma= ts provide a format to describe incident,

> threat-related inci= dent, and indicator information.  SACM data formats

> provide ways to und= erstand what endpoints are in your environment,

> whether they meet p= olicy requirements, and their current configuration

> state.  T= he data exchanged in MILE, supplementing the SACM data,

> creates enhanced si= tuational awareness, thus enabling increased

> understanding of cu= rrent threats and mitigations.

> 

> After the work item= s in the current charter have been submitted to and

> approved by the IES= G, the WG will recharter or close.

> 

> Goals and Milestone= s

> 

> Sep. 2013 - Initial= submission of an Internet-Draft on Use Cases

> 

> Oct. 2013 - Initial= submission of an Internet-Draft on Requirements

> taking into conside= ration RFC5706 and RFC3535

> 

> Oct. 2013 - Initial= submission of an Internet-Draft on SACM

> Architecture

> 

> Nov. 2013 - Initial= submission of an Internet-Draft on overview of

> related standards w= ork

> 

> Jan. 2014 - Initial= submission of an Internet-Draft for a protocol and

> data format for ret= rieving configuration and policy information for

> driving data collec= tion and analysis

> 

> Jan. 2014 - Initial= submission of an Internet-Draft for a protocol and

> data format for col= lecting actual endpoint posture

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on Use Cases

> for consideration a= s Informational RFC

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on

> Requirements for co= nsideration as Informational RFC

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on SACM

> Architecture for co= nsideration as Informational RFC

> 

> Oct. 2014 - Submiss= ion to the IESG of the Internet-Draft for a

> protocol and data f= ormat for retrieving configuration and policy

> information for dri= ving data collection and analysis for consideration

> as standards-track = RFC

> 

> Oct. 2014 - Submiss= ion to the IESG of the Internet-Draft a protocol

> and data format for= collecting actual endpoint posture for

> consideration as st= andards- track RFC

> 

> This message and at= tachments may contain confidential information.  If

> it appears that thi= s message was sent to you by mistake, any

> retention, dissemin= ation, distribution or copying of this message and

> attachments is stri= ctly prohibited.  Please notify the sender

> immediately and per= manently delete the message and any attachments.

...

 =

This message and attachm= ents may contain confidential information.  If it appears that th= is message was sent to you by mistake, any retention, dissemination, distri= bution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately an= d permanently delete the message and any attachments.

________________________= _______________________

sacm mailing list

 =


...


This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

--_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C0A1SN2PRD0510MB372_-- From kathleen.moriarty@emc.com Mon Jun 10 15:02:13 2013 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 4718A21F9ACD for ; Mon, 10 Jun 2013 15:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjPVq+zGDYIF for ; Mon, 10 Jun 2013 15:02:06 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C4A7021F9AC4 for ; Mon, 10 Jun 2013 15:02:05 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5AM207W024849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 18:02:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 10 Jun 2013 18:01:45 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5AM1hes021333; Mon, 10 Jun 2013 18:01:45 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Mon, 10 Jun 2013 18:01:43 -0400 From: "Moriarty, Kathleen" To: Stephen Hanna , Adam Montville , "Kent_Landfield@McAfee.com" , "david.waltermire@nist.gov" , "Field, John (Pivotal)" Date: Mon, 10 Jun 2013 18:01:42 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6sTB6NtW1w0unBSJfMGLGYpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAAZTgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAAFEEAgAACowCAAAM+AIAAAV2AgAAD9YCAAALaoIAACl7g Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF28FA5D@MIVEXAMER1N1.corp.nai.org> <05BCCEB107AF88469B9F99783D47C1D66F4FE0@CISEXCHANGE1.msisac.org.local> 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_F5063677821E3B4F81ACFB7905573F24DF027616MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Gunnar.Engelbach@threatguard.com" , "turners@ieca.com" , "adam@stoicsecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:02:13 -0000 --_000_F5063677821E3B4F81ACFB7905573F24DF027616MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A similar sentence is already there for NEA, which trigged the request for = the addition. The thought was more to make sure people understand that the= transports are flexible and can carry any data formats, they are not speci= fic to data formats in MILE. If GRC-Exchange gets revived, that would be a= clear example. Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ste= phen Hanna Sent: Monday, June 10, 2013 5:25 PM To: Adam Montville; Kent_Landfield@McAfee.com; david.waltermire@nist.gov; F= ield, John (Pivotal) Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.= com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text Let's not add redundant text. Otherwise, we'll need to add more sentences s= aying that transports and data formats may come from NEA and so forth. Either way, I'm +1 on sending the revised charter to Sean. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Monday, June 10, 2013 5:13 PM To: Kent_Landfield@McAfee.com; david.walt= ermire@nist.gov; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I agree that it is already covered, but because the additional sentence doe= sn't mention any specific transport or data format, I don't think there is = any harm by including it. Adam From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 1:59 PM To: david.waltermire@nist.gov; Adam Montv= ille; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I think that was the sentence Kathleen said she wanted. Just wanted to ver= ify... I agree it is already covered but if it is a bit more useful by bei= ng called out directly, I am ok with that too. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Monday, June 10, 2013 3:53 PM To: Kent Landfield >, "Adam.Montville@cisecurity.org= " >, "j= field@gopivotal.com" > Cc: Gunnar Engelbach >, Sean Turner >, "adam@stoicsecurity.com" >, "sacm@ietf.org" > Subject: RE: [sacm] Updated Candidate Charter Text Kent's sentence is fine with me, although it is covered by the other text i= n the charter: "The working group will, whenever reasonable and possible, reuse existing p= rotocols, mechanisms, information and data models." "There are common "problems" found in SACM, that may be addressed by the wo= rk done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.= " Unless I am missing something, I think we have already said as much in the = existing text. Dave From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 4:42 PM To: Adam.Montville@cisecurity.org; Wa= ltermire, David A.; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text If the sentence is "Transports from MILE may be used by SACM." I have no pr= oblem with it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, June 10, 2013 3:32 PM To: David Waltermire >, John Field > Cc: Gunnar Engelbach >, Sean Turner >, "Adam W. Montville" >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text I think once we add the sentence Kathleen would like to see, we're probably= good. Any objections to that? -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, June 10, 2013 12:20 PM To: Adam Montville; John Field Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org Subject: RE: [sacm] Updated Candidate Charter Text +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > David A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > last few sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are existing industry > standards, preferably IETF standards, that could support automation of > asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of mult= iple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in > the IETF (including, but not limited to MILE and NEA) in order to > create solutions that do not overlap and can be used or re-used to > meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, > creates enhanced situational awareness, thus enabling increased > understanding of current threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol and data format for retrieving configuration and policy > information for driving data collection and analysis for consideration > as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and data format for collecting actual endpoint posture for > consideration as standards- track RFC > > 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. ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. --_000_F5063677821E3B4F81ACFB7905573F24DF027616MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A similar= sentence is already there for NEA, which trigged the request for the addit= ion.  The thought was more to make sure people understand that the tra= nsports are flexible and can carry any data formats, they are not specific = to data formats in MILE.  If GRC-Exchange gets revived, that would be = a clear example.

&nbs= p;

Thanks,

Kathleen

 

= From:= sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Stephen Hanna
Sent: Monday, June 10, 2013 5:25 PM
To:= Adam Montville; Kent_Landfield@McAfee.com; david.waltermire@nist.gov; Fiel= d, John (Pivotal)
Cc: Gunnar.Engelbach@threatguard.com; turners@i= eca.com; adam@stoicsecurity.com; sacm@ietf.org
Subject: Re: [sacm= ] Updated Candidate Charter Text

 

Let’s n= ot add redundant text. Otherwise, we’ll need to add more sentences sa= ying that transports and data formats may come from NEA and so forth.<= /o:p>

 

Either way, I’m +1 on sending the revised ch= arter to Sean.

 =

Thanks,

<= p class=3DMsoNormal> 

Steve

 <= /o:p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Adam Montville
Sent: Monday, June 10, 2013 5:13 PM
To: = Kent_Landfield@McAfee.com;= david.waltermire@nist.gov= ; jfield@gopivotal.com
Cc= : Gunnar.Engelbach@= threatguard.com; turners@ieca.com; adam@stoicsecurity.com; <= a href=3D"mailto:sacm@ietf.org">sacm@ietf.org
Subject: Re: [s= acm] Updated Candidate Charter Text

 

I agree tha= t it is already covered, but because the additional sentence doesn’t = mention any specific transport or data format, I don’t think there is= any harm by including it.

 

Adam

 

From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]
Sent: Monday, June = 10, 2013 1:59 PM
To: david.waltermire@nist.gov; Adam Montville; jfield@gopivotal.com
Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org
Subject: Re: [sacm] Updated Candidate Chart= er Text

 

I t= hink that was the sentence Kathleen said she wanted.  Just wanted to v= erify…  I agree it is already covered but if it is a bit more us= eful by being called out directly, I am ok with that too.=

 =

Kent Landfield=

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

 

From: <Waltermi= re>, David Waltermire <d= avid.waltermire@nist.gov>
Date: Monday, June 10, 2013 3:53= PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, "Adam.Montville@cisecurity.org" <Adam.Montville@cisecurity.org= >, "jfield@gopivotal.com" <jfield@gopivotal.com>
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com>, Sean Turner <= ;turners@ieca.com>, "adam@stoicsecurity.com" <adam@stoicsecurity.com>, &qu= ot;sacm@ietf.org" <sacm@ietf.org>
Subject: RE: [sacm] U= pdated Candidate Charter Text

 

Kent’s sentence is fine with me, although it is covere= d by the other text in the charter:=

 

“The wor= king group will, whenever reasonable and possible, reuse existing protocols= , mechanisms, information and data models.”

“There are= common "problems" found in SACM, that may be addressed by the wo= rk done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.= ”

 

Unless I am missing something, I think we = have already said as much in the existing text.

 

Da= ve

 

 

 

From: Kent_Landfield@M= cAfee.com [mailto:Kent_Lan= dfield@McAfee.com]
Sent: Monday, June 10, 2013 4:42 PM
To: Adam.Montville@ci= security.org; Waltermire, David A.; jfield@gopivotal.com
Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@= ietf.org
Subject: Re: [sacm] Updated Candidate Charter Text

 

<= div>

If the sentence is "Transports from MILE may be used by SACM."= ; I have no problem with it.

 

Kent Landfield

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

=

&nb= sp;

From: = Adam Montville <Adam.Montville@cisecurity.org>
Date: Monday, June= 10, 2013 3:32 PM
To: David Waltermire <david.waltermire@nist.gov>, John Field <jfield@gopivotal.com>
Cc= : Gunnar Engelbach <gunnar.engelbach@threatguard.com>, Sean Turner <turners@ieca.com>, "Adam W. Montville&qu= ot; <adam@stoicsecurity.com>, "sacm@ietf.org" <<= a href=3D"mailto:sacm@ietf.org">sacm@ietf.org>
Subject: Re= : [sacm] Updated Candidate Charter Text<= o:p>

 

I think once we add the sentence Kathleen would like to see, we'= re probably good.

 

Any objections to that?

 

-----Original= Message-----

From: Waltermire, David A. [mailto:david.waltermire@nist.gov]

Sent: Monday,= June 10, 2013 12:20 PM

To: Adam Montville; John Field

Cc: Sean= Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org

= Subject: RE: [sacm] Updated Candidate Charter T= ext

+1 for me.  Are we good with handing this off to Sean t= oday?

Sincerely,

Dave

> -----Original Message-----

> From: Adam Montville [mailto:Adam.Montville@cisecurity.org]

<= div>

> Sent: Friday, Jun= e 07, 2013 6:36 PM

> To: John Field

> Cc: Sean Turner; Gu= nnar Engelbach; Adam W. Montville; Waltermire,

<= div>

> David A.; sacm@ietf.org

> Subject: RE: [sacm] = Updated Candidate Charter Text

> 

=

> Thanks John.&nbs= p; I've modified the "ROLIE paragraph" by truncating the

> last few sentences.  Also, changed Boolean to predicate.<= o:p>

> 

> Are there any further nits or really bad oversi= ghts in this copy of the

charter?

> <= /p>

> If you = like it as it stands, +1 it.

> 

> For me, +1

&= gt; 

> ---------------------------------------------

&= gt; 

> Securing information and the systems that store, proc= ess, and transmit

> that information is a challenging task for org= anizations of all sizes,

> and many security practitioners spend m= uch of their time on manual

processes.

> Standardized proces= ses to collect, verify, and update security system

> configuration= s would allow easier automation of the processes.

> Automating the= se routine tasks would free security practitioners to

=

> focus on h= igh priority tasks, and should improve operators' ability to

> pri= oritize risk based on timely information about threats and

> vulne= rabilities. This working group will define security automation

> p= rotocols and data format standards in support of information security<= /o:p>

> processes and practices. These standards will help security

>= ; practitioners to be more effective by automating routine tasks related

> to client and server security, freeing them to focus on more advan= ced

> tasks. The initial focus of this work is to address enterpri= se use

> cases pertaining to the assessment of endpoint posture (u= sing the

definitions of Endpoint and Posture from RFC 5209).

= > 

> The working group will, whenever reasonable and possi= ble, reuse

> existing protocols, mechanisms, information and data = models. Of

> particular interest to this working group are existin= g industry

> standards, preferably IETF standards, that could supp= ort automation of

> asset, change, configuration, and vulnerabilit= y management.

> 

> The working group will define:

> 

> 1. A set of standards to enable assessment of end= point posture. This

> area of focus provides for necessary languag= e and data format

specifications.

> <= /p>

> 2. A se= t of standards for interacting with repositories of content

> rela= ted to assessment of endpoint posture.

> 

> Assessme= nt of endpoint posture assessment entails the following

> general = steps, which accommodate policy-driven and asset-driven

assessment:

> 

> 1. Identify endpoints

> 

>= ; 2. Determine specific endpoint elements to assess

> 

= > 3. Collect actual value of elements

> =

> 4. Com= pare actual element values to expected element values

=

> =

> 5. Report results

> 

<= p class=3DMsoNormal>> This approach to endpo= int posture collection enables multiple policies

> to be evaluated= based on a single data collection activity. Policies

=

> will be ev= aluated by comparing available endpoint posture data

<= /div>

> according t= o rules expressed in the policy. Typically, these rules

> will com= pare the actual value against an expected value or range for

> spe= cific posture elements. In some cases, the posture element may

> p= ertain to software installation state, in which case the actual and

&= gt; expected values may be "installed" or "not installed.&qu= ot; Evaluation of multiple

posture elements may be combined using pre= dicate logic.

> 

> Repository protocols are needed t= o store, update, and retrieve

> configuration checks and other typ= es of content required for posture

> assessment (see step 2 above)= .  A content repository is expected to

> house specific = versions of checklists (i.e. benchmarks), may be

> required to sat= isfy different use cases (i.e. asset inventory,

=

> configuration se= ttings, or vulnerabilities).  In addition, content

> rep= ositories are expected to store up-to-date dictionary of specific

>= ; enumerations, such as those used for configuration element identifiers,

asset classifications, vulnerability identifiers, and so on.

>= ; 

> This working group will achieve the following deliverabl= es:

> 

<= span style=3D'color:black'>> - An Informational document on Use Cases

> - An Informational document on Requirements

<= /div>

> - An Inform= ational document on SACM Architecture

> - A standards-track docume= nt specifying a protocol and data format for

> retrieving configur= ation and policy information for driving data

> collection and ana= lysis

> - A standards-track document specifying a protocol and dat= a format for

> collecting actual endpoint posture

> =

> The working group will create an overview of related standards = work

> Internet-Draft which will document existing work in the IET= F or in

> other SDOs which can be used as-is or as a starting poin= t for

> developing solutions to the SACM requirements. The working= group may

> decide to make of this document an Informational RFC,= but this is not a

mandatory deliverable.

=

> =

>= The working group will work in close coordination with other WGs in

= > the IETF (including, but not limited to MILE and NEA) in order to=

> create solutions that do not overlap and can be used or re-used to

> meet the goals of more than one working group.<= /p>

> 

> In accordance with existing IETF processes, the group will commun= icate

> with and invite participation from other relevant standard= s bodies and

> regulatory organizations, and if necessary reuse ex= isting liaison

> relationships or request the establishment of new= liaison relationships.

> 

> SACM-related efforts ar= e largely aligned, and may overlap, with other

<= div>

> IETF (and non-IET= F) standardization efforts.  There are common "problems"= ;

> found in SACM, that may be addressed by the work done in SNMP,= IPFIX,

> NETCONF, SYSLOG, NEA, MILE, and potentially others. = ; Of particular

<= span style=3D'color:black'>> interest to SACM is understanding and respe= cting the distinctions

> between itself and NEA and MILE.

&g= t; 

> One way the NEA protocols can be used is as the trans= port for data

> collected on the endpoint to an external service o= r data repository

> for further analysis and action.  NE= A may also serve the purpose of

> carrying data-collection instruc= tions.

> 

> The MILE data formats provide a format t= o describe incident,

<= span style=3D'color:black'>> threat-related incident, and indicator info= rmation.  SACM data formats

> provide ways to understand= what endpoints are in your environment,

> whether they meet polic= y requirements, and their current configuration

=

> state. &nbs= p;The data exchanged in MILE, supplementing the SACM data,

> creat= es enhanced situational awareness, thus enabling increased

> under= standing of current threats and mitigations.

> 

> Af= ter the work items in the current charter have been submitted to and

= > approved by the IESG, the WG will recharter or close.

> =

> Goals and Milestones

> 

> Sep. 2013 - = Initial submission of an Internet-Draft on Use Cases

<= /div>

> <= /o:p>

> Oct. 2013 - Initial submission of an Internet-Draft on Requirements

> taking into consideration RFC5706 and RFC3535

> 

> Oct. 2013 - Initial submission of an Internet-Draft on SACM

= > Architecture

> 

> Nov. 2013 - Initial submissio= n of an Internet-Draft on overview of

> related standards work

> 

> Jan. 2014 - Initial submission of an Internet-Draf= t for a protocol and

<= span style=3D'color:black'>> data format for retrieving configuration an= d policy information for

> driving data collection and analysis

> 

> Jan. 2014 - Initial submission of an Internet-Dra= ft for a protocol and

= > data format for collecting actual endpoint= posture

> 

> Apr. 2014 - Submission to the IESG o= f the Internet-Draft on Use Cases

> for consideration as Informat= ional RFC

> 

> Apr. 2014 - Submission to the IESG o= f the Internet-Draft on

> Requirements for consideration as Inform= ational RFC

> 

> Apr. 2014 - Submission to the IESG = of the Internet-Draft on SACM

> Architecture for consideration as = Informational RFC

> 

> Oct. 2014 - Submission to the= IESG of the Internet-Draft for a

> protocol and data format for = retrieving configuration and policy

> information for driving data= collection and analysis for consideration

=

> as standards-track RF= C

> 

> Oct. 2014 - Submission to the IESG of the Int= ernet-Draft a protocol

> and data format for collecting actual end= point posture for

> consideration as standards- track RFC

&g= t; 

> This message and attachments may contain confidential= information.  If

> it appears that this message was sen= t to you by mistake, any

> retention, dissemination, distribution = or copying of this message and

> attachments is strictly prohibite= d.  Please notify the sender

> immediately and permanent= ly delete the message and any attachments.

=

...

<= /div>

&nb= sp;

This message and attachments may contain confidential information= .  If it appears that this message was sent to you by mistake, an= y retention, dissemination, distribution or copying of this message and att= achments is strictly prohibited.  Please notify the sender immedi= ately and permanently delete the message and any attachments.

_______= ________________________________________

sacm mailing list=

<= div>

https://www.ietf.org/mailman/listinfo/sacm=

 

=
...


This message an= d attachments may contain confidential information. If it appears that this= message was sent to you by mistake, any retention, dissemination, distribu= tion or copying of this message and attachments is strictly prohibited. Ple= ase notify the sender immediately and permanently delete the message and an= y attachments.

= --_000_F5063677821E3B4F81ACFB7905573F24DF027616MX15Acorpemccom_-- From shanna@juniper.net Mon Jun 10 15:13:13 2013 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 1C17821E8094 for ; Mon, 10 Jun 2013 15:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 qyGq75d4ZgSe for ; Mon, 10 Jun 2013 15:13:06 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0C32721E804B for ; Mon, 10 Jun 2013 15:13:05 -0700 (PDT) Received: from mail142-va3-R.bigfish.com (10.7.14.233) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Jun 2013 22:13:05 +0000 Received: from mail142-va3 (localhost [127.0.0.1]) by mail142-va3-R.bigfish.com (Postfix) with ESMTP id 543FB420099 for ; Mon, 10 Jun 2013 22:13:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: PS-37(zz9371I1431J9f17Rc85fh542I1432I1418I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1c8fb4h18602eh8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail142-va3: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=shanna@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail142-va3 (localhost.localdomain [127.0.0.1]) by mail142-va3 (MessageSwitch) id 1370902337709707_22958; Mon, 10 Jun 2013 22:12:17 +0000 (UTC) Received: from VA3EHSMHS039.bigfish.com (unknown [10.7.14.232]) by mail142-va3.bigfish.com (Postfix) with ESMTP id 9E5D13C010D for ; Mon, 10 Jun 2013 22:12:17 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by VA3EHSMHS039.bigfish.com (10.7.99.49) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Jun 2013 22:12:17 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Jun 2013 15:12:16 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 10 Jun 2013 15:12:15 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.248) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 10 Jun 2013 15:23:46 -0700 Received: from mail84-db9-R.bigfish.com (10.174.16.225) by DB9EHSOBE025.bigfish.com (10.174.14.88) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Jun 2013 22:12:12 +0000 Received: from mail84-db9 (localhost [127.0.0.1]) by mail84-db9-R.bigfish.com (Postfix) with ESMTP id 5F4E1E01BA for ; Mon, 10 Jun 2013 22:12:12 +0000 (UTC) Received: from mail84-db9 (localhost.localdomain [127.0.0.1]) by mail84-db9 (MessageSwitch) id 1370902284961600_9771; Mon, 10 Jun 2013 22:11:24 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.244]) by mail84-db9.bigfish.com (Postfix) with ESMTP id E4F29320049; Mon, 10 Jun 2013 22:11:24 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Jun 2013 22:11:24 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.13]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0311.000; Mon, 10 Jun 2013 22:11:16 +0000 From: Stephen Hanna To: "Moriarty, Kathleen" , Adam Montville , "Kent_Landfield@McAfee.com" , "david.waltermire@nist.gov" , "Field, John (Pivotal)" Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6sTB6NtW1w0unBSJfMGLGYpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAAZTgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAAFEEAgAACowCAAAM+AIAAAV2AgAAD9YCAAALaoIAACl7ggAADDHA= Date: Mon, 10 Jun 2013 22:11:15 +0000 Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF28FA5D@MIVEXAMER1N1.corp.nai.org> <05BCCEB107AF88469B9F99783D47C1D66F4FE0@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C25BSN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%EMC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISECURITY.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MCAFEE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NIST.GOV$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GOPIVOTAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%THREATGUARD.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%STOICSECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "Gunnar.Engelbach@threatguard.com" , "turners@ieca.com" , "adam@stoicsecurity.com" , "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:13:13 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C25BSN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good point. Never mind. Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Monday, June 10, 2013 6:02 PM To: Stephen Hanna; Adam Montville; Kent_Landfield@McAfee.com; david.walterm= ire@nist.gov; Field, John (Pivotal) Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.= com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text A similar sentence is already there for NEA, which trigged the request for = the addition. The thought was more to make sure people understand that the= transports are flexible and can carry any data formats, they are not speci= fic to data formats in MILE. If GRC-Exchange gets revived, that would be a= clear example. Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Stephen Hanna Sent: Monday, June 10, 2013 5:25 PM To: Adam Montville; Kent_Landfield@McAfee.com; david.waltermire@nist.gov; Field, J= ohn (Pivotal) Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text Let's not add redundant text. Otherwise, we'll need to add more sentences s= aying that transports and data formats may come from NEA and so forth. Either way, I'm +1 on sending the revised charter to Sean. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Monday, June 10, 2013 5:13 PM To: Kent_Landfield@McAfee.com; david.walt= ermire@nist.gov; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I agree that it is already covered, but because the additional sentence doe= sn't mention any specific transport or data format, I don't think there is = any harm by including it. Adam From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 1:59 PM To: david.waltermire@nist.gov; Adam Montv= ille; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text I think that was the sentence Kathleen said she wanted. Just wanted to ver= ify... I agree it is already covered but if it is a bit more useful by bei= ng called out directly, I am ok with that too. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Monday, June 10, 2013 3:53 PM To: Kent Landfield >, "Adam.Montville@cisecurity.org= " >, "j= field@gopivotal.com" > Cc: Gunnar Engelbach >, Sean Turner >, "adam@stoicsecurity.com" >, "sacm@ietf.org" > Subject: RE: [sacm] Updated Candidate Charter Text Kent's sentence is fine with me, although it is covered by the other text i= n the charter: "The working group will, whenever reasonable and possible, reuse existing p= rotocols, mechanisms, information and data models." "There are common "problems" found in SACM, that may be addressed by the wo= rk done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.= " Unless I am missing something, I think we have already said as much in the = existing text. Dave From: Kent_Landfield@McAfee.com [mailto:K= ent_Landfield@McAfee.com] Sent: Monday, June 10, 2013 4:42 PM To: Adam.Montville@cisecurity.org; Wa= ltermire, David A.; jfield@gopivotal.com Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicsecurity.com; sacm@ietf.org Subject: Re: [sacm] Updated Candidate Charter Text If the sentence is "Transports from MILE may be used by SACM." I have no pr= oblem with it. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Monday, June 10, 2013 3:32 PM To: David Waltermire >, John Field > Cc: Gunnar Engelbach >, Sean Turner >, "Adam W. Montville" >, "sacm@ietf.org" > Subject: Re: [sacm] Updated Candidate Charter Text I think once we add the sentence Kathleen would like to see, we're probably= good. Any objections to that? -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov] Sent: Monday, June 10, 2013 12:20 PM To: Adam Montville; John Field Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org Subject: RE: [sacm] Updated Candidate Charter Text +1 for me. Are we good with handing this off to Sean today? Sincerely, Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Friday, June 07, 2013 6:36 PM > To: John Field > Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > David A.; sacm@ietf.org > Subject: RE: [sacm] Updated Candidate Charter Text > > Thanks John. I've modified the "ROLIE paragraph" by truncating the > last few sentences. Also, changed Boolean to predicate. > > Are there any further nits or really bad oversights in this copy of the charter? > > If you like it as it stands, +1 it. > > For me, +1 > > --------------------------------------------- > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual processes. > Standardized processes to collect, verify, and update security system > configurations would allow easier automation of the processes. > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. The initial focus of this work is to address enterprise use > cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are existing industry > standards, preferably IETF standards, that could support automation of > asset, change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This > area of focus provides for necessary language and data format specifications. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven assessment: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of mult= iple posture elements may be combined using predicate logic. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. > > This working group will achieve the following deliverables: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an overview of related standards work > Internet-Draft which will document existing work in the IETF or in > other SDOs which can be used as-is or as a starting point for > developing solutions to the SACM requirements. The working group may > decide to make of this document an Informational RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in > the IETF (including, but not limited to MILE and NEA) in order to > create solutions that do not overlap and can be used or re-used to > meet the goals of more than one working group. > > In accordance with existing IETF processes, the group will communicate > with and invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions > between itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository > for further analysis and action. NEA may also serve the purpose of > carrying data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, > creates enhanced situational awareness, thus enabling increased > understanding of current threats and mitigations. > > After the work items in the current charter have been submitted to and > approved by the IESG, the WG will recharter or close. > > Goals and Milestones > > Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > > Oct. 2013 - Initial submission of an Internet-Draft on Requirements > taking into consideration RFC5706 and RFC3535 > > Oct. 2013 - Initial submission of an Internet-Draft on SACM > Architecture > > Nov. 2013 - Initial submission of an Internet-Draft on overview of > related standards work > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for retrieving configuration and policy information for > driving data collection and analysis > > Jan. 2014 - Initial submission of an Internet-Draft for a protocol and > data format for collecting actual endpoint posture > > Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases > for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on > Requirements for consideration as Informational RFC > > Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > Architecture for consideration as Informational RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft for a > protocol and data format for retrieving configuration and policy > information for driving data collection and analysis for consideration > as standards-track RFC > > Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol > and data format for collecting actual endpoint posture for > consideration as standards- track RFC > > 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. ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. --_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C25BSN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good point. Never mind.

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Monday, June 10, 2013 6:02 PM
To: Stephen Hanna; Adam Montville; Kent_Landfield@McAfee.com; david.= waltermire@nist.gov; Field, John (Pivotal)
Cc: Gunnar.Engelbach@threatguard.com; turners@ieca.com; adam@stoicse= curity.com; sacm@ietf.org
Subject: Re: [sacm] Updated Candidate Charter Text=

 

A similar sentence is alr= eady there for NEA, which trigged the request for the addition.  The t= hought was more to make sure people understand that the transports are flexible and can carry any data formats, they are not specific to data= formats in MILE.  If GRC-Exchange gets revived, that would be a clear= example.

 <= /p>

Thanks,=

Kathleen

 <= /p>

 

Let’s not add redun= dant text. Otherwise, we’ll need to add more sentences saying that tr= ansports and data formats may come from NEA and so forth.=

 <= /p>

Either way, I’m = 3;1 on sending the revised charter to Sean.

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

 

I agree that it is alread= y covered, but because the additional sentence doesn’t mention any sp= ecific transport or data format, I don’t think there is any harm by including it.

 <= /p>

Adam

 <= /p>

 

 =

 =

Kent’s sentence is = fine with me, although it is covered by the other text in the charter:

 

“The working group = will, whenever reasonable and possible, reuse existing protocols, mechanism= s, information and data models.”

“There are common &= quot;problems" found in SACM, that may be addressed by the work done i= n SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others.”

 

Unless I am missing somet= hing, I think we have already said as much in the existing text.

 

Dave

 =

 

 

 =

 =

From: Adam Montville <Adam.Montville@cisecurity.org>
Date: Monday, June 10, 2013 3:32 PM
To: David Waltermire <david.waltermire@nist.gov>, John Field <jfield@gopivotal.com>
Cc: Gunnar Engelbach <gunnar.engelbach@threatguard.com>, Sean Turner <turners@ieca.com>, "Adam W. Montvi= lle" <adam@stoicsecurity.= com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Updated Candidate Charter Text

 =

I think once we add the = sentence Kathleen would like to see, we're probably good.=

 =

Any objections to that?<= o:p>

 =

-----Original Message---= --

From: Waltermire, David = A. [mailto:david.waltermire@ni= st.gov]

Sent: Monday, June 10, 2= 013 12:20 PM

To: Adam Montville; John= Field

Cc: Sean Turner; Gunnar = Engelbach; Adam W. Montville; sacm@ietf.org

Subject: RE: [sacm] Upda= ted Candidate Charter Text

+1 for me. &nbs= p;Are we good with handing this off to Sean today?

Sincerely,

Dave

> -----Original Messa= ge-----

> From: Adam Montvill= e [mailto:Adam.Montville@c= isecurity.org]

> Sent: Friday, June = 07, 2013 6:36 PM

> To: John Field=

> Cc: Sean Turner; Gu= nnar Engelbach; Adam W. Montville; Waltermire,

> David A.; sacm@ietf.org

> Subject: RE: [sacm]= Updated Candidate Charter Text

> 

> Thanks John. &= nbsp;I've modified the "ROLIE paragraph" by truncating the

> last few sentences.=   Also, changed Boolean to predicate.

> 

> Are there any furth= er nits or really bad oversights in this copy of the

charter?

> 

> If you like it as i= t stands, +1 it.

> 

> For me, +1=

> 

> -------------------= --------------------------

> 

> Securing informatio= n and the systems that store, process, and transmit

> that information is= a challenging task for organizations of all sizes,

> and many security p= ractitioners spend much of their time on manual

processes.

> Standardized proces= ses to collect, verify, and update security system

> configurations woul= d allow easier automation of the processes.

> Automating these ro= utine tasks would free security practitioners to

> focus on high prior= ity tasks, and should improve operators' ability to

> prioritize risk bas= ed on timely information about threats and

> vulnerabilities. Th= is working group will define security automation

> protocols and data = format standards in support of information security

> processes and pract= ices. These standards will help security

> practitioners to be= more effective by automating routine tasks related

> to client and serve= r security, freeing them to focus on more advanced

> tasks. The initial = focus of this work is to address enterprise use

> cases pertaining to= the assessment of endpoint posture (using the

definitions of Endpoint = and Posture from RFC 5209).

> 

> The working group w= ill, whenever reasonable and possible, reuse

> existing protocols,= mechanisms, information and data models. Of

> particular interest= to this working group are existing industry

> standards, preferab= ly IETF standards, that could support automation of

> asset, change, conf= iguration, and vulnerability management.

> 

> The working group w= ill define:

> 

> 1. A set of standar= ds to enable assessment of endpoint posture. This

> area of focus provi= des for necessary language and data format

specifications.

> 

> 2. A set of standar= ds for interacting with repositories of content

> related to assessme= nt of endpoint posture.

> 

> Assessment of endpo= int posture assessment entails the following

> general steps, whic= h accommodate policy-driven and asset-driven

assessment:

> 

> 1. Identify endpoin= ts

> 

> 2. Determine specif= ic endpoint elements to assess

> 

> 3. Collect actual v= alue of elements

> 

> 4. Compare actual e= lement values to expected element values

> 

> 5. Report results

> 

> This approach to en= dpoint posture collection enables multiple policies

> to be evaluated bas= ed on a single data collection activity. Policies

> will be evaluated b= y comparing available endpoint posture data

> according to rules = expressed in the policy. Typically, these rules

> will compare the ac= tual value against an expected value or range for

> specific posture el= ements. In some cases, the posture element may

> pertain to software= installation state, in which case the actual and

> expected values may= be "installed" or "not installed." Evaluation of multi= ple

posture elements may be = combined using predicate logic.

> 

> Repository protocol= s are needed to store, update, and retrieve

> configuration check= s and other types of content required for posture

> assessment (see ste= p 2 above).  A content repository is expected to

> house specific vers= ions of checklists (i.e. benchmarks), may be

> required to satisfy= different use cases (i.e. asset inventory,

> configuration setti= ngs, or vulnerabilities).  In addition, content=

> repositories are ex= pected to store up-to-date dictionary of specific

> enumerations, such = as those used for configuration element identifiers,

asset classifications, v= ulnerability identifiers, and so on.

> 

> This working group = will achieve the following deliverables:

> 

> - An Informational = document on Use Cases

> - An Informational = document on Requirements

> - An Informational = document on SACM Architecture

> - A standards-track= document specifying a protocol and data format for

> retrieving configur= ation and policy information for driving data

> collection and anal= ysis

> - A standards-track= document specifying a protocol and data format for

> collecting actual e= ndpoint posture

> 

> The working group w= ill create an overview of related standards work

> Internet-Draft whic= h will document existing work in the IETF or in

> other SDOs which ca= n be used as-is or as a starting point for

> developing solution= s to the SACM requirements. The working group may

> decide to make of t= his document an Informational RFC, but this is not a

mandatory deliverable.

> 

> The working group w= ill work in close coordination with other WGs in

> the IETF (including= , but not limited to MILE and NEA) in order to

> create solutions th= at do not overlap and can be used or re-used to

> meet the goals of m= ore than one working group.

> 

> In accordance with = existing IETF processes, the group will communicate

> with and invite par= ticipation from other relevant standards bodies and

> regulatory organiza= tions, and if necessary reuse existing liaison

> relationships or re= quest the establishment of new liaison relationships.

> 

> SACM-related effort= s are largely aligned, and may overlap, with other

> IETF (and non-IETF)= standardization efforts.  There are common "problems"<= o:p>

> found in SACM, that= may be addressed by the work done in SNMP, IPFIX,

> NETCONF, SYSLOG, NE= A, MILE, and potentially others.  Of particular=

> interest to SACM is= understanding and respecting the distinctions

> between itself and = NEA and MILE.

> 

> One way the NEA pro= tocols can be used is as the transport for data

> collected on the en= dpoint to an external service or data repository

> for further analysi= s and action.  NEA may also serve the purpose of

> carrying data-colle= ction instructions.

> 

> The MILE data forma= ts provide a format to describe incident,

> threat-related inci= dent, and indicator information.  SACM data formats

> provide ways to und= erstand what endpoints are in your environment,

> whether they meet p= olicy requirements, and their current configuration

> state.  T= he data exchanged in MILE, supplementing the SACM data,

> creates enhanced si= tuational awareness, thus enabling increased

> understanding of cu= rrent threats and mitigations.

> 

> After the work item= s in the current charter have been submitted to and

> approved by the IES= G, the WG will recharter or close.

> 

> Goals and Milestone= s

> 

> Sep. 2013 - Initial= submission of an Internet-Draft on Use Cases

> 

> Oct. 2013 - Initial= submission of an Internet-Draft on Requirements

> taking into conside= ration RFC5706 and RFC3535

> 

> Oct. 2013 - Initial= submission of an Internet-Draft on SACM

> Architecture

> 

> Nov. 2013 - Initial= submission of an Internet-Draft on overview of

> related standards w= ork

> 

> Jan. 2014 - Initial= submission of an Internet-Draft for a protocol and

> data format for ret= rieving configuration and policy information for

> driving data collec= tion and analysis

> 

> Jan. 2014 - Initial= submission of an Internet-Draft for a protocol and

> data format for col= lecting actual endpoint posture

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on Use Cases

> for consideration a= s Informational RFC

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on

> Requirements for co= nsideration as Informational RFC

> 

> Apr. 2014 - Submiss= ion to the IESG of the Internet-Draft on SACM

> Architecture for co= nsideration as Informational RFC

> 

> Oct. 2014 - Submiss= ion to the IESG of the Internet-Draft for a

> protocol and data f= ormat for retrieving configuration and policy

> information for dri= ving data collection and analysis for consideration

> as standards-track = RFC

> 

> Oct. 2014 - Submiss= ion to the IESG of the Internet-Draft a protocol

> and data format for= collecting actual endpoint posture for

> consideration as st= andards- track RFC

> 

> This message and at= tachments may contain confidential information.  If

> it appears that thi= s message was sent to you by mistake, any

> retention, dissemin= ation, distribution or copying of this message and

> attachments is stri= ctly prohibited.  Please notify the sender

> immediately and per= manently delete the message and any attachments.

...

 =

This message and attachm= ents may contain confidential information.  If it appears that th= is message was sent to you by mistake, any retention, dissemination, distri= bution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately an= d permanently delete the message and any attachments.

________________________= _______________________

sacm mailing list

 =


...


This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

--_000_F1DFC16DCAA7D3468651A5A776D5796E1AA2C25BSN2PRD0510MB372_-- From gunnar.engelbach@threatguard.com Mon Jun 10 16:05:19 2013 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 78F1421F9631 for ; Mon, 10 Jun 2013 16:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt37bwcChkjH for ; Mon, 10 Jun 2013 16:05:13 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id A6A2821F9399 for ; Mon, 10 Jun 2013 16:05:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=n7cC0l6SQ34hWC6hRB/mxhJvei3e9jWNelcelbkMs/jDXitF8qW2u4U5mRkUCuu0g5GzlbpO7ryIwPgaPNqqXnPtD94IxBqAGXK+8Bua2mZp1E9muF4FDaA2aQd30gvj; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 2162 invoked from network); 10 Jun 2013 16:16:55 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Jun 2013 16:16:54 -0700 Message-ID: <51B65BB5.2030005@ThreatGuard.com> Date: Mon, 10 Jun 2013 19:05:25 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Montville References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "adam@stoicsecurity.com" , "sacm@ietf.org" , "Field, John \(Pivotal\)" , "david.waltermire@nist.gov" , "turners@ieca.com" , "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:05:19 -0000 To me, the sentence introducing the general assessment steps still reads like there's only one expected approach to assessment. Michael Hammer suggested changing that from "Assessment of endpoint posture assessment entails the following general steps, which accommodate policy-driven and asset-driven assessment:" to: "An example of such an endpoint posture assessment could include, but is not limited to, the following general steps:" which is good enough for me. On 6/10/2013 4:32 PM, Adam Montville wrote: > I don't have an objection to adding that sentence. Other opinions? > >> -----Original Message----- >> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >> Sent: Monday, June 10, 2013 12:51 PM >> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov >> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville >> Subject: RE: [sacm] Updated Candidate Charter Text >> >> I am mostly a +1, but would add one sentence at the end of the MILE >> description to tie in options for ROLIE and other transports. >> >> Transports from MILE may be used by SACM. >> >> Thank you, >> Kathleen >> >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Kent_Landfield@McAfee.com >> Sent: Monday, June 10, 2013 3:35 PM >> To: david.waltermire@nist.gov >> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >> Gunnar.Engelbach@threatguard.com; turners@ieca.com; >> Adam.Montville@cisecurity.org >> Subject: Re: [sacm] Updated Candidate Charter Text >> >> +1 for me. >> >> Kent Landfield >> McAfee Labs >> Kent_Landfield@McAfee.com >> +1.817.637.8026 >> >> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." >> wrote: >> >>> +1 for me. Are we good with handing this off to Sean today? >>> >>> Sincerely, >>> Dave >>> >>>> -----Original Message----- >>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >>>> Sent: Friday, June 07, 2013 6:36 PM >>>> To: John Field >>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, >>>> David A.; sacm@ietf.org >>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>> >>>> Thanks John. I've modified the "ROLIE paragraph" by truncating the >>>> last few sentences. Also, changed Boolean to predicate. >>>> >>>> Are there any further nits or really bad oversights in this copy of the >> charter? >>>> >>>> If you like it as it stands, +1 it. >>>> >>>> For me, +1 >>>> >>>> --------------------------------------------- >>>> >>>> Securing information and the systems that store, process, and >>>> transmit that information is a challenging task for organizations of >>>> all sizes, and many security practitioners spend much of their time on >> manual processes. >>>> Standardized processes to collect, verify, and update security system >>>> configurations would allow easier automation of the processes. >>>> Automating these routine tasks would free security practitioners to >>>> focus on high priority tasks, and should improve operators' ability >>>> to prioritize risk based on timely information about threats and >>>> vulnerabilities. This working group will define security automation >>>> protocols and data format standards in support of information >>>> security processes and practices. These standards will help security >>>> practitioners to be more effective by automating routine tasks >>>> related to client and server security, freeing them to focus on more >>>> advanced tasks. The initial focus of this work is to address >>>> enterprise use cases pertaining to the assessment of endpoint posture >> (using the definitions of Endpoint and Posture from RFC 5209). >>>> >>>> The working group will, whenever reasonable and possible, reuse >>>> existing protocols, mechanisms, information and data models. Of >>>> particular interest to this working group are existing industry >>>> standards, preferably IETF standards, that could support automation >>>> of asset, change, configuration, and vulnerability management. >>>> >>>> The working group will define: >>>> >>>> 1. A set of standards to enable assessment of endpoint posture. This >>>> area of focus provides for necessary language and data format >> specifications. >>>> >>>> 2. A set of standards for interacting with repositories of content >>>> related to assessment of endpoint posture. >>>> >>>> Assessment of endpoint posture assessment entails the following >>>> general steps, which accommodate policy-driven and asset-driven >> assessment: >>>> >>>> 1. Identify endpoints >>>> >>>> 2. Determine specific endpoint elements to assess >>>> >>>> 3. Collect actual value of elements >>>> >>>> 4. Compare actual element values to expected element values >>>> >>>> 5. Report results >>>> >>>> This approach to endpoint posture collection enables multiple >>>> policies to be evaluated based on a single data collection activity. >>>> Policies will be evaluated by comparing available endpoint posture >>>> data according to rules expressed in the policy. Typically, these >>>> rules will compare the actual value against an expected value or >>>> range for specific posture elements. In some cases, the posture >>>> element may pertain to software installation state, in which case the >>>> actual and expected values may be "installed" or "not installed." >> Evaluation of multiple posture elements may be combined using predicate >> logic. >>>> >>>> Repository protocols are needed to store, update, and retrieve >>>> configuration checks and other types of content required for posture >>>> assessment (see step 2 above). A content repository is expected to >>>> house specific versions of checklists (i.e. benchmarks), may be >>>> required to satisfy different use cases (i.e. asset inventory, >>>> configuration settings, or vulnerabilities). In addition, content >>>> repositories are expected to store up-to-date dictionary of specific >>>> enumerations, such as those used for configuration element identifiers, >> asset classifications, vulnerability identifiers, and so on. >>>> >>>> This working group will achieve the following deliverables: >>>> >>>> - An Informational document on Use Cases >>>> - An Informational document on Requirements >>>> - An Informational document on SACM Architecture >>>> - A standards-track document specifying a protocol and data format >>>> for retrieving configuration and policy information for driving data >>>> collection and analysis >>>> - A standards-track document specifying a protocol and data format >>>> for collecting actual endpoint posture >>>> >>>> The working group will create an overview of related standards work >>>> Internet-Draft which will document existing work in the IETF or in >>>> other SDOs which can be used as-is or as a starting point for >>>> developing solutions to the SACM requirements. The working group may >>>> decide to make of this document an Informational RFC, but this is not a >> mandatory deliverable. >>>> >>>> The working group will work in close coordination with other WGs in >>>> the IETF (including, but not limited to MILE and NEA) in order to >>>> create solutions that do not overlap and can be used or re-used to >>>> meet the goals of more than one working group. >>>> >>>> In accordance with existing IETF processes, the group will >>>> communicate with and invite participation from other relevant >>>> standards bodies and regulatory organizations, and if necessary reuse >>>> existing liaison relationships or request the establishment of new liaison >> relationships. >>>> >>>> SACM-related efforts are largely aligned, and may overlap, with other >>>> IETF (and non-IETF) standardization efforts. There are common >> "problems" >>>> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular >>>> interest to SACM is understanding and respecting the distinctions >>>> between itself and NEA and MILE. >>>> >>>> One way the NEA protocols can be used is as the transport for data >>>> collected on the endpoint to an external service or data repository >>>> for further analysis and action. NEA may also serve the purpose of >>>> carrying data-collection instructions. >>>> >>>> The MILE data formats provide a format to describe incident, >>>> threat-related incident, and indicator information. SACM data >>>> formats provide ways to understand what endpoints are in your >>>> environment, whether they meet policy requirements, and their current >>>> configuration state. The data exchanged in MILE, supplementing the >>>> SACM data, creates enhanced situational awareness, thus enabling >>>> increased understanding of current threats and mitigations. >>>> >>>> After the work items in the current charter have been submitted to >>>> and approved by the IESG, the WG will recharter or close. >>>> >>>> Goals and Milestones >>>> >>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>> >>>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>>> taking into consideration RFC5706 and RFC3535 >>>> >>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>> Architecture >>>> >>>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>>> related standards work >>>> >>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>> and data format for retrieving configuration and policy information >>>> for driving data collection and analysis >>>> >>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>> and data format for collecting actual endpoint posture >>>> >>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases >>>> for consideration as Informational RFC >>>> >>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>> Requirements for consideration as Informational RFC >>>> >>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>>> Architecture for consideration as Informational RFC >>>> >>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>> protocol and data format for retrieving configuration and policy >>>> information for driving data collection and analysis for >>>> consideration as standards-track RFC >>>> >>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol >>>> and data format for collecting actual endpoint posture for >>>> consideration as standards- track RFC >>>> >>>> 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. >>> _______________________________________________ >>> 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 >> >> ... > > 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 turners@ieca.com Tue Jun 11 08:48:04 2013 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 A259721F99E3 for ; Tue, 11 Jun 2013 08:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.241 X-Spam-Level: X-Spam-Status: No, score=-102.241 tagged_above=-999 required=5 tests=[AWL=0.024, 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 eelFNhXA2FTc for ; Tue, 11 Jun 2013 08:47:59 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.170.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26121F99BB for ; Tue, 11 Jun 2013 08:47:59 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id F0F757505F838; Tue, 11 Jun 2013 10:47:48 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id A82407505F65D for ; Tue, 11 Jun 2013 10:47:48 -0500 (CDT) Received: from [173.73.135.101] (port=49475 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UmQna-0002CN-NE; Tue, 11 Jun 2013 10:47:54 -0500 Message-ID: <51B746A9.9010008@ieca.com> Date: Tue, 11 Jun 2013 11:47:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gunnar Engelbach References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> In-Reply-To: <51B65BB5.2030005@ThreatGuard.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:49475 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "adam@stoicsecurity.com" , "sacm@ietf.org" , Adam Montville , "Field, John \(Pivotal\)" , "david.waltermire@nist.gov" , "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:48:04 -0000 I think this is a reasonable suggestion and unless I hear otherwise I'm going to add it to the charter. spt On 6/10/13 7:05 PM, Gunnar Engelbach wrote: > > To me, the sentence introducing the general assessment steps still reads > like there's only one expected approach to assessment. > > > Michael Hammer suggested changing that from > > "Assessment of endpoint posture assessment entails the following > general steps, which accommodate policy-driven and asset-driven > assessment:" > > > to: > > > "An example of such an endpoint posture assessment could include, but is > not limited to, the following general steps:" > > > which is good enough for me. > > > > On 6/10/2013 4:32 PM, Adam Montville wrote: >> I don't have an objection to adding that sentence. Other opinions? >> >>> -----Original Message----- >>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>> Sent: Monday, June 10, 2013 12:51 PM >>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov >>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville >>> Subject: RE: [sacm] Updated Candidate Charter Text >>> >>> I am mostly a +1, but would add one sentence at the end of the MILE >>> description to tie in options for ROLIE and other transports. >>> >>> Transports from MILE may be used by SACM. >>> >>> Thank you, >>> Kathleen >>> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Kent_Landfield@McAfee.com >>> Sent: Monday, June 10, 2013 3:35 PM >>> To: david.waltermire@nist.gov >>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; >>> Adam.Montville@cisecurity.org >>> Subject: Re: [sacm] Updated Candidate Charter Text >>> >>> +1 for me. >>> >>> Kent Landfield >>> McAfee Labs >>> Kent_Landfield@McAfee.com >>> +1.817.637.8026 >>> >>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." >>> wrote: >>> >>>> +1 for me. Are we good with handing this off to Sean today? >>>> >>>> Sincerely, >>>> Dave >>>> >>>>> -----Original Message----- >>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >>>>> Sent: Friday, June 07, 2013 6:36 PM >>>>> To: John Field >>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, >>>>> David A.; sacm@ietf.org >>>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>>> >>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating the >>>>> last few sentences. Also, changed Boolean to predicate. >>>>> >>>>> Are there any further nits or really bad oversights in this copy of >>>>> the >>> charter? >>>>> >>>>> If you like it as it stands, +1 it. >>>>> >>>>> For me, +1 >>>>> >>>>> --------------------------------------------- >>>>> >>>>> Securing information and the systems that store, process, and >>>>> transmit that information is a challenging task for organizations of >>>>> all sizes, and many security practitioners spend much of their time on >>> manual processes. >>>>> Standardized processes to collect, verify, and update security system >>>>> configurations would allow easier automation of the processes. >>>>> Automating these routine tasks would free security practitioners to >>>>> focus on high priority tasks, and should improve operators' ability >>>>> to prioritize risk based on timely information about threats and >>>>> vulnerabilities. This working group will define security automation >>>>> protocols and data format standards in support of information >>>>> security processes and practices. These standards will help security >>>>> practitioners to be more effective by automating routine tasks >>>>> related to client and server security, freeing them to focus on more >>>>> advanced tasks. The initial focus of this work is to address >>>>> enterprise use cases pertaining to the assessment of endpoint posture >>> (using the definitions of Endpoint and Posture from RFC 5209). >>>>> >>>>> The working group will, whenever reasonable and possible, reuse >>>>> existing protocols, mechanisms, information and data models. Of >>>>> particular interest to this working group are existing industry >>>>> standards, preferably IETF standards, that could support automation >>>>> of asset, change, configuration, and vulnerability management. >>>>> >>>>> The working group will define: >>>>> >>>>> 1. A set of standards to enable assessment of endpoint posture. This >>>>> area of focus provides for necessary language and data format >>> specifications. >>>>> >>>>> 2. A set of standards for interacting with repositories of content >>>>> related to assessment of endpoint posture. >>>>> >>>>> Assessment of endpoint posture assessment entails the following >>>>> general steps, which accommodate policy-driven and asset-driven >>> assessment: >>>>> >>>>> 1. Identify endpoints >>>>> >>>>> 2. Determine specific endpoint elements to assess >>>>> >>>>> 3. Collect actual value of elements >>>>> >>>>> 4. Compare actual element values to expected element values >>>>> >>>>> 5. Report results >>>>> >>>>> This approach to endpoint posture collection enables multiple >>>>> policies to be evaluated based on a single data collection activity. >>>>> Policies will be evaluated by comparing available endpoint posture >>>>> data according to rules expressed in the policy. Typically, these >>>>> rules will compare the actual value against an expected value or >>>>> range for specific posture elements. In some cases, the posture >>>>> element may pertain to software installation state, in which case the >>>>> actual and expected values may be "installed" or "not installed." >>> Evaluation of multiple posture elements may be combined using predicate >>> logic. >>>>> >>>>> Repository protocols are needed to store, update, and retrieve >>>>> configuration checks and other types of content required for posture >>>>> assessment (see step 2 above). A content repository is expected to >>>>> house specific versions of checklists (i.e. benchmarks), may be >>>>> required to satisfy different use cases (i.e. asset inventory, >>>>> configuration settings, or vulnerabilities). In addition, content >>>>> repositories are expected to store up-to-date dictionary of specific >>>>> enumerations, such as those used for configuration element >>>>> identifiers, >>> asset classifications, vulnerability identifiers, and so on. >>>>> >>>>> This working group will achieve the following deliverables: >>>>> >>>>> - An Informational document on Use Cases >>>>> - An Informational document on Requirements >>>>> - An Informational document on SACM Architecture >>>>> - A standards-track document specifying a protocol and data format >>>>> for retrieving configuration and policy information for driving data >>>>> collection and analysis >>>>> - A standards-track document specifying a protocol and data format >>>>> for collecting actual endpoint posture >>>>> >>>>> The working group will create an overview of related standards work >>>>> Internet-Draft which will document existing work in the IETF or in >>>>> other SDOs which can be used as-is or as a starting point for >>>>> developing solutions to the SACM requirements. The working group may >>>>> decide to make of this document an Informational RFC, but this is >>>>> not a >>> mandatory deliverable. >>>>> >>>>> The working group will work in close coordination with other WGs in >>>>> the IETF (including, but not limited to MILE and NEA) in order to >>>>> create solutions that do not overlap and can be used or re-used to >>>>> meet the goals of more than one working group. >>>>> >>>>> In accordance with existing IETF processes, the group will >>>>> communicate with and invite participation from other relevant >>>>> standards bodies and regulatory organizations, and if necessary reuse >>>>> existing liaison relationships or request the establishment of new >>>>> liaison >>> relationships. >>>>> >>>>> SACM-related efforts are largely aligned, and may overlap, with other >>>>> IETF (and non-IETF) standardization efforts. There are common >>> "problems" >>>>> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular >>>>> interest to SACM is understanding and respecting the distinctions >>>>> between itself and NEA and MILE. >>>>> >>>>> One way the NEA protocols can be used is as the transport for data >>>>> collected on the endpoint to an external service or data repository >>>>> for further analysis and action. NEA may also serve the purpose of >>>>> carrying data-collection instructions. >>>>> >>>>> The MILE data formats provide a format to describe incident, >>>>> threat-related incident, and indicator information. SACM data >>>>> formats provide ways to understand what endpoints are in your >>>>> environment, whether they meet policy requirements, and their current >>>>> configuration state. The data exchanged in MILE, supplementing the >>>>> SACM data, creates enhanced situational awareness, thus enabling >>>>> increased understanding of current threats and mitigations. >>>>> >>>>> After the work items in the current charter have been submitted to >>>>> and approved by the IESG, the WG will recharter or close. >>>>> >>>>> Goals and Milestones >>>>> >>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>>> >>>>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>>>> taking into consideration RFC5706 and RFC3535 >>>>> >>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>>> Architecture >>>>> >>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>>>> related standards work >>>>> >>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>> and data format for retrieving configuration and policy information >>>>> for driving data collection and analysis >>>>> >>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>> and data format for collecting actual endpoint posture >>>>> >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases >>>>> for consideration as Informational RFC >>>>> >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>>> Requirements for consideration as Informational RFC >>>>> >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>>>> Architecture for consideration as Informational RFC >>>>> >>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>>> protocol and data format for retrieving configuration and policy >>>>> information for driving data collection and analysis for >>>>> consideration as standards-track RFC >>>>> >>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol >>>>> and data format for collecting actual endpoint posture for >>>>> consideration as standards- track RFC >>>>> >>>>> 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. >>>> _______________________________________________ >>>> 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 >>> >>> ... >> >> 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 adam@stoicsecurity.com Tue Jun 11 08:50:17 2013 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 6EB5721F86C0 for ; Tue, 11 Jun 2013 08:50:16 -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 EXDm9i2336Zs for ; Tue, 11 Jun 2013 08:50:11 -0700 (PDT) Received: from m1plsmtpa01-02.prod.mesa1.secureserver.net (m1plsmtpa01-02.prod.mesa1.secureserver.net [64.202.165.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0C521F874E for ; Tue, 11 Jun 2013 08:50:11 -0700 (PDT) Received: from [192.168.1.4] ([71.59.203.52]) by m1plsmtpa01-02.prod.mesa1.secureserver.net with id n3q71l00K18LdGv013q7rW; Tue, 11 Jun 2013 08:50:10 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Adam W. Montville" In-Reply-To: <51B746A9.9010008@ieca.com> Date: Tue, 11 Jun 2013 08:50:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93602198-6F22-4D5E-A8A0-4F76292F6408@stoicsecurity.com> References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A 9.9010008@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1508) Cc: "sacm@ietf.org" , Adam Montville , "Field, John \(Pivotal\)" , Gunnar Engelbach , "david.waltermire@nist.gov" , "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:50:17 -0000 +1 On Jun 11, 2013, at 8:47 AM, Sean Turner wrote: > I think this is a reasonable suggestion and unless I hear otherwise = I'm going to add it to the charter. >=20 > spt >=20 > On 6/10/13 7:05 PM, Gunnar Engelbach wrote: >>=20 >> To me, the sentence introducing the general assessment steps still = reads >> like there's only one expected approach to assessment. >>=20 >>=20 >> Michael Hammer suggested changing that from >>=20 >> "Assessment of endpoint posture assessment entails the following >> general steps, which accommodate policy-driven and asset-driven >> assessment:" >>=20 >>=20 >> to: >>=20 >>=20 >> "An example of such an endpoint posture assessment could include, but = is >> not limited to, the following general steps:" >>=20 >>=20 >> which is good enough for me. >>=20 >>=20 >>=20 >> On 6/10/2013 4:32 PM, Adam Montville wrote: >>> I don't have an objection to adding that sentence. Other opinions? >>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>>> Sent: Monday, June 10, 2013 12:51 PM >>>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville >>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>>=20 >>>> I am mostly a +1, but would add one sentence at the end of the MILE >>>> description to tie in options for ROLIE and other transports. >>>>=20 >>>> Transports from MILE may be used by SACM. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On = Behalf Of >>>> Kent_Landfield@McAfee.com >>>> Sent: Monday, June 10, 2013 3:35 PM >>>> To: david.waltermire@nist.gov >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; >>>> Adam.Montville@cisecurity.org >>>> Subject: Re: [sacm] Updated Candidate Charter Text >>>>=20 >>>> +1 for me. >>>>=20 >>>> Kent Landfield >>>> McAfee Labs >>>> Kent_Landfield@McAfee.com >>>> +1.817.637.8026 >>>>=20 >>>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." >>>> wrote: >>>>=20 >>>>> +1 for me. Are we good with handing this off to Sean today? >>>>>=20 >>>>> Sincerely, >>>>> Dave >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >>>>>> Sent: Friday, June 07, 2013 6:36 PM >>>>>> To: John Field >>>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, >>>>>> David A.; sacm@ietf.org >>>>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>>>>=20 >>>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating = the >>>>>> last few sentences. Also, changed Boolean to predicate. >>>>>>=20 >>>>>> Are there any further nits or really bad oversights in this copy = of >>>>>> the >>>> charter? >>>>>>=20 >>>>>> If you like it as it stands, +1 it. >>>>>>=20 >>>>>> For me, +1 >>>>>>=20 >>>>>> --------------------------------------------- >>>>>>=20 >>>>>> Securing information and the systems that store, process, and >>>>>> transmit that information is a challenging task for organizations = of >>>>>> all sizes, and many security practitioners spend much of their = time on >>>> manual processes. >>>>>> Standardized processes to collect, verify, and update security = system >>>>>> configurations would allow easier automation of the processes. >>>>>> Automating these routine tasks would free security practitioners = to >>>>>> focus on high priority tasks, and should improve operators' = ability >>>>>> to prioritize risk based on timely information about threats and >>>>>> vulnerabilities. This working group will define security = automation >>>>>> protocols and data format standards in support of information >>>>>> security processes and practices. These standards will help = security >>>>>> practitioners to be more effective by automating routine tasks >>>>>> related to client and server security, freeing them to focus on = more >>>>>> advanced tasks. The initial focus of this work is to address >>>>>> enterprise use cases pertaining to the assessment of endpoint = posture >>>> (using the definitions of Endpoint and Posture from RFC 5209). >>>>>>=20 >>>>>> The working group will, whenever reasonable and possible, reuse >>>>>> existing protocols, mechanisms, information and data models. Of >>>>>> particular interest to this working group are existing industry >>>>>> standards, preferably IETF standards, that could support = automation >>>>>> of asset, change, configuration, and vulnerability management. >>>>>>=20 >>>>>> The working group will define: >>>>>>=20 >>>>>> 1. A set of standards to enable assessment of endpoint posture. = This >>>>>> area of focus provides for necessary language and data format >>>> specifications. >>>>>>=20 >>>>>> 2. A set of standards for interacting with repositories of = content >>>>>> related to assessment of endpoint posture. >>>>>>=20 >>>>>> Assessment of endpoint posture assessment entails the following >>>>>> general steps, which accommodate policy-driven and asset-driven >>>> assessment: >>>>>>=20 >>>>>> 1. Identify endpoints >>>>>>=20 >>>>>> 2. Determine specific endpoint elements to assess >>>>>>=20 >>>>>> 3. Collect actual value of elements >>>>>>=20 >>>>>> 4. Compare actual element values to expected element values >>>>>>=20 >>>>>> 5. Report results >>>>>>=20 >>>>>> This approach to endpoint posture collection enables multiple >>>>>> policies to be evaluated based on a single data collection = activity. >>>>>> Policies will be evaluated by comparing available endpoint = posture >>>>>> data according to rules expressed in the policy. Typically, these >>>>>> rules will compare the actual value against an expected value or >>>>>> range for specific posture elements. In some cases, the posture >>>>>> element may pertain to software installation state, in which case = the >>>>>> actual and expected values may be "installed" or "not installed." >>>> Evaluation of multiple posture elements may be combined using = predicate >>>> logic. >>>>>>=20 >>>>>> Repository protocols are needed to store, update, and retrieve >>>>>> configuration checks and other types of content required for = posture >>>>>> assessment (see step 2 above). A content repository is expected = to >>>>>> house specific versions of checklists (i.e. benchmarks), may be >>>>>> required to satisfy different use cases (i.e. asset inventory, >>>>>> configuration settings, or vulnerabilities). In addition, = content >>>>>> repositories are expected to store up-to-date dictionary of = specific >>>>>> enumerations, such as those used for configuration element >>>>>> identifiers, >>>> asset classifications, vulnerability identifiers, and so on. >>>>>>=20 >>>>>> This working group will achieve the following deliverables: >>>>>>=20 >>>>>> - An Informational document on Use Cases >>>>>> - An Informational document on Requirements >>>>>> - An Informational document on SACM Architecture >>>>>> - A standards-track document specifying a protocol and data = format >>>>>> for retrieving configuration and policy information for driving = data >>>>>> collection and analysis >>>>>> - A standards-track document specifying a protocol and data = format >>>>>> for collecting actual endpoint posture >>>>>>=20 >>>>>> The working group will create an overview of related standards = work >>>>>> Internet-Draft which will document existing work in the IETF or = in >>>>>> other SDOs which can be used as-is or as a starting point for >>>>>> developing solutions to the SACM requirements. The working group = may >>>>>> decide to make of this document an Informational RFC, but this is >>>>>> not a >>>> mandatory deliverable. >>>>>>=20 >>>>>> The working group will work in close coordination with other WGs = in >>>>>> the IETF (including, but not limited to MILE and NEA) in order to >>>>>> create solutions that do not overlap and can be used or re-used = to >>>>>> meet the goals of more than one working group. >>>>>>=20 >>>>>> In accordance with existing IETF processes, the group will >>>>>> communicate with and invite participation from other relevant >>>>>> standards bodies and regulatory organizations, and if necessary = reuse >>>>>> existing liaison relationships or request the establishment of = new >>>>>> liaison >>>> relationships. >>>>>>=20 >>>>>> SACM-related efforts are largely aligned, and may overlap, with = other >>>>>> IETF (and non-IETF) standardization efforts. There are common >>>> "problems" >>>>>> found in SACM, that may be addressed by the work done in SNMP, = IPFIX, >>>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of = particular >>>>>> interest to SACM is understanding and respecting the distinctions >>>>>> between itself and NEA and MILE. >>>>>>=20 >>>>>> One way the NEA protocols can be used is as the transport for = data >>>>>> collected on the endpoint to an external service or data = repository >>>>>> for further analysis and action. NEA may also serve the purpose = of >>>>>> carrying data-collection instructions. >>>>>>=20 >>>>>> The MILE data formats provide a format to describe incident, >>>>>> threat-related incident, and indicator information. SACM data >>>>>> formats provide ways to understand what endpoints are in your >>>>>> environment, whether they meet policy requirements, and their = current >>>>>> configuration state. The data exchanged in MILE, supplementing = the >>>>>> SACM data, creates enhanced situational awareness, thus enabling >>>>>> increased understanding of current threats and mitigations. >>>>>>=20 >>>>>> After the work items in the current charter have been submitted = to >>>>>> and approved by the IESG, the WG will recharter or close. >>>>>>=20 >>>>>> Goals and Milestones >>>>>>=20 >>>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>>>>=20 >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on = Requirements >>>>>> taking into consideration RFC5706 and RFC3535 >>>>>>=20 >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>>>> Architecture >>>>>>=20 >>>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview = of >>>>>> related standards work >>>>>>=20 >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a = protocol >>>>>> and data format for retrieving configuration and policy = information >>>>>> for driving data collection and analysis >>>>>>=20 >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a = protocol >>>>>> and data format for collecting actual endpoint posture >>>>>>=20 >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use = Cases >>>>>> for consideration as Informational RFC >>>>>>=20 >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>>>> Requirements for consideration as Informational RFC >>>>>>=20 >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>>>>> Architecture for consideration as Informational RFC >>>>>>=20 >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>>>> protocol and data format for retrieving configuration and policy >>>>>> information for driving data collection and analysis for >>>>>> consideration as standards-track RFC >>>>>>=20 >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a = protocol >>>>>> and data format for collecting actual endpoint posture for >>>>>> consideration as standards- track RFC >>>>>>=20 >>>>>> 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. >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>>=20 >>>> ... >>>=20 >>> 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. >>>=20 >>=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Tue Jun 11 08:57:13 2013 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 D0AB421F8C1A for ; Tue, 11 Jun 2013 08:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 ZaW7i5hdCwvR for ; Tue, 11 Jun 2013 08:57:08 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4621F8F6E for ; Tue, 11 Jun 2013 08:57:07 -0700 (PDT) Received: from mail174-va3-R.bigfish.com (10.7.14.232) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Jun 2013 15:57:00 +0000 Received: from mail174-va3 (localhost [127.0.0.1]) by mail174-va3-R.bigfish.com (Postfix) with ESMTP id D1AC1402EA for ; Tue, 11 Jun 2013 15:57:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail174-va3: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=shanna@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail174-va3 (localhost.localdomain [127.0.0.1]) by mail174-va3 (MessageSwitch) id 1370966189946405_26049; Tue, 11 Jun 2013 15:56:29 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.247]) by mail174-va3.bigfish.com (Postfix) with ESMTP id E259C1403BA for ; Tue, 11 Jun 2013 15:56:29 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Jun 2013 15:56:25 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 11 Jun 2013 08:56:22 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 11 Jun 2013 08:56:21 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 11 Jun 2013 09:00:07 -0700 Received: from mail31-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Jun 2013 15:56:17 +0000 Received: from mail31-ch1 (localhost [127.0.0.1]) by mail31-ch1-R.bigfish.com (Postfix) with ESMTP id 6659F60ABA for ; Tue, 11 Jun 2013 15:56:17 +0000 (UTC) Received: from mail31-ch1 (localhost.localdomain [127.0.0.1]) by mail31-ch1 (MessageSwitch) id 1370966174889325_12581; Tue, 11 Jun 2013 15:56:14 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail31-ch1.bigfish.com (Postfix) with ESMTP id D5EE24C0065; Tue, 11 Jun 2013 15:56:14 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Jun 2013 15:56:09 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.13]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0324.000; Tue, 11 Jun 2013 15:56:09 +0000 From: Stephen Hanna To: "Adam W. Montville" , Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6sTB6NtW1w0unBSJfMGLGYpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAAZTgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAABDeAgAAEUQCAAAuzgIAAKq2AgAEYFoCAAAChAIAAAajA Date: Tue, 11 Jun 2013 15:56:08 +0000 Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A 9.9010008@ieca.com> <93602198-6F22-4D5E-A8A0-4F76292F6408@stoicsecurity.com> In-Reply-To: <93602198-6F22-4D5E-A8A0-4F76292F6408@stoicsecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%STOICSECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISECURITY.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GOPIVOTAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%THREATGUARD.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NIST.GOV$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%EMC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MCAFEE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "sacm@ietf.org" , Adam Montville , "Field, John \(Pivotal\)" , Gunnar Engelbach , "david.waltermire@nist.gov" , "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:57:13 -0000 +1 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam W. Montville > Sent: Tuesday, June 11, 2013 11:50 AM > To: Sean Turner > Cc: sacm@ietf.org; Adam Montville; Field, John (Pivotal); Gunnar > Engelbach; david.waltermire@nist.gov; Moriarty, Kathleen; > Kent_Landfield@McAfee.com > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > +1 > On Jun 11, 2013, at 8:47 AM, Sean Turner wrote: >=20 > > I think this is a reasonable suggestion and unless I hear otherwise > I'm going to add it to the charter. > > > > spt > > > > On 6/10/13 7:05 PM, Gunnar Engelbach wrote: > >> > >> To me, the sentence introducing the general assessment steps still > reads > >> like there's only one expected approach to assessment. > >> > >> > >> Michael Hammer suggested changing that from > >> > >> "Assessment of endpoint posture assessment entails the following > >> general steps, which accommodate policy-driven and asset-driven > >> assessment:" > >> > >> > >> to: > >> > >> > >> "An example of such an endpoint posture assessment could include, > but is > >> not limited to, the following general steps:" > >> > >> > >> which is good enough for me. > >> > >> > >> > >> On 6/10/2013 4:32 PM, Adam Montville wrote: > >>> I don't have an objection to adding that sentence. Other opinions? > >>> > >>>> -----Original Message----- > >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > >>>> Sent: Monday, June 10, 2013 12:51 PM > >>>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov > >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville > >>>> Subject: RE: [sacm] Updated Candidate Charter Text > >>>> > >>>> I am mostly a +1, but would add one sentence at the end of the > MILE > >>>> description to tie in options for ROLIE and other transports. > >>>> > >>>> Transports from MILE may be used by SACM. > >>>> > >>>> Thank you, > >>>> Kathleen > >>>> > >>>> -----Original Message----- > >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf Of > >>>> Kent_Landfield@McAfee.com > >>>> Sent: Monday, June 10, 2013 3:35 PM > >>>> To: david.waltermire@nist.gov > >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; > >>>> Adam.Montville@cisecurity.org > >>>> Subject: Re: [sacm] Updated Candidate Charter Text > >>>> > >>>> +1 for me. > >>>> > >>>> Kent Landfield > >>>> McAfee Labs > >>>> Kent_Landfield@McAfee.com > >>>> +1.817.637.8026 > >>>> > >>>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." > >>>> wrote: > >>>> > >>>>> +1 for me. Are we good with handing this off to Sean today? > >>>>> > >>>>> Sincerely, > >>>>> Dave > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > >>>>>> Sent: Friday, June 07, 2013 6:36 PM > >>>>>> To: John Field > >>>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; > Waltermire, > >>>>>> David A.; sacm@ietf.org > >>>>>> Subject: RE: [sacm] Updated Candidate Charter Text > >>>>>> > >>>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating > the > >>>>>> last few sentences. Also, changed Boolean to predicate. > >>>>>> > >>>>>> Are there any further nits or really bad oversights in this copy > of > >>>>>> the > >>>> charter? > >>>>>> > >>>>>> If you like it as it stands, +1 it. > >>>>>> > >>>>>> For me, +1 > >>>>>> > >>>>>> --------------------------------------------- > >>>>>> > >>>>>> Securing information and the systems that store, process, and > >>>>>> transmit that information is a challenging task for > organizations of > >>>>>> all sizes, and many security practitioners spend much of their > time on > >>>> manual processes. > >>>>>> Standardized processes to collect, verify, and update security > system > >>>>>> configurations would allow easier automation of the processes. > >>>>>> Automating these routine tasks would free security practitioners > to > >>>>>> focus on high priority tasks, and should improve operators' > ability > >>>>>> to prioritize risk based on timely information about threats and > >>>>>> vulnerabilities. This working group will define security > automation > >>>>>> protocols and data format standards in support of information > >>>>>> security processes and practices. These standards will help > security > >>>>>> practitioners to be more effective by automating routine tasks > >>>>>> related to client and server security, freeing them to focus on > more > >>>>>> advanced tasks. The initial focus of this work is to address > >>>>>> enterprise use cases pertaining to the assessment of endpoint > posture > >>>> (using the definitions of Endpoint and Posture from RFC 5209). > >>>>>> > >>>>>> The working group will, whenever reasonable and possible, reuse > >>>>>> existing protocols, mechanisms, information and data models. Of > >>>>>> particular interest to this working group are existing industry > >>>>>> standards, preferably IETF standards, that could support > automation > >>>>>> of asset, change, configuration, and vulnerability management. > >>>>>> > >>>>>> The working group will define: > >>>>>> > >>>>>> 1. A set of standards to enable assessment of endpoint posture. > This > >>>>>> area of focus provides for necessary language and data format > >>>> specifications. > >>>>>> > >>>>>> 2. A set of standards for interacting with repositories of > content > >>>>>> related to assessment of endpoint posture. > >>>>>> > >>>>>> Assessment of endpoint posture assessment entails the following > >>>>>> general steps, which accommodate policy-driven and asset-driven > >>>> assessment: > >>>>>> > >>>>>> 1. Identify endpoints > >>>>>> > >>>>>> 2. Determine specific endpoint elements to assess > >>>>>> > >>>>>> 3. Collect actual value of elements > >>>>>> > >>>>>> 4. Compare actual element values to expected element values > >>>>>> > >>>>>> 5. Report results > >>>>>> > >>>>>> This approach to endpoint posture collection enables multiple > >>>>>> policies to be evaluated based on a single data collection > activity. > >>>>>> Policies will be evaluated by comparing available endpoint > posture > >>>>>> data according to rules expressed in the policy. Typically, > these > >>>>>> rules will compare the actual value against an expected value or > >>>>>> range for specific posture elements. In some cases, the posture > >>>>>> element may pertain to software installation state, in which > case the > >>>>>> actual and expected values may be "installed" or "not > installed." > >>>> Evaluation of multiple posture elements may be combined using > predicate > >>>> logic. > >>>>>> > >>>>>> Repository protocols are needed to store, update, and retrieve > >>>>>> configuration checks and other types of content required for > posture > >>>>>> assessment (see step 2 above). A content repository is expected > to > >>>>>> house specific versions of checklists (i.e. benchmarks), may be > >>>>>> required to satisfy different use cases (i.e. asset inventory, > >>>>>> configuration settings, or vulnerabilities). In addition, > content > >>>>>> repositories are expected to store up-to-date dictionary of > specific > >>>>>> enumerations, such as those used for configuration element > >>>>>> identifiers, > >>>> asset classifications, vulnerability identifiers, and so on. > >>>>>> > >>>>>> This working group will achieve the following deliverables: > >>>>>> > >>>>>> - An Informational document on Use Cases > >>>>>> - An Informational document on Requirements > >>>>>> - An Informational document on SACM Architecture > >>>>>> - A standards-track document specifying a protocol and data > format > >>>>>> for retrieving configuration and policy information for driving > data > >>>>>> collection and analysis > >>>>>> - A standards-track document specifying a protocol and data > format > >>>>>> for collecting actual endpoint posture > >>>>>> > >>>>>> The working group will create an overview of related standards > work > >>>>>> Internet-Draft which will document existing work in the IETF or > in > >>>>>> other SDOs which can be used as-is or as a starting point for > >>>>>> developing solutions to the SACM requirements. The working group > may > >>>>>> decide to make of this document an Informational RFC, but this > is > >>>>>> not a > >>>> mandatory deliverable. > >>>>>> > >>>>>> The working group will work in close coordination with other WGs > in > >>>>>> the IETF (including, but not limited to MILE and NEA) in order > to > >>>>>> create solutions that do not overlap and can be used or re-used > to > >>>>>> meet the goals of more than one working group. > >>>>>> > >>>>>> In accordance with existing IETF processes, the group will > >>>>>> communicate with and invite participation from other relevant > >>>>>> standards bodies and regulatory organizations, and if necessary > reuse > >>>>>> existing liaison relationships or request the establishment of > new > >>>>>> liaison > >>>> relationships. > >>>>>> > >>>>>> SACM-related efforts are largely aligned, and may overlap, with > other > >>>>>> IETF (and non-IETF) standardization efforts. There are common > >>>> "problems" > >>>>>> found in SACM, that may be addressed by the work done in SNMP, > IPFIX, > >>>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > particular > >>>>>> interest to SACM is understanding and respecting the > distinctions > >>>>>> between itself and NEA and MILE. > >>>>>> > >>>>>> One way the NEA protocols can be used is as the transport for > data > >>>>>> collected on the endpoint to an external service or data > repository > >>>>>> for further analysis and action. NEA may also serve the purpose > of > >>>>>> carrying data-collection instructions. > >>>>>> > >>>>>> The MILE data formats provide a format to describe incident, > >>>>>> threat-related incident, and indicator information. SACM data > >>>>>> formats provide ways to understand what endpoints are in your > >>>>>> environment, whether they meet policy requirements, and their > current > >>>>>> configuration state. The data exchanged in MILE, supplementing > the > >>>>>> SACM data, creates enhanced situational awareness, thus enabling > >>>>>> increased understanding of current threats and mitigations. > >>>>>> > >>>>>> After the work items in the current charter have been submitted > to > >>>>>> and approved by the IESG, the WG will recharter or close. > >>>>>> > >>>>>> Goals and Milestones > >>>>>> > >>>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > >>>>>> > >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on > Requirements > >>>>>> taking into consideration RFC5706 and RFC3535 > >>>>>> > >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM > >>>>>> Architecture > >>>>>> > >>>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview > of > >>>>>> related standards work > >>>>>> > >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a > protocol > >>>>>> and data format for retrieving configuration and policy > information > >>>>>> for driving data collection and analysis > >>>>>> > >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a > protocol > >>>>>> and data format for collecting actual endpoint posture > >>>>>> > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > Cases > >>>>>> for consideration as Informational RFC > >>>>>> > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on > >>>>>> Requirements for consideration as Informational RFC > >>>>>> > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > >>>>>> Architecture for consideration as Informational RFC > >>>>>> > >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a > >>>>>> protocol and data format for retrieving configuration and policy > >>>>>> information for driving data collection and analysis for > >>>>>> consideration as standards-track RFC > >>>>>> > >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a > protocol > >>>>>> and data format for collecting actual endpoint posture for > >>>>>> consideration as standards- track RFC > >>>>>> > >>>>>> 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. > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>>> ... > >>> > >>> 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. > >>> > >> > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From kathleen.moriarty@emc.com Tue Jun 11 08:58:57 2013 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 7FB4321F848A for ; Tue, 11 Jun 2013 08:58:56 -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 KXwV0dAgGsso for ; Tue, 11 Jun 2013 08:58:50 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0603B21F861F for ; Tue, 11 Jun 2013 08:58:49 -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 r5BFwYmV022458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 11:58:47 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 11 Jun 2013 11:58:17 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5BFwG7e029962; Tue, 11 Jun 2013 11:58:16 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Tue, 11 Jun 2013 11:58:16 -0400 From: "Moriarty, Kathleen" To: Sean Turner Date: Tue, 11 Jun 2013 11:58:15 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6sTB6NtW1w0unBSJfMGLGYpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAAZTgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAABDeAgAAEUQCAAAuzgIAAKq2AgAEYFoCAAAChAIAAAajAgAAAfnA= Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A 9.9010008@ieca.com> <93602198-6F22-4D5E-A8A0-4F76292F6408@stoicsecurity.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:58:58 -0000 +1 -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Tuesday, June 11, 2013 11:56 AM To: Adam W. Montville; Sean Turner Cc: sacm@ietf.org; Adam Montville; Field, John (Pivotal); Gunnar Engelbach;= david.waltermire@nist.gov; Moriarty, Kathleen; Kent_Landfield@McAfee.com Subject: RE: [sacm] Updated Candidate Charter Text +1 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam W. Montville > Sent: Tuesday, June 11, 2013 11:50 AM > To: Sean Turner > Cc: sacm@ietf.org; Adam Montville; Field, John (Pivotal); Gunnar > Engelbach; david.waltermire@nist.gov; Moriarty, Kathleen; > Kent_Landfield@McAfee.com > Subject: Re: [sacm] Updated Candidate Charter Text > > +1 > On Jun 11, 2013, at 8:47 AM, Sean Turner wrote: > > > I think this is a reasonable suggestion and unless I hear otherwise > I'm going to add it to the charter. > > > > spt > > > > On 6/10/13 7:05 PM, Gunnar Engelbach wrote: > >> > >> To me, the sentence introducing the general assessment steps still > reads > >> like there's only one expected approach to assessment. > >> > >> > >> Michael Hammer suggested changing that from > >> > >> "Assessment of endpoint posture assessment entails the following > >> general steps, which accommodate policy-driven and asset-driven > >> assessment:" > >> > >> > >> to: > >> > >> > >> "An example of such an endpoint posture assessment could include, > but is > >> not limited to, the following general steps:" > >> > >> > >> which is good enough for me. > >> > >> > >> > >> On 6/10/2013 4:32 PM, Adam Montville wrote: > >>> I don't have an objection to adding that sentence. Other opinions? > >>> > >>>> -----Original Message----- > >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > >>>> Sent: Monday, June 10, 2013 12:51 PM > >>>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov > >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville > >>>> Subject: RE: [sacm] Updated Candidate Charter Text > >>>> > >>>> I am mostly a +1, but would add one sentence at the end of the > MILE > >>>> description to tie in options for ROLIE and other transports. > >>>> > >>>> Transports from MILE may be used by SACM. > >>>> > >>>> Thank you, > >>>> Kathleen > >>>> > >>>> -----Original Message----- > >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf Of > >>>> Kent_Landfield@McAfee.com > >>>> Sent: Monday, June 10, 2013 3:35 PM > >>>> To: david.waltermire@nist.gov > >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; > >>>> Adam.Montville@cisecurity.org > >>>> Subject: Re: [sacm] Updated Candidate Charter Text > >>>> > >>>> +1 for me. > >>>> > >>>> Kent Landfield > >>>> McAfee Labs > >>>> Kent_Landfield@McAfee.com > >>>> +1.817.637.8026 > >>>> > >>>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." > >>>> wrote: > >>>> > >>>>> +1 for me. Are we good with handing this off to Sean today? > >>>>> > >>>>> Sincerely, > >>>>> Dave > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > >>>>>> Sent: Friday, June 07, 2013 6:36 PM > >>>>>> To: John Field > >>>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; > Waltermire, > >>>>>> David A.; sacm@ietf.org > >>>>>> Subject: RE: [sacm] Updated Candidate Charter Text > >>>>>> > >>>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating > the > >>>>>> last few sentences. Also, changed Boolean to predicate. > >>>>>> > >>>>>> Are there any further nits or really bad oversights in this copy > of > >>>>>> the > >>>> charter? > >>>>>> > >>>>>> If you like it as it stands, +1 it. > >>>>>> > >>>>>> For me, +1 > >>>>>> > >>>>>> --------------------------------------------- > >>>>>> > >>>>>> Securing information and the systems that store, process, and > >>>>>> transmit that information is a challenging task for > organizations of > >>>>>> all sizes, and many security practitioners spend much of their > time on > >>>> manual processes. > >>>>>> Standardized processes to collect, verify, and update security > system > >>>>>> configurations would allow easier automation of the processes. > >>>>>> Automating these routine tasks would free security practitioners > to > >>>>>> focus on high priority tasks, and should improve operators' > ability > >>>>>> to prioritize risk based on timely information about threats and > >>>>>> vulnerabilities. This working group will define security > automation > >>>>>> protocols and data format standards in support of information > >>>>>> security processes and practices. These standards will help > security > >>>>>> practitioners to be more effective by automating routine tasks > >>>>>> related to client and server security, freeing them to focus on > more > >>>>>> advanced tasks. The initial focus of this work is to address > >>>>>> enterprise use cases pertaining to the assessment of endpoint > posture > >>>> (using the definitions of Endpoint and Posture from RFC 5209). > >>>>>> > >>>>>> The working group will, whenever reasonable and possible, reuse > >>>>>> existing protocols, mechanisms, information and data models. Of > >>>>>> particular interest to this working group are existing industry > >>>>>> standards, preferably IETF standards, that could support > automation > >>>>>> of asset, change, configuration, and vulnerability management. > >>>>>> > >>>>>> The working group will define: > >>>>>> > >>>>>> 1. A set of standards to enable assessment of endpoint posture. > This > >>>>>> area of focus provides for necessary language and data format > >>>> specifications. > >>>>>> > >>>>>> 2. A set of standards for interacting with repositories of > content > >>>>>> related to assessment of endpoint posture. > >>>>>> > >>>>>> Assessment of endpoint posture assessment entails the following > >>>>>> general steps, which accommodate policy-driven and asset-driven > >>>> assessment: > >>>>>> > >>>>>> 1. Identify endpoints > >>>>>> > >>>>>> 2. Determine specific endpoint elements to assess > >>>>>> > >>>>>> 3. Collect actual value of elements > >>>>>> > >>>>>> 4. Compare actual element values to expected element values > >>>>>> > >>>>>> 5. Report results > >>>>>> > >>>>>> This approach to endpoint posture collection enables multiple > >>>>>> policies to be evaluated based on a single data collection > activity. > >>>>>> Policies will be evaluated by comparing available endpoint > posture > >>>>>> data according to rules expressed in the policy. Typically, > these > >>>>>> rules will compare the actual value against an expected value or > >>>>>> range for specific posture elements. In some cases, the posture > >>>>>> element may pertain to software installation state, in which > case the > >>>>>> actual and expected values may be "installed" or "not > installed." > >>>> Evaluation of multiple posture elements may be combined using > predicate > >>>> logic. > >>>>>> > >>>>>> Repository protocols are needed to store, update, and retrieve > >>>>>> configuration checks and other types of content required for > posture > >>>>>> assessment (see step 2 above). A content repository is expected > to > >>>>>> house specific versions of checklists (i.e. benchmarks), may be > >>>>>> required to satisfy different use cases (i.e. asset inventory, > >>>>>> configuration settings, or vulnerabilities). In addition, > content > >>>>>> repositories are expected to store up-to-date dictionary of > specific > >>>>>> enumerations, such as those used for configuration element > >>>>>> identifiers, > >>>> asset classifications, vulnerability identifiers, and so on. > >>>>>> > >>>>>> This working group will achieve the following deliverables: > >>>>>> > >>>>>> - An Informational document on Use Cases > >>>>>> - An Informational document on Requirements > >>>>>> - An Informational document on SACM Architecture > >>>>>> - A standards-track document specifying a protocol and data > format > >>>>>> for retrieving configuration and policy information for driving > data > >>>>>> collection and analysis > >>>>>> - A standards-track document specifying a protocol and data > format > >>>>>> for collecting actual endpoint posture > >>>>>> > >>>>>> The working group will create an overview of related standards > work > >>>>>> Internet-Draft which will document existing work in the IETF or > in > >>>>>> other SDOs which can be used as-is or as a starting point for > >>>>>> developing solutions to the SACM requirements. The working group > may > >>>>>> decide to make of this document an Informational RFC, but this > is > >>>>>> not a > >>>> mandatory deliverable. > >>>>>> > >>>>>> The working group will work in close coordination with other WGs > in > >>>>>> the IETF (including, but not limited to MILE and NEA) in order > to > >>>>>> create solutions that do not overlap and can be used or re-used > to > >>>>>> meet the goals of more than one working group. > >>>>>> > >>>>>> In accordance with existing IETF processes, the group will > >>>>>> communicate with and invite participation from other relevant > >>>>>> standards bodies and regulatory organizations, and if necessary > reuse > >>>>>> existing liaison relationships or request the establishment of > new > >>>>>> liaison > >>>> relationships. > >>>>>> > >>>>>> SACM-related efforts are largely aligned, and may overlap, with > other > >>>>>> IETF (and non-IETF) standardization efforts. There are common > >>>> "problems" > >>>>>> found in SACM, that may be addressed by the work done in SNMP, > IPFIX, > >>>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > particular > >>>>>> interest to SACM is understanding and respecting the > distinctions > >>>>>> between itself and NEA and MILE. > >>>>>> > >>>>>> One way the NEA protocols can be used is as the transport for > data > >>>>>> collected on the endpoint to an external service or data > repository > >>>>>> for further analysis and action. NEA may also serve the purpose > of > >>>>>> carrying data-collection instructions. > >>>>>> > >>>>>> The MILE data formats provide a format to describe incident, > >>>>>> threat-related incident, and indicator information. SACM data > >>>>>> formats provide ways to understand what endpoints are in your > >>>>>> environment, whether they meet policy requirements, and their > current > >>>>>> configuration state. The data exchanged in MILE, supplementing > the > >>>>>> SACM data, creates enhanced situational awareness, thus enabling > >>>>>> increased understanding of current threats and mitigations. > >>>>>> > >>>>>> After the work items in the current charter have been submitted > to > >>>>>> and approved by the IESG, the WG will recharter or close. > >>>>>> > >>>>>> Goals and Milestones > >>>>>> > >>>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > >>>>>> > >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on > Requirements > >>>>>> taking into consideration RFC5706 and RFC3535 > >>>>>> > >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM > >>>>>> Architecture > >>>>>> > >>>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview > of > >>>>>> related standards work > >>>>>> > >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a > protocol > >>>>>> and data format for retrieving configuration and policy > information > >>>>>> for driving data collection and analysis > >>>>>> > >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a > protocol > >>>>>> and data format for collecting actual endpoint posture > >>>>>> > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > Cases > >>>>>> for consideration as Informational RFC > >>>>>> > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on > >>>>>> Requirements for consideration as Informational RFC > >>>>>> > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > >>>>>> Architecture for consideration as Informational RFC > >>>>>> > >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a > >>>>>> protocol and data format for retrieving configuration and policy > >>>>>> information for driving data collection and analysis for > >>>>>> consideration as standards-track RFC > >>>>>> > >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a > protocol > >>>>>> and data format for collecting actual endpoint posture for > >>>>>> consideration as standards- track RFC > >>>>>> > >>>>>> 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. > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>>> ... > >>> > >>> 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. > >>> > >> > > _______________________________________________ > > 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 Tue Jun 11 08:59:21 2013 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 E8C2021F8825 for ; Tue, 11 Jun 2013 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOnylPCsoLn6 for ; Tue, 11 Jun 2013 08:58:58 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA8B21F8763 for ; Tue, 11 Jun 2013 08:58:58 -0700 (PDT) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 0c86_768e_d31b80ea_faca_496e_b1ab_fde931e84dcd; Tue, 11 Jun 2013 10:58:22 -0500 Received: from MIVEXEMEA1N1.corp.nai.org (10.48.48.31) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 11 Jun 2013 11:57:25 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXEMEA1N1.corp.nai.org ([169.254.3.136]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 11:57:25 -0400 From: To: Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6xNalvQ89Okyx82eII/CXtpkmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgIAAEZAAgAARYQCAAAxrgIAABiqAgAAzMQCABIBwAIAABAsA///3w5aAAVswgIAAAKEAgAABrQCAAABZgA== Date: Tue, 11 Jun 2013 15:57:24 +0000 Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A 9.9010008@ieca.com> <93602198-6F22-4D5E-A8A0-4F76292F6408@stoicsecurity.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <5CECD179277BF24A8EE36498ACFAFC39@McAfee.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: adam@stoicsecurity.com, sacm@ietf.org, kathleen.moriarty@emc.com, jfield@gopivotal.com, Gunnar.Engelbach@ThreatGuard.com, david.waltermire@nist.gov, turners@ieca.com, Adam.Montville@cisecurity.org Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:59:21 -0000 +1 Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026=20 On Jun 11, 2013, at 10:56 AM, "Stephen Hanna" wrote: > +1 >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam W. Montville >> Sent: Tuesday, June 11, 2013 11:50 AM >> To: Sean Turner >> Cc: sacm@ietf.org; Adam Montville; Field, John (Pivotal); Gunnar >> Engelbach; david.waltermire@nist.gov; Moriarty, Kathleen; >> Kent_Landfield@McAfee.com >> Subject: Re: [sacm] Updated Candidate Charter Text >>=20 >> +1 >> On Jun 11, 2013, at 8:47 AM, Sean Turner wrote: >>=20 >>> I think this is a reasonable suggestion and unless I hear otherwise >> I'm going to add it to the charter. >>>=20 >>> spt >>>=20 >>> On 6/10/13 7:05 PM, Gunnar Engelbach wrote: >>>>=20 >>>> To me, the sentence introducing the general assessment steps still >> reads >>>> like there's only one expected approach to assessment. >>>>=20 >>>>=20 >>>> Michael Hammer suggested changing that from >>>>=20 >>>> "Assessment of endpoint posture assessment entails the following >>>> general steps, which accommodate policy-driven and asset-driven >>>> assessment:" >>>>=20 >>>>=20 >>>> to: >>>>=20 >>>>=20 >>>> "An example of such an endpoint posture assessment could include, >> but is >>>> not limited to, the following general steps:" >>>>=20 >>>>=20 >>>> which is good enough for me. >>>>=20 >>>>=20 >>>>=20 >>>> On 6/10/2013 4:32 PM, Adam Montville wrote: >>>>> I don't have an objection to adding that sentence. Other opinions? >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>>>>> Sent: Monday, June 10, 2013 12:51 PM >>>>>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov >>>>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville >>>>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>>>>=20 >>>>>> I am mostly a +1, but would add one sentence at the end of the >> MILE >>>>>> description to tie in options for ROLIE and other transports. >>>>>>=20 >>>>>> Transports from MILE may be used by SACM. >>>>>>=20 >>>>>> Thank you, >>>>>> Kathleen >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of >>>>>> Kent_Landfield@McAfee.com >>>>>> Sent: Monday, June 10, 2013 3:35 PM >>>>>> To: david.waltermire@nist.gov >>>>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; >>>>>> Adam.Montville@cisecurity.org >>>>>> Subject: Re: [sacm] Updated Candidate Charter Text >>>>>>=20 >>>>>> +1 for me. >>>>>>=20 >>>>>> Kent Landfield >>>>>> McAfee Labs >>>>>> Kent_Landfield@McAfee.com >>>>>> +1.817.637.8026 >>>>>>=20 >>>>>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." >>>>>> wrote: >>>>>>=20 >>>>>>> +1 for me. Are we good with handing this off to Sean today? >>>>>>>=20 >>>>>>> Sincerely, >>>>>>> Dave >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >>>>>>>> Sent: Friday, June 07, 2013 6:36 PM >>>>>>>> To: John Field >>>>>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; >> Waltermire, >>>>>>>> David A.; sacm@ietf.org >>>>>>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>>>>>>=20 >>>>>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating >> the >>>>>>>> last few sentences. Also, changed Boolean to predicate. >>>>>>>>=20 >>>>>>>> Are there any further nits or really bad oversights in this copy >> of >>>>>>>> the >>>>>> charter? >>>>>>>>=20 >>>>>>>> If you like it as it stands, +1 it. >>>>>>>>=20 >>>>>>>> For me, +1 >>>>>>>>=20 >>>>>>>> --------------------------------------------- >>>>>>>>=20 >>>>>>>> Securing information and the systems that store, process, and >>>>>>>> transmit that information is a challenging task for >> organizations of >>>>>>>> all sizes, and many security practitioners spend much of their >> time on >>>>>> manual processes. >>>>>>>> Standardized processes to collect, verify, and update security >> system >>>>>>>> configurations would allow easier automation of the processes. >>>>>>>> Automating these routine tasks would free security practitioners >> to >>>>>>>> focus on high priority tasks, and should improve operators' >> ability >>>>>>>> to prioritize risk based on timely information about threats and >>>>>>>> vulnerabilities. This working group will define security >> automation >>>>>>>> protocols and data format standards in support of information >>>>>>>> security processes and practices. These standards will help >> security >>>>>>>> practitioners to be more effective by automating routine tasks >>>>>>>> related to client and server security, freeing them to focus on >> more >>>>>>>> advanced tasks. The initial focus of this work is to address >>>>>>>> enterprise use cases pertaining to the assessment of endpoint >> posture >>>>>> (using the definitions of Endpoint and Posture from RFC 5209). >>>>>>>>=20 >>>>>>>> The working group will, whenever reasonable and possible, reuse >>>>>>>> existing protocols, mechanisms, information and data models. Of >>>>>>>> particular interest to this working group are existing industry >>>>>>>> standards, preferably IETF standards, that could support >> automation >>>>>>>> of asset, change, configuration, and vulnerability management. >>>>>>>>=20 >>>>>>>> The working group will define: >>>>>>>>=20 >>>>>>>> 1. A set of standards to enable assessment of endpoint posture. >> This >>>>>>>> area of focus provides for necessary language and data format >>>>>> specifications. >>>>>>>>=20 >>>>>>>> 2. A set of standards for interacting with repositories of >> content >>>>>>>> related to assessment of endpoint posture. >>>>>>>>=20 >>>>>>>> Assessment of endpoint posture assessment entails the following >>>>>>>> general steps, which accommodate policy-driven and asset-driven >>>>>> assessment: >>>>>>>>=20 >>>>>>>> 1. Identify endpoints >>>>>>>>=20 >>>>>>>> 2. Determine specific endpoint elements to assess >>>>>>>>=20 >>>>>>>> 3. Collect actual value of elements >>>>>>>>=20 >>>>>>>> 4. Compare actual element values to expected element values >>>>>>>>=20 >>>>>>>> 5. Report results >>>>>>>>=20 >>>>>>>> This approach to endpoint posture collection enables multiple >>>>>>>> policies to be evaluated based on a single data collection >> activity. >>>>>>>> Policies will be evaluated by comparing available endpoint >> posture >>>>>>>> data according to rules expressed in the policy. Typically, >> these >>>>>>>> rules will compare the actual value against an expected value or >>>>>>>> range for specific posture elements. In some cases, the posture >>>>>>>> element may pertain to software installation state, in which >> case the >>>>>>>> actual and expected values may be "installed" or "not >> installed." >>>>>> Evaluation of multiple posture elements may be combined using >> predicate >>>>>> logic. >>>>>>>>=20 >>>>>>>> Repository protocols are needed to store, update, and retrieve >>>>>>>> configuration checks and other types of content required for >> posture >>>>>>>> assessment (see step 2 above). A content repository is expected >> to >>>>>>>> house specific versions of checklists (i.e. benchmarks), may be >>>>>>>> required to satisfy different use cases (i.e. asset inventory, >>>>>>>> configuration settings, or vulnerabilities). In addition, >> content >>>>>>>> repositories are expected to store up-to-date dictionary of >> specific >>>>>>>> enumerations, such as those used for configuration element >>>>>>>> identifiers, >>>>>> asset classifications, vulnerability identifiers, and so on. >>>>>>>>=20 >>>>>>>> This working group will achieve the following deliverables: >>>>>>>>=20 >>>>>>>> - An Informational document on Use Cases >>>>>>>> - An Informational document on Requirements >>>>>>>> - An Informational document on SACM Architecture >>>>>>>> - A standards-track document specifying a protocol and data >> format >>>>>>>> for retrieving configuration and policy information for driving >> data >>>>>>>> collection and analysis >>>>>>>> - A standards-track document specifying a protocol and data >> format >>>>>>>> for collecting actual endpoint posture >>>>>>>>=20 >>>>>>>> The working group will create an overview of related standards >> work >>>>>>>> Internet-Draft which will document existing work in the IETF or >> in >>>>>>>> other SDOs which can be used as-is or as a starting point for >>>>>>>> developing solutions to the SACM requirements. The working group >> may >>>>>>>> decide to make of this document an Informational RFC, but this >> is >>>>>>>> not a >>>>>> mandatory deliverable. >>>>>>>>=20 >>>>>>>> The working group will work in close coordination with other WGs >> in >>>>>>>> the IETF (including, but not limited to MILE and NEA) in order >> to >>>>>>>> create solutions that do not overlap and can be used or re-used >> to >>>>>>>> meet the goals of more than one working group. >>>>>>>>=20 >>>>>>>> In accordance with existing IETF processes, the group will >>>>>>>> communicate with and invite participation from other relevant >>>>>>>> standards bodies and regulatory organizations, and if necessary >> reuse >>>>>>>> existing liaison relationships or request the establishment of >> new >>>>>>>> liaison >>>>>> relationships. >>>>>>>>=20 >>>>>>>> SACM-related efforts are largely aligned, and may overlap, with >> other >>>>>>>> IETF (and non-IETF) standardization efforts. There are common >>>>>> "problems" >>>>>>>> found in SACM, that may be addressed by the work done in SNMP, >> IPFIX, >>>>>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of >> particular >>>>>>>> interest to SACM is understanding and respecting the >> distinctions >>>>>>>> between itself and NEA and MILE. >>>>>>>>=20 >>>>>>>> One way the NEA protocols can be used is as the transport for >> data >>>>>>>> collected on the endpoint to an external service or data >> repository >>>>>>>> for further analysis and action. NEA may also serve the purpose >> of >>>>>>>> carrying data-collection instructions. >>>>>>>>=20 >>>>>>>> The MILE data formats provide a format to describe incident, >>>>>>>> threat-related incident, and indicator information. SACM data >>>>>>>> formats provide ways to understand what endpoints are in your >>>>>>>> environment, whether they meet policy requirements, and their >> current >>>>>>>> configuration state. The data exchanged in MILE, supplementing >> the >>>>>>>> SACM data, creates enhanced situational awareness, thus enabling >>>>>>>> increased understanding of current threats and mitigations. >>>>>>>>=20 >>>>>>>> After the work items in the current charter have been submitted >> to >>>>>>>> and approved by the IESG, the WG will recharter or close. >>>>>>>>=20 >>>>>>>> Goals and Milestones >>>>>>>>=20 >>>>>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>>>>>>=20 >>>>>>>> Oct. 2013 - Initial submission of an Internet-Draft on >> Requirements >>>>>>>> taking into consideration RFC5706 and RFC3535 >>>>>>>>=20 >>>>>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>>>>>> Architecture >>>>>>>>=20 >>>>>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview >> of >>>>>>>> related standards work >>>>>>>>=20 >>>>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a >> protocol >>>>>>>> and data format for retrieving configuration and policy >> information >>>>>>>> for driving data collection and analysis >>>>>>>>=20 >>>>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a >> protocol >>>>>>>> and data format for collecting actual endpoint posture >>>>>>>>=20 >>>>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use >> Cases >>>>>>>> for consideration as Informational RFC >>>>>>>>=20 >>>>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>>>>>> Requirements for consideration as Informational RFC >>>>>>>>=20 >>>>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>>>>>>> Architecture for consideration as Informational RFC >>>>>>>>=20 >>>>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>>>>>> protocol and data format for retrieving configuration and policy >>>>>>>> information for driving data collection and analysis for >>>>>>>> consideration as standards-track RFC >>>>>>>>=20 >>>>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a >> protocol >>>>>>>> and data format for collecting actual endpoint posture for >>>>>>>> consideration as standards- track RFC >>>>>>>>=20 >>>>>>>> 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. >>>>>>> _______________________________________________ >>>>>>> sacm mailing list >>>>>>> sacm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>>=20 >>>>>> ... >>>>>=20 >>>>> 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. >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 >=20 From david.waltermire@nist.gov Tue Jun 11 09:11:17 2013 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 9826621F9622 for ; Tue, 11 Jun 2013 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.585, 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 T-LoCMg5jFJn for ; Tue, 11 Jun 2013 09:11:12 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8549A21F960F for ; Tue, 11 Jun 2013 09:11:12 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Jun 2013 12:10:55 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 11 Jun 2013 12:11:06 -0400 From: "Waltermire, David A." To: Sean Turner , Gunnar Engelbach Date: Tue, 11 Jun 2013 12:03:59 -0400 Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: Ac5muwtiTMe1UsP1R8utmd0e2tlv5gAAjO3Q Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A9.9010008@ieca.com> In-Reply-To: <51B746A9.9010008@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: "adam@stoicsecurity.com" , "sacm@ietf.org" , Adam Montville , "Field, John \(Pivotal\)" , "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 16:11:17 -0000 +1 > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tuesday, June 11, 2013 11:48 AM > To: Gunnar Engelbach > Cc: Adam Montville; Moriarty, Kathleen; Kent_Landfield@McAfee.com; > Waltermire, David A.; adam@stoicsecurity.com; sacm@ietf.org; Field, John > (Pivotal) > Subject: Re: [sacm] Updated Candidate Charter Text > > I think this is a reasonable suggestion and unless I hear otherwise I'm going to > add it to the charter. > > spt > > On 6/10/13 7:05 PM, Gunnar Engelbach wrote: > > > > To me, the sentence introducing the general assessment steps still > > reads like there's only one expected approach to assessment. > > > > > > Michael Hammer suggested changing that from > > > > "Assessment of endpoint posture assessment entails the following > > general steps, which accommodate policy-driven and asset-driven > > assessment:" > > > > > > to: > > > > > > "An example of such an endpoint posture assessment could include, but > > is not limited to, the following general steps:" > > > > > > which is good enough for me. > > > > > > > > On 6/10/2013 4:32 PM, Adam Montville wrote: > >> I don't have an objection to adding that sentence. Other opinions? > >> > >>> -----Original Message----- > >>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > >>> Sent: Monday, June 10, 2013 12:51 PM > >>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov > >>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > >>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam > Montville > >>> Subject: RE: [sacm] Updated Candidate Charter Text > >>> > >>> I am mostly a +1, but would add one sentence at the end of the MILE > >>> description to tie in options for ROLIE and other transports. > >>> > >>> Transports from MILE may be used by SACM. > >>> > >>> Thank you, > >>> Kathleen > >>> > >>> -----Original Message----- > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > >>> Of Kent_Landfield@McAfee.com > >>> Sent: Monday, June 10, 2013 3:35 PM > >>> To: david.waltermire@nist.gov > >>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > >>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; > >>> Adam.Montville@cisecurity.org > >>> Subject: Re: [sacm] Updated Candidate Charter Text > >>> > >>> +1 for me. > >>> > >>> Kent Landfield > >>> McAfee Labs > >>> Kent_Landfield@McAfee.com > >>> +1.817.637.8026 > >>> > >>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." > >>> wrote: > >>> > >>>> +1 for me. Are we good with handing this off to Sean today? > >>>> > >>>> Sincerely, > >>>> Dave > >>>> > >>>>> -----Original Message----- > >>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > >>>>> Sent: Friday, June 07, 2013 6:36 PM > >>>>> To: John Field > >>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, > >>>>> David A.; sacm@ietf.org > >>>>> Subject: RE: [sacm] Updated Candidate Charter Text > >>>>> > >>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating > >>>>> the last few sentences. Also, changed Boolean to predicate. > >>>>> > >>>>> Are there any further nits or really bad oversights in this copy > >>>>> of the > >>> charter? > >>>>> > >>>>> If you like it as it stands, +1 it. > >>>>> > >>>>> For me, +1 > >>>>> > >>>>> --------------------------------------------- > >>>>> > >>>>> Securing information and the systems that store, process, and > >>>>> transmit that information is a challenging task for organizations > >>>>> of all sizes, and many security practitioners spend much of their > >>>>> time on > >>> manual processes. > >>>>> Standardized processes to collect, verify, and update security > >>>>> system configurations would allow easier automation of the > processes. > >>>>> Automating these routine tasks would free security practitioners > >>>>> to focus on high priority tasks, and should improve operators' > >>>>> ability to prioritize risk based on timely information about > >>>>> threats and vulnerabilities. This working group will define > >>>>> security automation protocols and data format standards in support > >>>>> of information security processes and practices. These standards > >>>>> will help security practitioners to be more effective by > >>>>> automating routine tasks related to client and server security, > >>>>> freeing them to focus on more advanced tasks. The initial focus of > >>>>> this work is to address enterprise use cases pertaining to the > >>>>> assessment of endpoint posture > >>> (using the definitions of Endpoint and Posture from RFC 5209). > >>>>> > >>>>> The working group will, whenever reasonable and possible, reuse > >>>>> existing protocols, mechanisms, information and data models. Of > >>>>> particular interest to this working group are existing industry > >>>>> standards, preferably IETF standards, that could support > >>>>> automation of asset, change, configuration, and vulnerability > management. > >>>>> > >>>>> The working group will define: > >>>>> > >>>>> 1. A set of standards to enable assessment of endpoint posture. > >>>>> This area of focus provides for necessary language and data format > >>> specifications. > >>>>> > >>>>> 2. A set of standards for interacting with repositories of content > >>>>> related to assessment of endpoint posture. > >>>>> > >>>>> Assessment of endpoint posture assessment entails the following > >>>>> general steps, which accommodate policy-driven and asset-driven > >>> assessment: > >>>>> > >>>>> 1. Identify endpoints > >>>>> > >>>>> 2. Determine specific endpoint elements to assess > >>>>> > >>>>> 3. Collect actual value of elements > >>>>> > >>>>> 4. Compare actual element values to expected element values > >>>>> > >>>>> 5. Report results > >>>>> > >>>>> This approach to endpoint posture collection enables multiple > >>>>> policies to be evaluated based on a single data collection activity. > >>>>> Policies will be evaluated by comparing available endpoint posture > >>>>> data according to rules expressed in the policy. Typically, these > >>>>> rules will compare the actual value against an expected value or > >>>>> range for specific posture elements. In some cases, the posture > >>>>> element may pertain to software installation state, in which case > >>>>> the actual and expected values may be "installed" or "not installed." > >>> Evaluation of multiple posture elements may be combined using > >>> predicate logic. > >>>>> > >>>>> Repository protocols are needed to store, update, and retrieve > >>>>> configuration checks and other types of content required for > >>>>> posture assessment (see step 2 above). A content repository is > >>>>> expected to house specific versions of checklists (i.e. > >>>>> benchmarks), may be required to satisfy different use cases (i.e. > >>>>> asset inventory, configuration settings, or vulnerabilities). In > >>>>> addition, content repositories are expected to store up-to-date > >>>>> dictionary of specific enumerations, such as those used for > >>>>> configuration element identifiers, > >>> asset classifications, vulnerability identifiers, and so on. > >>>>> > >>>>> This working group will achieve the following deliverables: > >>>>> > >>>>> - An Informational document on Use Cases > >>>>> - An Informational document on Requirements > >>>>> - An Informational document on SACM Architecture > >>>>> - A standards-track document specifying a protocol and data format > >>>>> for retrieving configuration and policy information for driving > >>>>> data collection and analysis > >>>>> - A standards-track document specifying a protocol and data format > >>>>> for collecting actual endpoint posture > >>>>> > >>>>> The working group will create an overview of related standards > >>>>> work Internet-Draft which will document existing work in the IETF > >>>>> or in other SDOs which can be used as-is or as a starting point > >>>>> for developing solutions to the SACM requirements. The working > >>>>> group may decide to make of this document an Informational RFC, > >>>>> but this is not a > >>> mandatory deliverable. > >>>>> > >>>>> The working group will work in close coordination with other WGs > >>>>> in the IETF (including, but not limited to MILE and NEA) in order > >>>>> to create solutions that do not overlap and can be used or re-used > >>>>> to meet the goals of more than one working group. > >>>>> > >>>>> In accordance with existing IETF processes, the group will > >>>>> communicate with and invite participation from other relevant > >>>>> standards bodies and regulatory organizations, and if necessary > >>>>> reuse existing liaison relationships or request the establishment > >>>>> of new liaison > >>> relationships. > >>>>> > >>>>> SACM-related efforts are largely aligned, and may overlap, with > >>>>> other IETF (and non-IETF) standardization efforts. There are > >>>>> common > >>> "problems" > >>>>> found in SACM, that may be addressed by the work done in SNMP, > >>>>> IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > >>>>> particular interest to SACM is understanding and respecting the > >>>>> distinctions between itself and NEA and MILE. > >>>>> > >>>>> One way the NEA protocols can be used is as the transport for data > >>>>> collected on the endpoint to an external service or data > >>>>> repository for further analysis and action. NEA may also serve > >>>>> the purpose of carrying data-collection instructions. > >>>>> > >>>>> The MILE data formats provide a format to describe incident, > >>>>> threat-related incident, and indicator information. SACM data > >>>>> formats provide ways to understand what endpoints are in your > >>>>> environment, whether they meet policy requirements, and their > >>>>> current configuration state. The data exchanged in MILE, > >>>>> supplementing the SACM data, creates enhanced situational > >>>>> awareness, thus enabling increased understanding of current threats > and mitigations. > >>>>> > >>>>> After the work items in the current charter have been submitted to > >>>>> and approved by the IESG, the WG will recharter or close. > >>>>> > >>>>> Goals and Milestones > >>>>> > >>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases > >>>>> > >>>>> Oct. 2013 - Initial submission of an Internet-Draft on > >>>>> Requirements taking into consideration RFC5706 and RFC3535 > >>>>> > >>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM > >>>>> Architecture > >>>>> > >>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview of > >>>>> related standards work > >>>>> > >>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol > >>>>> and data format for retrieving configuration and policy > >>>>> information for driving data collection and analysis > >>>>> > >>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol > >>>>> and data format for collecting actual endpoint posture > >>>>> > >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > >>>>> Cases for consideration as Informational RFC > >>>>> > >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on > >>>>> Requirements for consideration as Informational RFC > >>>>> > >>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM > >>>>> Architecture for consideration as Informational RFC > >>>>> > >>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a > >>>>> protocol and data format for retrieving configuration and policy > >>>>> information for driving data collection and analysis for > >>>>> consideration as standards-track RFC > >>>>> > >>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a > >>>>> protocol and data format for collecting actual endpoint posture > >>>>> for consideration as standards- track RFC > >>>>> > >>>>> 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. > >>>> _______________________________________________ > >>>> 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 > >>> > >>> ... > >> > >> 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 dromasca@avaya.com Tue Jun 11 09:12:38 2013 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 4BB7121F9636 for ; Tue, 11 Jun 2013 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AyP+9Tv623m for ; Tue, 11 Jun 2013 09:12:32 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 875BD21F962B for ; Tue, 11 Jun 2013 09:12:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAH5Lt1HGmAcF/2dsb2JhbABPBwOCaCEwSb5LfxZ0giMBAQEBAwEBAQ8oNAQBBgwEAgEIDQQBAwEBAQoUCQcnCxQDBggCBAENBQgTB4drAQueJJwfEwSNdgSBByELBQcGC4JuYQOTbooUiwCDD4FoPw X-IronPort-AV: E=Sophos;i="4.87,845,1363147200"; d="scan'208";a="15634307" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Jun 2013 12:12:30 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Jun 2013 12:10:58 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 12:12:29 -0400 From: "Romascanu, Dan (Dan)" To: "Moriarty, Kathleen" , Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOZrsI9aAcJm1sm06iNfabEXNJCJkwh7UAgAABrQCAAGUsgP//wODQ Date: Tue, 11 Jun 2013 16:12:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA19B36C@AZ-FFEXMB04.global.avaya.com> References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A 9.9010008@ieca.com> <93602198-6F22-4D5E-A8A0-4F76292F6408@stoicsecurity.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 16:12:38 -0000 +1 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Tuesday, June 11, 2013 6:58 PM > To: Sean Turner > Cc: sacm@ietf.org > Subject: Re: [sacm] Updated Candidate Charter Text >=20 > +1 >=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Tuesday, June 11, 2013 11:56 AM > To: Adam W. Montville; Sean Turner > Cc: sacm@ietf.org; Adam Montville; Field, John (Pivotal); Gunnar > Engelbach; david.waltermire@nist.gov; Moriarty, Kathleen; > Kent_Landfield@McAfee.com > Subject: RE: [sacm] Updated Candidate Charter Text >=20 > +1 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam W. Montville > > Sent: Tuesday, June 11, 2013 11:50 AM > > To: Sean Turner > > Cc: sacm@ietf.org; Adam Montville; Field, John (Pivotal); Gunnar > > Engelbach; david.waltermire@nist.gov; Moriarty, Kathleen; > > Kent_Landfield@McAfee.com > > Subject: Re: [sacm] Updated Candidate Charter Text > > > > +1 > > On Jun 11, 2013, at 8:47 AM, Sean Turner wrote: > > > > > I think this is a reasonable suggestion and unless I hear otherwise > > I'm going to add it to the charter. > > > > > > spt > > > > > > On 6/10/13 7:05 PM, Gunnar Engelbach wrote: > > >> > > >> To me, the sentence introducing the general assessment steps still > > reads > > >> like there's only one expected approach to assessment. > > >> > > >> > > >> Michael Hammer suggested changing that from > > >> > > >> "Assessment of endpoint posture assessment entails the following > > >> general steps, which accommodate policy-driven and asset-driven > > >> assessment:" > > >> > > >> > > >> to: > > >> > > >> > > >> "An example of such an endpoint posture assessment could include, > > but is > > >> not limited to, the following general steps:" > > >> > > >> > > >> which is good enough for me. > > >> > > >> > > >> > > >> On 6/10/2013 4:32 PM, Adam Montville wrote: > > >>> I don't have an objection to adding that sentence. Other > opinions? > > >>> > > >>>> -----Original Message----- > > >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > > >>>> Sent: Monday, June 10, 2013 12:51 PM > > >>>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov > > >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > > >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam > > >>>> Montville > > >>>> Subject: RE: [sacm] Updated Candidate Charter Text > > >>>> > > >>>> I am mostly a +1, but would add one sentence at the end of the > > MILE > > >>>> description to tie in options for ROLIE and other transports. > > >>>> > > >>>> Transports from MILE may be used by SACM. > > >>>> > > >>>> Thank you, > > >>>> Kathleen > > >>>> > > >>>> -----Original Message----- > > >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > > Behalf Of > > >>>> Kent_Landfield@McAfee.com > > >>>> Sent: Monday, June 10, 2013 3:35 PM > > >>>> To: david.waltermire@nist.gov > > >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); > > >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; > > >>>> Adam.Montville@cisecurity.org > > >>>> Subject: Re: [sacm] Updated Candidate Charter Text > > >>>> > > >>>> +1 for me. > > >>>> > > >>>> Kent Landfield > > >>>> McAfee Labs > > >>>> Kent_Landfield@McAfee.com > > >>>> +1.817.637.8026 > > >>>> > > >>>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." > > >>>> wrote: > > >>>> > > >>>>> +1 for me. Are we good with handing this off to Sean today? > > >>>>> > > >>>>> Sincerely, > > >>>>> Dave > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > > >>>>>> Sent: Friday, June 07, 2013 6:36 PM > > >>>>>> To: John Field > > >>>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; > > Waltermire, > > >>>>>> David A.; sacm@ietf.org > > >>>>>> Subject: RE: [sacm] Updated Candidate Charter Text > > >>>>>> > > >>>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating > > the > > >>>>>> last few sentences. Also, changed Boolean to predicate. > > >>>>>> > > >>>>>> Are there any further nits or really bad oversights in this > > >>>>>> copy > > of > > >>>>>> the > > >>>> charter? > > >>>>>> > > >>>>>> If you like it as it stands, +1 it. > > >>>>>> > > >>>>>> For me, +1 > > >>>>>> > > >>>>>> --------------------------------------------- > > >>>>>> > > >>>>>> Securing information and the systems that store, process, and > > >>>>>> transmit that information is a challenging task for > > organizations of > > >>>>>> all sizes, and many security practitioners spend much of their > > time on > > >>>> manual processes. > > >>>>>> Standardized processes to collect, verify, and update security > > system > > >>>>>> configurations would allow easier automation of the processes. > > >>>>>> Automating these routine tasks would free security > > >>>>>> practitioners > > to > > >>>>>> focus on high priority tasks, and should improve operators' > > ability > > >>>>>> to prioritize risk based on timely information about threats > > >>>>>> and vulnerabilities. This working group will define security > > automation > > >>>>>> protocols and data format standards in support of information > > >>>>>> security processes and practices. These standards will help > > security > > >>>>>> practitioners to be more effective by automating routine tasks > > >>>>>> related to client and server security, freeing them to focus on > > more > > >>>>>> advanced tasks. The initial focus of this work is to address > > >>>>>> enterprise use cases pertaining to the assessment of endpoint > > posture > > >>>> (using the definitions of Endpoint and Posture from RFC 5209). > > >>>>>> > > >>>>>> The working group will, whenever reasonable and possible, reuse > > >>>>>> existing protocols, mechanisms, information and data models. Of > > >>>>>> particular interest to this working group are existing industry > > >>>>>> standards, preferably IETF standards, that could support > > automation > > >>>>>> of asset, change, configuration, and vulnerability management. > > >>>>>> > > >>>>>> The working group will define: > > >>>>>> > > >>>>>> 1. A set of standards to enable assessment of endpoint posture. > > This > > >>>>>> area of focus provides for necessary language and data format > > >>>> specifications. > > >>>>>> > > >>>>>> 2. A set of standards for interacting with repositories of > > content > > >>>>>> related to assessment of endpoint posture. > > >>>>>> > > >>>>>> Assessment of endpoint posture assessment entails the following > > >>>>>> general steps, which accommodate policy-driven and asset-driven > > >>>> assessment: > > >>>>>> > > >>>>>> 1. Identify endpoints > > >>>>>> > > >>>>>> 2. Determine specific endpoint elements to assess > > >>>>>> > > >>>>>> 3. Collect actual value of elements > > >>>>>> > > >>>>>> 4. Compare actual element values to expected element values > > >>>>>> > > >>>>>> 5. Report results > > >>>>>> > > >>>>>> This approach to endpoint posture collection enables multiple > > >>>>>> policies to be evaluated based on a single data collection > > activity. > > >>>>>> Policies will be evaluated by comparing available endpoint > > posture > > >>>>>> data according to rules expressed in the policy. Typically, > > these > > >>>>>> rules will compare the actual value against an expected value > > >>>>>> or range for specific posture elements. In some cases, the > > >>>>>> posture element may pertain to software installation state, in > > >>>>>> which > > case the > > >>>>>> actual and expected values may be "installed" or "not > > installed." > > >>>> Evaluation of multiple posture elements may be combined using > > predicate > > >>>> logic. > > >>>>>> > > >>>>>> Repository protocols are needed to store, update, and retrieve > > >>>>>> configuration checks and other types of content required for > > posture > > >>>>>> assessment (see step 2 above). A content repository is > > >>>>>> expected > > to > > >>>>>> house specific versions of checklists (i.e. benchmarks), may be > > >>>>>> required to satisfy different use cases (i.e. asset inventory, > > >>>>>> configuration settings, or vulnerabilities). In addition, > > content > > >>>>>> repositories are expected to store up-to-date dictionary of > > specific > > >>>>>> enumerations, such as those used for configuration element > > >>>>>> identifiers, > > >>>> asset classifications, vulnerability identifiers, and so on. > > >>>>>> > > >>>>>> This working group will achieve the following deliverables: > > >>>>>> > > >>>>>> - An Informational document on Use Cases > > >>>>>> - An Informational document on Requirements > > >>>>>> - An Informational document on SACM Architecture > > >>>>>> - A standards-track document specifying a protocol and data > > format > > >>>>>> for retrieving configuration and policy information for driving > > data > > >>>>>> collection and analysis > > >>>>>> - A standards-track document specifying a protocol and data > > format > > >>>>>> for collecting actual endpoint posture > > >>>>>> > > >>>>>> The working group will create an overview of related standards > > work > > >>>>>> Internet-Draft which will document existing work in the IETF or > > in > > >>>>>> other SDOs which can be used as-is or as a starting point for > > >>>>>> developing solutions to the SACM requirements. The working > > >>>>>> group > > may > > >>>>>> decide to make of this document an Informational RFC, but this > > is > > >>>>>> not a > > >>>> mandatory deliverable. > > >>>>>> > > >>>>>> The working group will work in close coordination with other > > >>>>>> WGs > > in > > >>>>>> the IETF (including, but not limited to MILE and NEA) in order > > to > > >>>>>> create solutions that do not overlap and can be used or re-used > > to > > >>>>>> meet the goals of more than one working group. > > >>>>>> > > >>>>>> In accordance with existing IETF processes, the group will > > >>>>>> communicate with and invite participation from other relevant > > >>>>>> standards bodies and regulatory organizations, and if necessary > > reuse > > >>>>>> existing liaison relationships or request the establishment of > > new > > >>>>>> liaison > > >>>> relationships. > > >>>>>> > > >>>>>> SACM-related efforts are largely aligned, and may overlap, with > > other > > >>>>>> IETF (and non-IETF) standardization efforts. There are common > > >>>> "problems" > > >>>>>> found in SACM, that may be addressed by the work done in SNMP, > > IPFIX, > > >>>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of > > particular > > >>>>>> interest to SACM is understanding and respecting the > > distinctions > > >>>>>> between itself and NEA and MILE. > > >>>>>> > > >>>>>> One way the NEA protocols can be used is as the transport for > > data > > >>>>>> collected on the endpoint to an external service or data > > repository > > >>>>>> for further analysis and action. NEA may also serve the > > >>>>>> purpose > > of > > >>>>>> carrying data-collection instructions. > > >>>>>> > > >>>>>> The MILE data formats provide a format to describe incident, > > >>>>>> threat-related incident, and indicator information. SACM data > > >>>>>> formats provide ways to understand what endpoints are in your > > >>>>>> environment, whether they meet policy requirements, and their > > current > > >>>>>> configuration state. The data exchanged in MILE, supplementing > > the > > >>>>>> SACM data, creates enhanced situational awareness, thus > > >>>>>> enabling increased understanding of current threats and > mitigations. > > >>>>>> > > >>>>>> After the work items in the current charter have been submitted > > to > > >>>>>> and approved by the IESG, the WG will recharter or close. > > >>>>>> > > >>>>>> Goals and Milestones > > >>>>>> > > >>>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use > > >>>>>> Cases > > >>>>>> > > >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on > > Requirements > > >>>>>> taking into consideration RFC5706 and RFC3535 > > >>>>>> > > >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM > > >>>>>> Architecture > > >>>>>> > > >>>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview > > of > > >>>>>> related standards work > > >>>>>> > > >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a > > protocol > > >>>>>> and data format for retrieving configuration and policy > > information > > >>>>>> for driving data collection and analysis > > >>>>>> > > >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a > > protocol > > >>>>>> and data format for collecting actual endpoint posture > > >>>>>> > > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use > > Cases > > >>>>>> for consideration as Informational RFC > > >>>>>> > > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on > > >>>>>> Requirements for consideration as Informational RFC > > >>>>>> > > >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on > > >>>>>> SACM Architecture for consideration as Informational RFC > > >>>>>> > > >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a > > >>>>>> protocol and data format for retrieving configuration and > > >>>>>> policy information for driving data collection and analysis for > > >>>>>> consideration as standards-track RFC > > >>>>>> > > >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a > > protocol > > >>>>>> and data format for collecting actual endpoint posture for > > >>>>>> consideration as standards- track RFC > > >>>>>> > > >>>>>> 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. > > >>>>> _______________________________________________ > > >>>>> 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 > > >>>> > > >>>> ... > > >>> > > >>> 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. > > >>> > > >> > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Tue Jun 11 09:32:34 2013 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 38B0121F8BC0 for ; Tue, 11 Jun 2013 09:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 EMWpdKfPfuFJ for ; Tue, 11 Jun 2013 09:32:29 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.170.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1C67A21F8BE9 for ; Tue, 11 Jun 2013 09:32:29 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 66EDB75CCD66C; Tue, 11 Jun 2013 11:32:28 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 16F8775CCD5DF for ; Tue, 11 Jun 2013 11:32:28 -0500 (CDT) Received: from [173.73.135.101] (port=49647 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UmRUh-0001xw-EL; Tue, 11 Jun 2013 11:32:27 -0500 Message-ID: <51B7511A.7080408@ieca.com> Date: Tue, 11 Jun 2013 12:32:26 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ietfdbh References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> In-Reply-To: <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:49647 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: 'David Harrington' , "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [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, 11 Jun 2013 16:32:34 -0000 Dave, I kind of have to agree with you here. I think the draft ought to cover the basics of here's what we want to do in the intro and then dive in to the how's this going work say where: a. My IT people bought some shiny new thing and plunk it on the network and ... b. My IT people didn't put a patch in when they should have and ... c. My enterprise supports BYOD, and I plug my D in to the network and ... d. .... I've got no problem if the use case documents goes way beyond what the charter says it just needs to be clear and say this bit is covered now, this bit might be done later, and this bit over here is done in that other wg. spt On 6/3/13 8:01 PM, ietfdbh wrote: > I have no objection to helping edit the draft. > However, the main failing of the draft in my eyes is that it doesn't really > contain use cases. > I am not active in the industry we are targeting, so we would need some > input on use cases from operators, security admins, vendors, etc. who are. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Monday, June 03, 2013 7:00 PM > To: David Harrington; sacm@ietf.org > Subject: Re: [sacm] use case document > > Great points and good questions. > > Would you be interested in working as an editor of the current use cases > draft to drive it forward while addressing your concerns? > > Sincerely, > Dave > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of David Harrington >> Sent: Friday, May 31, 2013 6:32 PM >> To: sacm@ietf.org >> Subject: [sacm] use case document >> >> Hi, >> >> I read through the use cases document last night. >> The current document sounds like pure marketing, with lots of promises >> of the wonderful world that will exist once we finish defining this >> new architecture and standards. >> Lots of people new to IETF make this mistake. >> This is the Internet ENGINEERING Task Force. We prefer engineering >> documents to marketing documents. >> >> To that end, let me make some comments and suggestions. >> Some SDOs work top-down; they design a pretty architecture and then >> try to populate it with protocols and data models, and so on. >> This is consistent with the way many proprietary engineering >> departments work. >> Historically, the IETF works bottom-up. >> A problem exists in the real world; multiple vendors solve it using >> proprietary approaches. >> Then the problem becomes more or less a solved problem that is not >> solved in a standardized manner. >> A lack of interoperability becomes the problem. >> That's when the IETF comes into play - helping the community establish >> a multi-vendor interoperable standard to help solve the original >> problem in an interoperable manner. >> The IETF approach is historically built on field-tested solutions, >> which then get standardized. >> Interoperability problems frequently are an aggregation of problems. >> Typically, the IETF focuses on standardizing details, like specific >> protocols or specific data models, based on uses that already exist in the > real world. >> Of course, with multiple contributors involved, the final result is >> usually changed quite a bit form the original because different >> segments of the community need to USE the technologies in different >> ways, often to add value to their products or services. >> >> >> The security automation use cases document would greatly benefit from >> content that describes how security automation is currently being USED >> in the real world, using proprietary solutions - the "use cases". >> From that, we can try to extract the common functionality and work to >> establish vendor-neutral, interoperable engineered standards, such as >> protocols and data models. >> >> Are there users of security automation subscribed to this list? >> If so, how are they using their automation? Who is the customer? >> What technical decisions have worked well; which have been problematic? >> >> I think the use cases document should help to identify users (e.g., >> vendors, services, operators) whose products/services utilize security > automation. >> We should try to get vendors to participate in building these >> standards, since they are the ones who will use them to build products. >> We should try to get operators to participate in building these >> standards, because they are the people who will configure and maintain >> the networks that use security automation. >> The use cases document doesn't represent the users of proprietary >> solutions that we propose to improve through standardization. >> The use cases document doesn't represent the expected users of the >> standards we propose to build (our customers). >> >> I think it should. >> >> David Harrington >> dbharrington@comcast.net >> +1-603-828-1401 >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From turners@ieca.com Tue Jun 11 09:36:20 2013 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 95DC521F9050 for ; Tue, 11 Jun 2013 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.072, 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 c9EqDfCrnboO for ; Tue, 11 Jun 2013 09:36:14 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.7.11]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6021F9048 for ; Tue, 11 Jun 2013 09:36:14 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 1EC8B67C3C429; Tue, 11 Jun 2013 11:36:06 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id A5F3C67C3C31E for ; Tue, 11 Jun 2013 11:36:05 -0500 (CDT) Received: from [173.73.135.101] (port=49654 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UmRYK-0003ZB-Pz for sacm@ietf.org; Tue, 11 Jun 2013 11:36:13 -0500 Message-ID: <51B751FC.4020307@ieca.com> Date: Tue, 11 Jun 2013 12:36:12 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "sacm@ietf.org" References: <51AE21AB.4060209@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4FEC@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F4FEC@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:49654 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 15 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 16:36:20 -0000 All, This charter is ready in my mind. If you don't agree, then it's time to speak up. You can do so here on this mailing list, to me privately, or more publicly on the ietf@ietf.org mailing list. What happens now is that I'm going to enter the charter for internal IESG review. It's a one week review so it can't be on the 6/13 telechat but it'll be on the 6/27. I expect comments before then and I'll mostly be fielding the questions. I'm queued up the management ADs and the applications ADs so none of this should be a surprise to them, but I've no doubt questions will be asked. Assuming internal review is navigated successfully, the charter will go for external review. This is where the announcement of a possible new WG goes to a bunch of SDOs and the IETF list. Sometimes this step can be skipped (for recharters) but it doesn't make any sense to do that for new wgs in my mind. At the earliest, the WG could be formed by the 11th of July. Because there is no chance it'll be WG before the IETF 87 scheduling occurs, I'll enter it on the BOF wiki to reserve a slot for it on the agenda. If the WG gets approved the slot gets used, if not then it goes back in to the pool. spt PS: *NONE* of this should stop anybody from publishing drafts under: draft-yourlastname-sacm-somethingusefulhere-00.txt PS: Also, a lot of the drafts I've seen in this space are bending over backwards to do tables. You can do bullet points or something else instead no need to make table columns that aren't wide enough for many of the element names. On 6/10/13 5:13 PM, Adam Montville wrote: > Sean, are you good with the charter (either before or after adding the sentence proposed by Kathleen)? > >> -----Original Message----- >> From: Waltermire, David A. [mailto:david.waltermire@nist.gov] >> Sent: Monday, June 10, 2013 12:20 PM >> To: Adam Montville; John Field >> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; sacm@ietf.org >> Subject: RE: [sacm] Updated Candidate Charter Text >> >> +1 for me. Are we good with handing this off to Sean today? >> >> Sincerely, >> Dave >> >>> -----Original Message----- >>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >>> Sent: Friday, June 07, 2013 6:36 PM >>> To: John Field >>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, >>> David A.; sacm@ietf.org >>> Subject: RE: [sacm] Updated Candidate Charter Text >>> >>> Thanks John. I've modified the "ROLIE paragraph" by truncating the >>> last few sentences. Also, changed Boolean to predicate. >>> >>> Are there any further nits or really bad oversights in this copy of the >> charter? >>> >>> If you like it as it stands, +1 it. >>> >>> For me, +1 >>> >>> --------------------------------------------- >>> >>> Securing information and the systems that store, process, and transmit >>> that information is a challenging task for organizations of all sizes, >>> and many security practitioners spend much of their time on manual >> processes. >>> Standardized processes to collect, verify, and update security system >>> configurations would allow easier automation of the processes. >>> Automating these routine tasks would free security practitioners to >>> focus on high priority tasks, and should improve operators' ability to >>> prioritize risk based on timely information about threats and >>> vulnerabilities. This working group will define security automation >>> protocols and data format standards in support of information security >>> processes and practices. These standards will help security >>> practitioners to be more effective by automating routine tasks related >>> to client and server security, freeing them to focus on more advanced >>> tasks. The initial focus of this work is to address enterprise use >>> cases pertaining to the assessment of endpoint posture (using the >> definitions of Endpoint and Posture from RFC 5209). >>> >>> The working group will, whenever reasonable and possible, reuse >>> existing protocols, mechanisms, information and data models. Of >>> particular interest to this working group are existing industry >>> standards, preferably IETF standards, that could support automation of >>> asset, change, configuration, and vulnerability management. >>> >>> The working group will define: >>> >>> 1. A set of standards to enable assessment of endpoint posture. This >>> area of focus provides for necessary language and data format >> specifications. >>> >>> 2. A set of standards for interacting with repositories of content >>> related to assessment of endpoint posture. >>> >>> Assessment of endpoint posture assessment entails the following >>> general steps, which accommodate policy-driven and asset-driven >> assessment: >>> >>> 1. Identify endpoints >>> >>> 2. Determine specific endpoint elements to assess >>> >>> 3. Collect actual value of elements >>> >>> 4. Compare actual element values to expected element values >>> >>> 5. Report results >>> >>> This approach to endpoint posture collection enables multiple policies >>> to be evaluated based on a single data collection activity. Policies >>> will be evaluated by comparing available endpoint posture data >>> according to rules expressed in the policy. Typically, these rules >>> will compare the actual value against an expected value or range for >>> specific posture elements. In some cases, the posture element may >>> pertain to software installation state, in which case the actual and >>> expected values may be "installed" or "not installed." Evaluation of multiple >> posture elements may be combined using predicate logic. >>> >>> Repository protocols are needed to store, update, and retrieve >>> configuration checks and other types of content required for posture >>> assessment (see step 2 above). A content repository is expected to >>> house specific versions of checklists (i.e. benchmarks), may be >>> required to satisfy different use cases (i.e. asset inventory, >>> configuration settings, or vulnerabilities). In addition, content >>> repositories are expected to store up-to-date dictionary of specific >>> enumerations, such as those used for configuration element identifiers, >> asset classifications, vulnerability identifiers, and so on. >>> >>> This working group will achieve the following deliverables: >>> >>> - An Informational document on Use Cases >>> - An Informational document on Requirements >>> - An Informational document on SACM Architecture >>> - A standards-track document specifying a protocol and data format for >>> retrieving configuration and policy information for driving data >>> collection and analysis >>> - A standards-track document specifying a protocol and data format for >>> collecting actual endpoint posture >>> >>> The working group will create an overview of related standards work >>> Internet-Draft which will document existing work in the IETF or in >>> other SDOs which can be used as-is or as a starting point for >>> developing solutions to the SACM requirements. The working group may >>> decide to make of this document an Informational RFC, but this is not a >> mandatory deliverable. >>> >>> The working group will work in close coordination with other WGs in >>> the IETF (including, but not limited to MILE and NEA) in order to >>> create solutions that do not overlap and can be used or re-used to >>> meet the goals of more than one working group. >>> >>> In accordance with existing IETF processes, the group will communicate >>> with and invite participation from other relevant standards bodies and >>> regulatory organizations, and if necessary reuse existing liaison >>> relationships or request the establishment of new liaison relationships. >>> >>> SACM-related efforts are largely aligned, and may overlap, with other >>> IETF (and non-IETF) standardization efforts. There are common "problems" >>> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular >>> interest to SACM is understanding and respecting the distinctions >>> between itself and NEA and MILE. >>> >>> One way the NEA protocols can be used is as the transport for data >>> collected on the endpoint to an external service or data repository >>> for further analysis and action. NEA may also serve the purpose of >>> carrying data-collection instructions. >>> >>> The MILE data formats provide a format to describe incident, >>> threat-related incident, and indicator information. SACM data formats >>> provide ways to understand what endpoints are in your environment, >>> whether they meet policy requirements, and their current configuration >>> state. The data exchanged in MILE, supplementing the SACM data, >>> creates enhanced situational awareness, thus enabling increased >>> understanding of current threats and mitigations. >>> >>> After the work items in the current charter have been submitted to and >>> approved by the IESG, the WG will recharter or close. >>> >>> Goals and Milestones >>> >>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>> >>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>> taking into consideration RFC5706 and RFC3535 >>> >>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>> Architecture >>> >>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>> related standards work >>> >>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and >>> data format for retrieving configuration and policy information for >>> driving data collection and analysis >>> >>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol and >>> data format for collecting actual endpoint posture >>> >>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases >>> for consideration as Informational RFC >>> >>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>> Requirements for consideration as Informational RFC >>> >>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>> Architecture for consideration as Informational RFC >>> >>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>> protocol and data format for retrieving configuration and policy >>> information for driving data collection and analysis for consideration >>> as standards-track RFC >>> >>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol >>> and data format for collecting actual endpoint posture for >>> consideration as standards- track RFC >>> >>> 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. >> >> ... > > 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 gunnar.engelbach@threatguard.com Tue Jun 11 09:53:25 2013 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 9D62E21F94E1 for ; Tue, 11 Jun 2013 09:53:22 -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 cYEbsnhIlikO for ; Tue, 11 Jun 2013 09:53:16 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 22E8221F93F8 for ; Tue, 11 Jun 2013 09:53:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=RjG+AhomlGduVyR9VqiKovn4ki6KMXYd+6gjNPkoCdJ1iFoLlWQ3MWBebfmLgECK0YiN28hiZa309OHKWgQwVNXrfPgzzz3Uo5jOslO+KeLZMyHBIXmWpJ4oqKLSO0y5; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 15895 invoked from network); 11 Jun 2013 10:04:56 -0700 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Jun 2013 10:04:55 -0700 Message-ID: <51B75605.6040706@ThreatGuard.com> Date: Tue, 11 Jun 2013 12:53:25 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sean Turner References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A9.9010008@ieca.com> In-Reply-To: <51B746A9.9010008@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "adam@stoicsecurity.com" , "sacm@ietf.org" , Adam Montville , "Field, John \(Pivotal\)" , "david.waltermire@nist.gov" , "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 16:53:25 -0000 +1 On 6/11/2013 11:47 AM, Sean Turner wrote: > I think this is a reasonable suggestion and unless I hear otherwise I'm > going to add it to the charter. > > spt > > On 6/10/13 7:05 PM, Gunnar Engelbach wrote: >> >> To me, the sentence introducing the general assessment steps still reads >> like there's only one expected approach to assessment. >> >> >> Michael Hammer suggested changing that from >> >> "Assessment of endpoint posture assessment entails the following >> general steps, which accommodate policy-driven and asset-driven >> assessment:" >> >> >> to: >> >> >> "An example of such an endpoint posture assessment could include, but is >> not limited to, the following general steps:" >> >> >> which is good enough for me. >> >> >> >> On 6/10/2013 4:32 PM, Adam Montville wrote: >>> I don't have an objection to adding that sentence. Other opinions? >>> >>>> -----Original Message----- >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>>> Sent: Monday, June 10, 2013 12:51 PM >>>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville >>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>> >>>> I am mostly a +1, but would add one sentence at the end of the MILE >>>> description to tie in options for ROLIE and other transports. >>>> >>>> Transports from MILE may be used by SACM. >>>> >>>> Thank you, >>>> Kathleen >>>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>>> Kent_Landfield@McAfee.com >>>> Sent: Monday, June 10, 2013 3:35 PM >>>> To: david.waltermire@nist.gov >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; >>>> Adam.Montville@cisecurity.org >>>> Subject: Re: [sacm] Updated Candidate Charter Text >>>> >>>> +1 for me. >>>> >>>> Kent Landfield >>>> McAfee Labs >>>> Kent_Landfield@McAfee.com >>>> +1.817.637.8026 >>>> >>>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." >>>> wrote: >>>> >>>>> +1 for me. Are we good with handing this off to Sean today? >>>>> >>>>> Sincerely, >>>>> Dave >>>>> >>>>>> -----Original Message----- >>>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >>>>>> Sent: Friday, June 07, 2013 6:36 PM >>>>>> To: John Field >>>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, >>>>>> David A.; sacm@ietf.org >>>>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>>>> >>>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating the >>>>>> last few sentences. Also, changed Boolean to predicate. >>>>>> >>>>>> Are there any further nits or really bad oversights in this copy of >>>>>> the >>>> charter? >>>>>> >>>>>> If you like it as it stands, +1 it. >>>>>> >>>>>> For me, +1 >>>>>> >>>>>> --------------------------------------------- >>>>>> >>>>>> Securing information and the systems that store, process, and >>>>>> transmit that information is a challenging task for organizations of >>>>>> all sizes, and many security practitioners spend much of their >>>>>> time on >>>> manual processes. >>>>>> Standardized processes to collect, verify, and update security system >>>>>> configurations would allow easier automation of the processes. >>>>>> Automating these routine tasks would free security practitioners to >>>>>> focus on high priority tasks, and should improve operators' ability >>>>>> to prioritize risk based on timely information about threats and >>>>>> vulnerabilities. This working group will define security automation >>>>>> protocols and data format standards in support of information >>>>>> security processes and practices. These standards will help security >>>>>> practitioners to be more effective by automating routine tasks >>>>>> related to client and server security, freeing them to focus on more >>>>>> advanced tasks. The initial focus of this work is to address >>>>>> enterprise use cases pertaining to the assessment of endpoint posture >>>> (using the definitions of Endpoint and Posture from RFC 5209). >>>>>> >>>>>> The working group will, whenever reasonable and possible, reuse >>>>>> existing protocols, mechanisms, information and data models. Of >>>>>> particular interest to this working group are existing industry >>>>>> standards, preferably IETF standards, that could support automation >>>>>> of asset, change, configuration, and vulnerability management. >>>>>> >>>>>> The working group will define: >>>>>> >>>>>> 1. A set of standards to enable assessment of endpoint posture. This >>>>>> area of focus provides for necessary language and data format >>>> specifications. >>>>>> >>>>>> 2. A set of standards for interacting with repositories of content >>>>>> related to assessment of endpoint posture. >>>>>> >>>>>> Assessment of endpoint posture assessment entails the following >>>>>> general steps, which accommodate policy-driven and asset-driven >>>> assessment: >>>>>> >>>>>> 1. Identify endpoints >>>>>> >>>>>> 2. Determine specific endpoint elements to assess >>>>>> >>>>>> 3. Collect actual value of elements >>>>>> >>>>>> 4. Compare actual element values to expected element values >>>>>> >>>>>> 5. Report results >>>>>> >>>>>> This approach to endpoint posture collection enables multiple >>>>>> policies to be evaluated based on a single data collection activity. >>>>>> Policies will be evaluated by comparing available endpoint posture >>>>>> data according to rules expressed in the policy. Typically, these >>>>>> rules will compare the actual value against an expected value or >>>>>> range for specific posture elements. In some cases, the posture >>>>>> element may pertain to software installation state, in which case the >>>>>> actual and expected values may be "installed" or "not installed." >>>> Evaluation of multiple posture elements may be combined using predicate >>>> logic. >>>>>> >>>>>> Repository protocols are needed to store, update, and retrieve >>>>>> configuration checks and other types of content required for posture >>>>>> assessment (see step 2 above). A content repository is expected to >>>>>> house specific versions of checklists (i.e. benchmarks), may be >>>>>> required to satisfy different use cases (i.e. asset inventory, >>>>>> configuration settings, or vulnerabilities). In addition, content >>>>>> repositories are expected to store up-to-date dictionary of specific >>>>>> enumerations, such as those used for configuration element >>>>>> identifiers, >>>> asset classifications, vulnerability identifiers, and so on. >>>>>> >>>>>> This working group will achieve the following deliverables: >>>>>> >>>>>> - An Informational document on Use Cases >>>>>> - An Informational document on Requirements >>>>>> - An Informational document on SACM Architecture >>>>>> - A standards-track document specifying a protocol and data format >>>>>> for retrieving configuration and policy information for driving data >>>>>> collection and analysis >>>>>> - A standards-track document specifying a protocol and data format >>>>>> for collecting actual endpoint posture >>>>>> >>>>>> The working group will create an overview of related standards work >>>>>> Internet-Draft which will document existing work in the IETF or in >>>>>> other SDOs which can be used as-is or as a starting point for >>>>>> developing solutions to the SACM requirements. The working group may >>>>>> decide to make of this document an Informational RFC, but this is >>>>>> not a >>>> mandatory deliverable. >>>>>> >>>>>> The working group will work in close coordination with other WGs in >>>>>> the IETF (including, but not limited to MILE and NEA) in order to >>>>>> create solutions that do not overlap and can be used or re-used to >>>>>> meet the goals of more than one working group. >>>>>> >>>>>> In accordance with existing IETF processes, the group will >>>>>> communicate with and invite participation from other relevant >>>>>> standards bodies and regulatory organizations, and if necessary reuse >>>>>> existing liaison relationships or request the establishment of new >>>>>> liaison >>>> relationships. >>>>>> >>>>>> SACM-related efforts are largely aligned, and may overlap, with other >>>>>> IETF (and non-IETF) standardization efforts. There are common >>>> "problems" >>>>>> found in SACM, that may be addressed by the work done in SNMP, IPFIX, >>>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular >>>>>> interest to SACM is understanding and respecting the distinctions >>>>>> between itself and NEA and MILE. >>>>>> >>>>>> One way the NEA protocols can be used is as the transport for data >>>>>> collected on the endpoint to an external service or data repository >>>>>> for further analysis and action. NEA may also serve the purpose of >>>>>> carrying data-collection instructions. >>>>>> >>>>>> The MILE data formats provide a format to describe incident, >>>>>> threat-related incident, and indicator information. SACM data >>>>>> formats provide ways to understand what endpoints are in your >>>>>> environment, whether they meet policy requirements, and their current >>>>>> configuration state. The data exchanged in MILE, supplementing the >>>>>> SACM data, creates enhanced situational awareness, thus enabling >>>>>> increased understanding of current threats and mitigations. >>>>>> >>>>>> After the work items in the current charter have been submitted to >>>>>> and approved by the IESG, the WG will recharter or close. >>>>>> >>>>>> Goals and Milestones >>>>>> >>>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>>>> >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements >>>>>> taking into consideration RFC5706 and RFC3535 >>>>>> >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>>>> Architecture >>>>>> >>>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>>>>> related standards work >>>>>> >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>>> and data format for retrieving configuration and policy information >>>>>> for driving data collection and analysis >>>>>> >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>>> and data format for collecting actual endpoint posture >>>>>> >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cases >>>>>> for consideration as Informational RFC >>>>>> >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>>>> Requirements for consideration as Informational RFC >>>>>> >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>>>>> Architecture for consideration as Informational RFC >>>>>> >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>>>> protocol and data format for retrieving configuration and policy >>>>>> information for driving data collection and analysis for >>>>>> consideration as standards-track RFC >>>>>> >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol >>>>>> and data format for collecting actual endpoint posture for >>>>>> consideration as standards- track RFC >>>>>> >>>>>> 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. >>>>> _______________________________________________ >>>>> 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 >>>> >>>> ... >>> >>> 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 Adam.Montville@cisecurity.org Wed Jun 12 07:26:57 2013 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 B4B4A21F9B57 for ; Wed, 12 Jun 2013 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEz3VDIxkq-6 for ; Wed, 12 Jun 2013 07:26:52 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1C64D21F9B3F for ; Wed, 12 Jun 2013 07:26:29 -0700 (PDT) Received: from [216.82.241.211:11689] by server-11.bemta-8.messagelabs.com id A7/93-18209-60588B15; Wed, 12 Jun 2013 14:26:14 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-6.tower-85.messagelabs.com!1371047173!37385814!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 27732 invoked from network); 12 Jun 2013 14:26:13 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-6.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jun 2013 14:26:13 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 10:25:56 -0400 From: Adam Montville To: Gunnar Engelbach , Sean Turner Thread-Topic: [sacm] Updated Candidate Charter Text Thread-Index: AQHOX6n6YA/o2vHFUkGQwiF+kQelt5kmEx2AgAFcNICAAu0o4IAAUXwA///CUICAAElhgP//zpxAgAAOWVCAAA86YIAASVeA///unPAAkC8MwAAI+H2AAACKIgAACBQQoP//9b+AgAEYFoCAABJPgIABJe97 Date: Wed, 12 Jun 2013 14:25:56 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F5C1A@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D66F367E@CISEXCHANGE1.msisac.org.local> <51B1FE8E.3050405@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F37EC@CISEXCHANGE1.msisac.org.local> <51B2085D.2020400@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F38A1@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3A35@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F3ACC@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F47A0@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D66F4F5D@CISEXCHANGE1.msisac.org.local> <51B65BB5.2030005@ThreatGuard.com> <51B746A9.9010008@ieca.com>,<51B75605.6040706@ThreatGuard.com> In-Reply-To: <51B75605.6040706@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adam@stoicsecurity.com" , "sacm@ietf.org" , "Field, John \(Pivotal\)" , "david.waltermire@nist.gov" , "Moriarty, Kathleen" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] Updated Candidate Charter Text X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:26:57 -0000 Can someone get the charter text updated at http://datatracker.ietf.org/wg= /sacm/charter/ or tell me how to do so and I'll do it :-) Adam ________________________________________ From: Gunnar Engelbach [Gunnar.Engelbach@ThreatGuard.com] Sent: Tuesday, June 11, 2013 9:53 AM To: Sean Turner Cc: Adam Montville; Moriarty, Kathleen; Kent_Landfield@McAfee.com; david.w= altermire@nist.gov; adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pi= votal) Subject: Re: [sacm] Updated Candidate Charter Text +1 On 6/11/2013 11:47 AM, Sean Turner wrote: > I think this is a reasonable suggestion and unless I hear otherwise I'm > going to add it to the charter. > > spt > > On 6/10/13 7:05 PM, Gunnar Engelbach wrote: >> >> To me, the sentence introducing the general assessment steps still read= s >> like there's only one expected approach to assessment. >> >> >> Michael Hammer suggested changing that from >> >> "Assessment of endpoint posture assessment entails the following >> general steps, which accommodate policy-driven and=20asset-driven >> assessment:" >> >> >> to: >> >> >> "An example of such an endpoint posture assessment could include, but i= s >> not limited to, the following general steps:" >> >> >> which is good enough for me. >> >> >> >> On 6/10/2013 4:32 PM, Adam Montville wrote: >>> I don't have an objection to adding that sentence. Other opinions? >>> >>>> -----Original Message----- >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>>> Sent: Monday, June 10, 2013 12:51 PM >>>> To: Kent_Landfield@McAfee.com; david.waltermire@nist.gov >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; Adam Montville >>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>> >>>> I am mostly a +1, but would add one sentence at the end of the MILE >>>> description to tie in options for ROLIE and other transports. >>>> >>>> Transports from MILE may be used by SACM. >>>> >>>> Thank you, >>>> Kathleen >>>> >>>> -----Original Message----- >>>> From:=20sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behal= f Of >>>> Kent_Landfield@McAfee.com >>>> Sent: Monday, June 10, 2013 3:35 PM >>>> To: david.waltermire@nist.gov >>>> Cc: adam@stoicsecurity.com; sacm@ietf.org; Field, John (Pivotal); >>>> Gunnar.Engelbach@threatguard.com; turners@ieca.com; >>>> Adam.Montville@cisecurity.org >>>> Subject: Re: [sacm] Updated Candidate Charter Text >>>> >>>> +1 for me. >>>> >>>> Kent Landfield >>>> McAfee Labs >>>> Kent_Landfield@McAfee.com >>>> +1.817.637.8026 >>>> >>>> On Jun 10, 2013, at 2:21 PM, "Waltermire, David A." >>>> wrote: >>>> >>>>> +1 for me. Are we good with handing this off to Sean today? >>>>> >>>>> Sincerely, >>>>> Dave >>>>> >>>>>> -----Original Message----- >>>>>> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >>>>>> Sent: Friday, June 07, 2013 6:36 PM >>>>>> To: John Field >>>>>> Cc: Sean Turner; Gunnar Engelbach; Adam W. Montville; Waltermire, >>>>>> David A.; sacm@ietf.org >>>>>> Subject: RE: [sacm] Updated Candidate Charter Text >>>>>> >>>>>> Thanks John. I've modified the "ROLIE paragraph" by truncating the= >>>>>> last few sentences. Also, changed Boolean to predicate. >>>>>> >>>>>> Are there any further nits or really bad oversights in this copy of= >>>>>> the >>>> charter? >>>>>> >>>>>> If you like it as it stands, +1 it. >>>>>> >>>>>> For me, +1 >>>>>> >>>>>> --------------------------------------------- >>>>>> >>>>>> Securing information and the systems that store, process, and >>>>>> transmit that information is a challenging task for organizations o= f >>>>>> all sizes, and many security practitioners spend much of their >>>>>> time on >>>> manual processes. >>>>>> Standardized processes to collect, verify, and update security syst= em >>>>>> configurations would allow easier automation of the processes. >>>>>> Automating these routine tasks would free security practitioners to= >>>>>> focus on high priority tasks, and should improve operators' ability= >>>>>> to prioritize risk based on timely information about threats and >>>>>> vulnerabilities. This working group will define security automation= >>>>>> protocols and data format standards in support of information >>>>>> security processes and practices. These standards will help securit= y >>>>>> practitioners to be more effective by automating routine tasks >>>>>> related to client and server security, freeing them to focus on mor= e >>>>>> advanced tasks. The initial focus of this work is to address >>>>>> enterprise use cases pertaining to the assessment of endpoint postu= re >>>> (using the definitions of Endpoint and Posture from RFC 5209). >>>>>> >>>>>> The working group will, whenever reasonable and possible, reuse >>>>>> existing protocols, mechanisms, information and data models. Of >>>>>> particular interest to this working group are existing industry >>>>>> standards, preferably IETF standards, that could support automation= >>>>>> of asset, change, configuration, and vulnerability management. >>>>>> >>>>>> The working group will define: >>>>>> >>>>>>=201. A set of standards to enable assessment of endpoint posture. T= his >>>>>> area of focus provides for necessary language and data format >>>> specifications. >>>>>> >>>>>> 2. A set of standards for interacting with repositories of content >>>>>> related to assessment of endpoint posture. >>>>>> >>>>>> Assessment of endpoint posture assessment entails the following >>>>>> general steps, which accommodate policy-driven and asset-driven >>>> assessment: >>>>>> >>>>>> 1. Identify endpoints >>>>>> >>>>>> 2. Determine specific endpoint elements to assess >>>>>> >>>>>> 3. Collect actual value of elements >>>>>> >>>>>> 4. Compare actual element values to expected element values >>>>>> >>>>>> 5. Report results >>>>>> >>>>>> This approach to endpoint posture collection enables multiple >>>>>> policies to be evaluated based on a single data collection activity= . >>>>>> Policies will be evaluated by comparing available endpoint posture >>>>>> data according to rules expressed in the policy. Typically, these >>>>>> rules will compare the actual value against an expected value or >>>>>> range for specific posture elements. In some cases, the posture >>>>>> element may pertain to software installation state, in which case t= he >>>>>> actual and expected values may be "installed" or "not installed." >>>> Evaluation of multiple posture elements may be combined using predica= te >>>> logic. >>>>>> >>>>>> Repository protocols are needed to store, update, and retrieve >>>>>> configuration checks and other types of content required for postur= e >>>>>> assessment (see step 2 above). A content repository is expected to= >>>>>> house specific versions of checklists (i.e. benchmarks), may be >>>>>> required to satisfy different use cases (i.e. asset inventory, >>>>>> configuration settings, or vulnerabilities). In addition, content >>>>>> repositories are expected to store up-to-date dictionary of specifi= c >>>>>> enumerations, such as those used for configuration element >>>>>> identifiers, >>>> asset classifications, vulnerability identifiers, and so on. >>>>>> >>>>>> This working group will achieve the following deliverables: >>>>>> >>>>>> - An Informational document on Use Cases >>>>>> - An Informational document on Requirements >>>>>> - An Informational document on SACM Architecture >>>>>> - A standards-track document specifying a protocol and data format >>>>>> for retrieving configuration and policy information for driving dat= a >>>>>> collection and analysis >>>>>> - A standards-track document specifying a protocol and data format >>>>>> for collecting actual endpoint posture >>>>>> >>>>>> The working group will create an overview of related standards work= >>>>>> Internet-Draft which will document existing work in the IETF or in >>>>>> other SDOs which can be used as-is or as a starting point for >>>>>> developing solutions to the SACM requirements. The working group ma= y >>>>>> decide to make of this document an Informational RFC, but this is >>>>>> not a >>>> mandatory deliverable. >>>>>> >>>>>> The working group will work in close coordination with other WGs in= >>>>>> the IETF (including, but not limited to MILE and NEA) in order to >>>>>> create solutions that do not overlap and can be used or re-used to >>>>>> meet the goals of more than one working group. >>>>>> >>>>>> In accordance with existing IETF processes, the group will >>>>>> communicate with and invite participation from other relevant >>>>>> standards bodies and regulatory organizations, and if necessary reu= se >>>>>> existing liaison relationships or request the establishment of new >>>>>> liaison >>>> relationships. >>>>>> >>>>>> SACM-related efforts are largely aligned, and may overlap, with oth= er >>>>>> IETF (and non-IETF) standardization efforts. There are common >>>> "problems" >>>>>> found in SACM, that may be addressed by the work done in SNMP, IPFI= X, >>>>>> NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular >>>>>> interest to SACM is understanding and respecting the distinctions >>>>>> between itself and NEA and MILE. >>>>>> >>>>>> One way the NEA protocols can be used is as the transport for data >>>>>> collected on the endpoint to an external service or data repository= >>>>>> for further analysis and action. NEA may also serve the purpose of= >>>>>> carrying data-collection instructions. >>>>>> >>>>>> The MILE data formats provide a format to describe incident, >>>>>> threat-related incident, and indicator information. SACM data >>>>>> formats provide ways to understand what endpoints are in your >>>>>> environment, whether they meet policy requirements, and their curre= nt >>>>>> configuration state. The data exchanged in MILE, supplementing the= >>>>>> SACM data, creates enhanced situational awareness, thus enabling >>>>>> increased understanding of current threats and mitigations. >>>>>> >>>>>> After the work items in the current charter have been submitted to >>>>>> and approved by the IESG, the WG will recharter or close. >>>>>> >>>>>> Goals and Milestones >>>>>> >>>>>> Sep. 2013 - Initial submission of an Internet-Draft on Use Cases >>>>>> >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on Requirements= >>>>>> taking into consideration RFC5706 and RFC3535 >>>>>> >>>>>> Oct. 2013 - Initial submission of an Internet-Draft on SACM >>>>>> Architecture >>>>>> >>>>>> Nov. 2013 - Initial submission of an Internet-Draft on overview of >>>>>> related standards work >>>>>> >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>>> and data format for retrieving configuration and policy information= >>>>>> for driving data collection and analysis >>>>>> >>>>>> Jan. 2014 - Initial submission of an Internet-Draft for a protocol >>>>>> and data format for collecting actual endpoint posture >>>>>> >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on Use Cas= es >>>>>> for consideration as Informational RFC >>>>>> >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on >>>>>> Requirements for consideration as Informational RFC >>>>>> >>>>>> Apr. 2014 - Submission to the IESG of the Internet-Draft on SACM >>>>>> Architecture for consideration as Informational RFC >>>>>> >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft for a >>>>>> protocol and data format for retrieving configuration and policy >>>>>> information for driving data collection and analysis for >>>>>> consideration as standards-track RFC >>>>>> >>>>>> Oct. 2014 - Submission to the IESG of the Internet-Draft a protocol= >>>>>> and data format for collecting actual endpoint posture for >>>>>> consideration as standards- track RFC >>>>>> >>>>>> 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 a= nd >>>>>> attachments is strictly prohibited. Please notify the sender >>>>>> immediately and permanently delete the message and any attachments.= >>>>> _______________________________________________ >>>>> 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 >>>> >>>> ... >>> >>> 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. >>> >> ... 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 Adam.Montville@cisecurity.org Wed Jun 12 07:43:52 2013 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 BD06721F9B9E for ; Wed, 12 Jun 2013 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv3KuoUsZ7ys for ; Wed, 12 Jun 2013 07:43:48 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.196]) by ietfa.amsl.com (Postfix) with ESMTP id 58BFC21F9B8D for ; Wed, 12 Jun 2013 07:43:48 -0700 (PDT) Received: from [216.82.242.179:21129] by server-4.bemta-8.messagelabs.com id 47/7F-09999-32988B15; Wed, 12 Jun 2013 14:43:47 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-14.tower-86.messagelabs.com!1371048227!765337!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 728 invoked from network); 12 Jun 2013 14:43:47 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-14.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jun 2013 14:43:47 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 10:43:09 -0400 From: Adam Montville To: Sean Turner , ietfdbh Thread-Topic: [sacm] use case document Thread-Index: Ac5eSUH6AbcnKB9yT0eGS0vpD1wP0ACZETYgAAqp7IABgqaaAAAlrGZg Date: Wed, 12 Jun 2013 14:43:10 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F5C64@CISEXCHANGE1.msisac.org.local> References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> <51B7511A.7080408@ieca.com> In-Reply-To: <51B7511A.7080408@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'David Harrington' , "'Waltermire, David A.'" , "sacm@ietf.org" Subject: Re: [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, 12 Jun 2013 14:43:52 -0000 I like the idea of being more pedantic with our use cases. Several people= have more-or-less formalized use case documentation structures (Alistair = Cockburn [1] and Martin Fowler [2] come to mind). For purposes of the us= e case draft, I think it would be useful to agree on 1) the content a use = case should contain, and 2) the structure of that content. =20 This might mean that some reformatting needs to be done to the draft, but = I'd rather see it convey what it needs to convey than worry about reformat= ting. I don't think every possible edge case should necessarily be included with= in each use case description. I also believe that a representative set of use cases can be leveraged rat= her than every possible case. Thinking aloud, would it be useful to consi= der user scenarios [4] as a means of focusing use cases? I've seen scenar= ios work very well in practice. Adam [1] http://alistair.cockburn.us/index.php/Basic_use_case_template [2] http://martinfowler.com/bliki/UseCases.html [3] http://www.usability.gov/methods/design_site/usecasesresource.html [4] http://www.usability.gov/methods/analyze_current/scenarios.html > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Tuesday, June 11, 2013 9:32 AM > To: ietfdbh > Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org > Subject: Re: [sacm] use case document >=20 > Dave, >=20 > I kind of have to agree with you here. I think the draft ought to cover= the > basics of here's what we want to do in the intro and then dive in to the= how's > this going work say where: >=20 > a. My IT people bought some shiny new thing and plunk it on the network > and ... > b. My IT people didn't put a patch in when they should have and ... > c. My enterprise supports BYOD, and I plug my D in to the network and ..= . > d. .... >=20 > I've got no problem if the use case documents goes way beyond what the > charter says it just needs to be clear and say this bit is covered now, = this bit > might be done later, and this bit over here is done in that other wg. >=20 > spt >=20 > On 6/3/13 8:01 PM, ietfdbh wrote: > > I have no objection to helping edit the draft. > > However, the main failing of the draft in my eyes is that it doesn't > > really contain use cases. > > I am not active in the industry we are targeting, so we would need > > some input on use cases from operators, security admins, vendors, etc.= > who are. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Waltermire, David A. > > Sent: Monday, June 03, 2013 7:00 PM > > To: David Harrington; sacm@ietf.org > > Subject: Re: [sacm] use case document > > > > Great points and good questions. > > > > Would you be interested in working as an editor of the current use > > cases draft to drive it forward while addressing your concerns? > > > > Sincerely, > > Dave > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of David Harrington > >> Sent: Friday, May 31, 2013 6:32 PM > >> To: sacm@ietf.org > >> Subject: [sacm] use case document > >> > >> Hi, > >> > >> I read through the use cases document last night. > >> The current document sounds like pure marketing, with lots of > >> promises of the wonderful world that will exist once we finish > >> defining this new architecture and standards. > >> Lots of people new to IETF make this mistake. > >> This is the Internet ENGINEERING Task Force. We prefer engineering > >> documents to marketing documents. > >> > >> To that end, let me make some comments and suggestions. > >> Some SDOs work top-down; they design a pretty architecture and then > >> try to populate it with protocols and data models, and so on. > >> This is consistent with the way many proprietary engineering > >> departments work. > >> Historically, the IETF works bottom-up. > >> A problem exists in the real world; multiple vendors solve it using > >> proprietary approaches. > >> Then the problem becomes more or less a solved problem that is not > >> solved in a standardized manner. > >> A lack of interoperability becomes the problem. > >> That's when the IETF comes into play - helping the community > >> establish a multi-vendor interoperable standard to help solve the > >> original problem in an interoperable manner. > >> The IETF approach is historically built on field-tested solutions, > >> which then get standardized. > >> Interoperability problems frequently are an aggregation of problems. > >> Typically, the IETF focuses on standardizing details, like specific > >> protocols or specific data models, based on uses that already exist > >> in the > > real world. > >> Of course, with multiple contributors involved, the final result is > >> usually changed quite a bit form the original because different > >> segments of the community need to USE the technologies in different > >> ways, often to add value to their products or services. > >> > >> > >> The security automation use cases document would greatly benefit from= > >> content that describes how security automation is currently being > >> USED in the real world, using proprietary solutions - the "use cases"= . > >> From that, we can try to extract the common functionality and work > >> to establish vendor-neutral, interoperable engineered standards, such= > >> as protocols and data models. > >> > >> Are there users of security automation subscribed to this list? > >> If so, how are they using their automation? Who is the customer? > >> What technical decisions have worked well; which have been > problematic? > >> > >> I think the use cases document should help to identify users (e.g., > >> vendors, services, operators) whose products/services utilize > >> security > > automation. > >> We should try to get vendors to participate in building these > >> standards, since they are the ones who will use them to build product= s. > >> We should try to get operators to participate in building these > >> standards, because they are the people who will configure and > >> maintain the networks that use security automation. > >> The use cases document doesn't represent the users of proprietary > >> solutions that we propose to improve through standardization. > >> The use cases document doesn't represent the expected users of the > >> standards we propose to build (our customers). > >> > >> I think it should. > >> > >> David Harrington > >> dbharrington@comcast.net > >> +1-603-828-1401 > >> > >> > >> _______________________________________________ > >> 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 >=20 > ... 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 dbharrington@comcast.net Wed Jun 12 10:00:59 2013 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 CF09521E805D for ; Wed, 12 Jun 2013 10:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 MmWieKNT+TjU for ; Wed, 12 Jun 2013 10:00:52 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id BE80B21E804C for ; Wed, 12 Jun 2013 10:00:51 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id nRZe1l0030ldTLk51V0rg1; Wed, 12 Jun 2013 17:00:51 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta04.westchester.pa.mail.comcast.net with comcast id nUyq1l01R2yZEBF01UyrNv; Wed, 12 Jun 2013 16:58:51 +0000 From: "David Harrington" To: "'Adam Montville'" , "'Sean Turner'" , "'ietfdbh'" References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> <51B7511A.7080408@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F5C64@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D66F5C64@CISEXCHANGE1.msisac.org.local> Date: Wed, 12 Jun 2013 12:58:50 -0400 Message-ID: <055701ce678e$1cc71870$56554950$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEMdLuegdeWdCbFCE+YTD19zbEQBQB+8R1tASepuEMB0h65aAGjSKGOmo1JgvA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371056451; bh=Id3wS1V+f68iRG9lLMFUpeRERO3/WWHHKkBgc2y4nGA=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=b5cetsxy+D827D16vAUbsrsiVfwSa3hMRPUuYyMkR/Wl/0tNRWHqB2FCMM5Ljawg+ wwZmtLXOLjt92NCzAmddP+Pw34n5eWiYedqjTv9KSrLmW9h6Ef+HndahzDNrFMOKzx n7jTWGU5QQXmOJ9ljjDBNAG4zf8SIE8G0aGGTzl1M/A16+itcH+StqTfBGJDYqjF+E oc9d1yYlLok+Mg+uoQRTi/5keVjxeHpAfK2c/O/1Cb+qRkOFctypboQS2TgaDLwdgk bAMN+YsvACmSmGJ0aq3tKon6G6e447oOG4tI+wswvWVfxa1sUAGeABjjBPBfQ5oCIj qZOWSdb8MFKCQ== Cc: "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [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, 12 Jun 2013 17:00:59 -0000 Hi Adam, I looked at your references. I found some useful information for things to consider. OTOH, my impression is that the Alistair and fowler approaches are more oriented toward formal software development, ala UML, than we need for our purposes. There are a number of use case documents already published in the IETF. They are far less formal, but consistent with IETF practice. I recommend we look at a few of those. I have not gone through these in detail, and they each have their own style and amount of detail depending on their purpose. RFCs: 3752, 4496, 5344, 6294, 6341, 6394, 6405, 6461, 6770, 6789, 6907, and 6953. First, though I think we need some contributions. Who is planning to use security automation, and how do they plan to use it? And let's get beyond motherhood and apple pie; let's get into some detailed usage scenarios. Are the assessments going to be used for approving network access? If so, why is this not being done in NEA WG? Is the vulnerability information going to be shared across management domains? If so, why is this not being done in MILE? If the purpose is collecting data from sensors into a database, why not do this using SNMP? If the purpose if policy-based config, why not do this work in NETCONF? If the purpose is to standardize data models of security protocols, like TLS and SSH, why not do this work in the those WGs? What explicitly makes the sacm work different from all the other work already being done that relates to automated management functionality? Just the fact that the focus is on security? SNMP has been used to manage bridging, routing, host resources, and hundreds of other specific focus points. Should the IETF have had specific WGs for "routing automation and continuous monitoring" with a completely new architecture for that? Should the IETF have had specific WGs for "bridging automation and continuous monitoring" with a completely new architecture for that? Should the IETF have had specific WGs for "host automation and continuous monitoring" with a completely new architecture for that? ... What makes sacm different enough to require its own WG and its own architecture? How are sacm standards going to be used? By what types of applications? David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, June 12, 2013 10:43 AM To: Sean Turner; ietfdbh Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org Subject: Re: [sacm] use case document I like the idea of being more pedantic with our use cases. Several people have more-or-less formalized use case documentation structures (Alistair Cockburn [1] and Martin Fowler [2] come to mind). For purposes of the use case draft, I think it would be useful to agree on 1) the content a use case should contain, and 2) the structure of that content. This might mean that some reformatting needs to be done to the draft, but I'd rather see it convey what it needs to convey than worry about reformatting. I don't think every possible edge case should necessarily be included within each use case description. I also believe that a representative set of use cases can be leveraged rather than every possible case. Thinking aloud, would it be useful to consider user scenarios [4] as a means of focusing use cases? I've seen scenarios work very well in practice. Adam [1] http://alistair.cockburn.us/index.php/Basic_use_case_template [2] http://martinfowler.com/bliki/UseCases.html [3] http://www.usability.gov/methods/design_site/usecasesresource.html [4] http://www.usability.gov/methods/analyze_current/scenarios.html > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of Sean Turner > Sent: Tuesday, June 11, 2013 9:32 AM > To: ietfdbh > Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org > Subject: Re: [sacm] use case document > > Dave, > > I kind of have to agree with you here. I think the draft ought to > cover the basics of here's what we want to do in the intro and then > dive in to the how's this going work say where: > > a. My IT people bought some shiny new thing and plunk it on the > network and ... > b. My IT people didn't put a patch in when they should have and ... > c. My enterprise supports BYOD, and I plug my D in to the network and ... > d. .... > > I've got no problem if the use case documents goes way beyond what the > charter says it just needs to be clear and say this bit is covered > now, this bit might be done later, and this bit over here is done in that other wg. > > spt > > On 6/3/13 8:01 PM, ietfdbh wrote: > > I have no objection to helping edit the draft. > > However, the main failing of the draft in my eyes is that it doesn't > > really contain use cases. > > I am not active in the industry we are targeting, so we would need > > some input on use cases from operators, security admins, vendors, etc. > who are. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Waltermire, David A. > > Sent: Monday, June 03, 2013 7:00 PM > > To: David Harrington; sacm@ietf.org > > Subject: Re: [sacm] use case document > > > > Great points and good questions. > > > > Would you be interested in working as an editor of the current use > > cases draft to drive it forward while addressing your concerns? > > > > Sincerely, > > Dave > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf Of David Harrington > >> Sent: Friday, May 31, 2013 6:32 PM > >> To: sacm@ietf.org > >> Subject: [sacm] use case document > >> > >> Hi, > >> > >> I read through the use cases document last night. > >> The current document sounds like pure marketing, with lots of > >> promises of the wonderful world that will exist once we finish > >> defining this new architecture and standards. > >> Lots of people new to IETF make this mistake. > >> This is the Internet ENGINEERING Task Force. We prefer engineering > >> documents to marketing documents. > >> > >> To that end, let me make some comments and suggestions. > >> Some SDOs work top-down; they design a pretty architecture and then > >> try to populate it with protocols and data models, and so on. > >> This is consistent with the way many proprietary engineering > >> departments work. > >> Historically, the IETF works bottom-up. > >> A problem exists in the real world; multiple vendors solve it using > >> proprietary approaches. > >> Then the problem becomes more or less a solved problem that is not > >> solved in a standardized manner. > >> A lack of interoperability becomes the problem. > >> That's when the IETF comes into play - helping the community > >> establish a multi-vendor interoperable standard to help solve the > >> original problem in an interoperable manner. > >> The IETF approach is historically built on field-tested solutions, > >> which then get standardized. > >> Interoperability problems frequently are an aggregation of problems. > >> Typically, the IETF focuses on standardizing details, like specific > >> protocols or specific data models, based on uses that already exist > >> in the > > real world. > >> Of course, with multiple contributors involved, the final result is > >> usually changed quite a bit form the original because different > >> segments of the community need to USE the technologies in different > >> ways, often to add value to their products or services. > >> > >> > >> The security automation use cases document would greatly benefit > >> from content that describes how security automation is currently > >> being USED in the real world, using proprietary solutions - the "use cases". > >> From that, we can try to extract the common functionality and work > >> to establish vendor-neutral, interoperable engineered standards, > >> such as protocols and data models. > >> > >> Are there users of security automation subscribed to this list? > >> If so, how are they using their automation? Who is the customer? > >> What technical decisions have worked well; which have been > problematic? > >> > >> I think the use cases document should help to identify users (e.g., > >> vendors, services, operators) whose products/services utilize > >> security > > automation. > >> We should try to get vendors to participate in building these > >> standards, since they are the ones who will use them to build products. > >> We should try to get operators to participate in building these > >> standards, because they are the people who will configure and > >> maintain the networks that use security automation. > >> The use cases document doesn't represent the users of proprietary > >> solutions that we propose to improve through standardization. > >> The use cases document doesn't represent the expected users of the > >> standards we propose to build (our customers). > >> > >> I think it should. > >> > >> David Harrington > >> dbharrington@comcast.net > >> +1-603-828-1401 > >> > >> > >> _______________________________________________ > >> 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 > > ... 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. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Thu Jun 13 06:55:56 2013 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 03CD921F9A0B for ; Thu, 13 Jun 2013 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqyS0U7Ca9e2 for ; Thu, 13 Jun 2013 06:55:51 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.102]) by ietfa.amsl.com (Postfix) with ESMTP id 22AE121F9978 for ; Thu, 13 Jun 2013 06:55:51 -0700 (PDT) Received: from [216.82.253.227:63614] by server-6.bemta-7.messagelabs.com id 50/FB-21879-66FC9B15; Thu, 13 Jun 2013 13:55:50 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-15.tower-170.messagelabs.com!1371131748!22014380!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 10629 invoked from network); 13 Jun 2013 13:55:49 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-15.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jun 2013 13:55:49 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 13 Jun 2013 09:55:30 -0400 From: Adam Montville To: David Harrington , 'Sean Turner' , 'ietfdbh' Thread-Topic: [sacm] use case document Thread-Index: Ac5eSUH6AbcnKB9yT0eGS0vpD1wP0ACZETYgAAqp7IABgqaaAAAlrGZgAA2KPgAAIo+4oA== Date: Thu, 13 Jun 2013 13:55:30 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D66F5FE6@CISEXCHANGE1.msisac.org.local> References: <008c01ce5e4e$b326fd60$1974f820$@comcast.net> <00e701ce60b6$a7ce90d0$f76bb270$@comcast.net> <51B7511A.7080408@ieca.com> <05BCCEB107AF88469B9F99783D47C1D66F5C64@CISEXCHANGE1.msisac.org.local> <055701ce678e$1cc71870$56554950$@comcast.net> In-Reply-To: <055701ce678e$1cc71870$56554950$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Waltermire, David A.'" , "sacm@ietf.org" Subject: Re: [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: Thu, 13 Jun 2013 13:55:56 -0000 David, Thank you for your questions - they're helpful. I think we should start to take your questions to heart and review some of= the material from our Atlanta BoF where we presented Use Cases, ultimatel= y, in the context of Operational Risk Management and with specific types o= f actors. =20 One example scenario that might get us to a more meaningful use case discu= ssion would be that an organization's Chief Information Security Officer w= ants a thumbnail sketch of the organization's PCI-related security posture= , as measured by configuration and vulnerability of its PCI-related assets= . To get this information, a security administrator, filling the role of = an "auditor," may be tasked to collect this information, which requires th= at the security administrator: 1. Identify PCI-related assets 2. Assess configuration and vulnerability posture of each of those assets = against known organizational hardening standards (we assume that such hard= ening standards are aligned with PCI) 3. Generate a report of some kind It's what happens in 2 that you, I think, want more detail on. Is this right? Adam > -----Original Message----- > From: David Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, June 12, 2013 10:01 AM > To: Adam Montville; 'Sean Turner'; 'ietfdbh' > Cc: 'Waltermire, David A.'; sacm@ietf.org > Subject: RE: [sacm] use case document >=20 > Hi Adam, >=20 > I looked at your references. > I found some useful information for things to consider. > OTOH, my impression is that the Alistair and fowler approaches are more > oriented toward formal software development, ala UML, than we need for > our purposes. Fair enough. I was just looking toward the facets of a use case we might = want to convey. >=20 > There are a number of use case documents already published in the IETF. > They are far less formal, but consistent with IETF practice. > I recommend we look at a few of those. > I have not gone through these in detail, and they each have their own st= yle > and amount of detail depending on their purpose. > RFCs:=203752, 4496, 5344, 6294, 6341, 6394, 6405, 6461, 6770, 6789, 6907= , and > 6953. Thank you. We should certainly review a handful of these for formatting/c= ontent ideas. >=20 > First, though I think we need some contributions. > Who is planning to use security automation, and how do they plan to use = it? I would recommend reviewing IETF Proceedings information from our Atlanta = BoF. In particular, the Use Case presentation: http://www.ietf.org/procee= dings/85/slides/slides-85-sacm-2.pdf That presentation provides our primary frame of reference and an overview = of the actors involved. > And let's get beyond motherhood and apple pie; let's get into some detai= led > usage scenarios. >=20 > Are the assessments going to be used for approving network access? If so= , > why is this not being done in NEA WG? > Is the vulnerability information going to be shared across management > domains? If so, why is this not being done in MILE? > If the purpose is collecting data from sensors into a database, why not = do this > using SNMP? > If the purpose if policy-based config, why not do this work in NETCONF? > If the purpose is to standardize data models of security protocols, like= TLS > and SSH, why not do this work in the those WGs? > What explicitly makes the sacm work different from all the other work > already being done that relates to automated management functionality? > Just the fact that the focus is on security? > SNMP has been used to manage bridging, routing, host resources, and > hundreds of other specific focus points. > Should the IETF have had specific WGs for "routing automation and > continuous monitoring" with a completely new architecture for that? > Should the IETF have had specific WGs for "bridging automation and > continuous monitoring" with a completely new architecture for that? > Should the IETF have had specific WGs for "host automation and continuou= s > monitoring" with a completely new architecture for that? > ... The questions you pose above are good ones. In general, the "why is this = not being done in X?" questions may be answered in a similar way: No one e= xisting WG is concerned with the intersection of the whole. It so happens= that configuration assessment is a component of SACM that can be reused a= cross some of these other efforts. To me, the biggest differentiator between SACM and some of the other WGs i= s the fact that it is less operational in nature and more security/complia= nce focused. A primary use case for the SACM architecture will be to enab= le organizations to ensure that appropriately hardened host configurations= are in place throughout the asset management lifecycle and to manage conf= iguration drift over time in a manner that is consistent with higher-level= policies, which may be driven by internal or external requirements (i.e. = PCI, COBIT, SOX, EU Data Protection, Monetary Authority of Singapore, DSD = Top 35, CSC Top 20, and so on). Also, note that "asset" can include info= rmation and is not restricted to computing devices. >=20 > What makes sacm different enough to require its own WG and its own > architecture? See above. Additionally, the architecture for SACM may well include facet= s of other IETF WGs where warranted. =20 > How are sacm standards going to be used? By what types of applications? Primarily security control/tool vendors (choose your terminology here). T= ripwire, McAfee, Symantec, IBM, RedHat, Microsoft, CIS, SPAWAR, and a host= of other tools in this space. If you throw in the integrations that are = possible by collaborating with other working groups, then more tools/effor= ts can be added to the list (i.e. those supporting network access control = or incident response capabilities). >=20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Wednesday, June 12, 2013 10:43 AM > To: Sean Turner; ietfdbh > Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org > Subject: Re: [sacm] use case document >=20 > I like the idea of being more pedantic with our use cases. Several peop= le > have more-or-less formalized use case documentation structures (Alistair= > Cockburn [1] and Martin Fowler [2] come to mind). For purposes of the = use > case draft, I think it would be useful to agree on 1) the content a use = case > should contain, and 2) the structure of that content. >=20 > This might mean that some reformatting needs to be done to the draft, bu= t > I'd rather see it convey what it needs to convey than worry about > reformatting. >=20 > I don't think every possible edge case should necessarily be included wi= thin > each use case description. >=20 > I also believe that a representative set of use cases can be leveraged r= ather > than every possible case. Thinking aloud, would it be useful to conside= r user > scenarios [4] as a means of focusing use cases? I've seen scenarios wor= k very > well in practice. >=20 > Adam >=20 > [1] http://alistair.cockburn.us/index.php/Basic_use_case_template > [2] http://martinfowler.com/bliki/UseCases.html > [3] http://www.usability.gov/methods/design_site/usecasesresource.html > [4] http://www.usability.gov/methods/analyze_current/scenarios.html >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Sean Turner > > Sent: Tuesday, June 11, 2013 9:32 AM > > To: ietfdbh > > Cc: 'David Harrington'; 'Waltermire, David A.'; sacm@ietf.org > > Subject: Re: [sacm] use case document > > > > Dave, > > > > I kind of have to agree with you here. I think the draft ought to > > cover the basics of here's what we want to do in the intro and then > > dive in to the how's this going work say where: > > > > a. My IT people bought some shiny new thing and plunk it on the > > network and ... > > b. My IT people didn't put a patch in when they should have and ... > > c. My enterprise supports BYOD, and I plug my D in to the network and = ... > > d. .... > > > > I've got no problem if the use case documents goes way beyond what the= > > charter says it just needs to be clear and say this bit is covered > > now, this bit might be done later, and this bit over here is done in > > that > other wg. > > > > spt > > > > On 6/3/13 8:01 PM, ietfdbh wrote: > > > I have no objection to helping edit the draft. > > > However, the main failing of the draft in my eyes is that it doesn't= > > > really contain use cases. > > > I am not active in the industry we are targeting, so we would need > > > some input on use cases from operators, security admins, vendors, et= c. > > who are. > > > > > > David Harrington > > > ietfdbh@comcast.net > > > +1-603-828-1401 > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > > Of Waltermire, David A. > > > Sent: Monday, June 03, 2013 7:00 PM > > > To: David Harrington; sacm@ietf.org > > > Subject: Re: [sacm] use case document > > > > > > Great points and good questions. > > > > > > Would you be interested in working as an editor of the current use > > > cases draft to drive it forward while addressing your concerns? > > > > >=20> Sincerely, > > > Dave > > > > > >> -----Original Message----- > > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > > >> Behalf Of David Harrington > > >> Sent: Friday, May 31, 2013 6:32 PM > > >> To: sacm@ietf.org > > >> Subject: [sacm] use case document > > >> > > >> Hi, > > >> > > >> I read through the use cases document last night. > > >> The current document sounds like pure marketing, with lots of > > >> promises of the wonderful world that will exist once we finish > > >> defining this new architecture and standards. > > >> Lots of people new to IETF make this mistake. > > >> This is the Internet ENGINEERING Task Force. We prefer engineering > > >> documents to marketing documents. > > >> > > >> To that end, let me make some comments and suggestions. > > >> Some SDOs work top-down; they design a pretty architecture and then= > > >> try to populate it with protocols and data models, and so on. > > >> This is consistent with the way many proprietary engineering > > >> departments work. > > >> Historically, the IETF works bottom-up. > > >> A problem exists in the real world; multiple vendors solve it using= > > >> proprietary approaches. > > >> Then the problem becomes more or less a solved problem that is not= > > >> solved in a standardized manner. > > >> A lack of interoperability becomes the problem. > > >> That's when the IETF comes into play - helping the community > > >> establish a multi-vendor interoperable standard to help solve the > > >> original problem in an interoperable manner. > > >> The IETF approach is historically built on field-tested solutions, > > >> which then get standardized. > > >> Interoperability problems frequently are an aggregation of problems= . > > >> Typically, the IETF focuses on standardizing details, like specific= > > >> protocols or specific data models, based on uses that already exist= > > >> in the > > > real world. > > >> Of course, with multiple contributors involved, the final result is= > > >> usually changed quite a bit form the original because different > > >> segments of the community need to USE the technologies in different= > > >> ways, often to add value to their products or services. > > >> > > >> > > >> The security automation use cases document would greatly benefit > > >> from content that describes how security automation is currently > > >> being USED in the real world, using proprietary solutions - the > > >> "use > cases". > > >> From that, we can try to extract the common functionality and work= > > >> to establish vendor-neutral, interoperable engineered standards, > > >> such as protocols and data models. > > >> > > >> Are there users of security automation subscribed to this list? > > >> If so, how are they using their automation? Who is the customer? > > >> What technical decisions have worked well; which have been > > problematic? > > >> > > >> I think the use cases document should help to identify users (e.g.,= > > >> vendors, services, operators) whose products/services utilize > > >> security > > > automation. > > >> We should try to get vendors to participate in building these > > >> standards, since they are the ones who will use them to build produ= cts. > > >> We should try to get operators to participate in building these > > >> standards, because they are the people who will configure and > > >> maintain the networks that use security automation. > > >> The use cases document doesn't represent the users of proprietary > > >> solutions that we propose to improve through standardization. > > >> The use cases document doesn't represent the expected users of the > > >> standards we propose to build (our customers). > > >> > > >> I think it should. > > >> > > >> David Harrington > > >> dbharrington@comcast.net > > >> +1-603-828-1401 > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > ... >=20 > This message and attachments may contain confidential information. If i= t > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments i= s > strictly prohibited. Please notify the sender immediately and permanent= ly > delete the message and any attachments. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 > ... 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 dromasca@avaya.com Sun Jun 23 04:15:24 2013 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 7412F21F9C67 for ; Sun, 23 Jun 2013 04:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 g+neaLbMCh4v for ; Sun, 23 Jun 2013 04:15:24 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C5CC721F9C45 for ; Sun, 23 Jun 2013 04:15:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAKbXxlHGmAcF/2dsb2JhbABagmgheoMFvDENbhZtB4IjAQEBAQMSERFRBgEGAg0EBAEBAwIGHQMCBDAUAQYBAQUFBBMIGodsAYxWjEOEQoo6hg2KJReBJoxngRE+gkkzYQOeB4sAgxCBagcXBho X-IronPort-AV: E=Sophos;i="4.87,922,1363147200"; d="scan'208";a="14111713" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jun 2013 07:15:22 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2013 07:13:09 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 13:15:21 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: NOMCOM 2013 - UPDATE of validated volunteers list so far Thread-Index: AQHObdME6Rq94fdvak6H2HdtpQQDoZlDKUtg Date: Sun, 23 Jun 2013 11:15:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1AB62B@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: NOMCOM 2013 - UPDATE of validated volunteers list so far X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 11:15:24 -0000 UGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZyBmb3IgTk9NQ09NIGlmIHlvdSBhcmUgZWxpZ2li bGUgYW5kIHlvdSBkaWQgbm90IGRvIGl0IGJ5IG5vdy4gDQoNClRoYW5rcyBhbmQgUmVnYXJkcywN Cg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0Zi1hbm5v dW5jZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTMNClNlbnQ6IFRodXJzZGF5LCBKdW5l IDIwLCAyMDEzIDE6MTQgQU0NClRvOiBJRVRGIEFubm91bmNlbWVudCBMaXN0DQpDYzogaWV0ZkBp ZXRmLm9yZw0KU3ViamVjdDogTk9NQ09NIDIwMTMgLSBVUERBVEUgb2YgdmFsaWRhdGVkIHZvbHVu dGVlcnMgbGlzdCBzbyBmYXINCg0KQmVsb3cgaXMgdGhlIGN1cnJlbnQgdmFsaWRhdGVkIGxpc3Qg b2Ygdm9sdW50ZWVycyBmb3IgTm9tY29tIDIwMTMuICBJZiB5b3VyIG5hbWUgaGFzIGEgKiwgSSdt IHdhaXRpbmcgZm9yIGEgbWVzc2FnZSBiYWNrIGZyb20geW91Lg0KDQpCaWcgdGhhbmtzIHRvIGV2 ZXJ5b25lIHdobyBoYXMgdm9sdW50ZWVyZWQhDQoNCk5vdyB3aGF0IGFyZSB0aGUgcmVzdCBvZiB5 b3Ugd2FpdGluZyBmb3I/DQoNCldlIHN0aWxsIG5lZWQgcXVpdGUgYSBmZXcgdG8gZ2V0IHVwIHRv IDIwMCB2b2x1bnRlZXJzLg0KUGxlYXNlIHJlcGx5IGFuZCB2b2x1bnRlZXIgLSBpbmNsdWRlIGlu IHRoZSBlbWFpbDogeW91ciBGaXJzdCBOYW1lLCBMYXN0IE5hbWUsIGVtYWlsIGFkZHJlc3NlcyB5 b3UndmUgdXNlZCBpbiB0aGUgbGFzdCBmZXcgeWVhcnMgaW4gcmVnaXN0ZXJpbmcgZm9yIElFVEYg bWVldGluZ3MsIHByZWZlcnJlZCBlbWFpbCBhZGRyZXNzLCBwcmltYXJ5IGFmZmlsaWF0aW9uLCBh bmQgYSBjb250YWN0IHBob25lIG51bWJlciBmb3IgdXNlIGlmIHlvdSdyZSBzZWxlY3RlZC4NCg0K VGhhbmtzLCANCg0KQWxsaXNvbiBNYW5raW4NCk5vbWNvbSAyMDEzIENoYWlyDQoNCg0KMSBKb2hu IFNjdWRkZXINCjIgU3RlcGhlbiBIYW5uYQ0KMyBXYXNzaW0gSGFkZGFkDQo0IFJ1c3MgV2hpdGUN CjUgU3RlcGhhbiBXZW5nZXINCjYgWkhBTyBZaQ0KNyBFcmljIEdyYXkNCjggU3RldmUgS2VudA0K OSBUb2VybGVzcyBFY2tlcnQNCjEwIEFsaWEgQXRsYXMNCjExIFZpY3RvciBLdWFyc2luZ2gNCjEy IFlpemhvdSBMSQ0KMTMgR29uemFsbyBTYWxndWVpcm8NCjE0IEdhbmcgQ0hFTg0KMTUgTmluZyBL T05HDQoxNiBNYXJjZWxvIEJhZ251bG8NCjE3IFNIRU4gU2h1byDmsojng4EgKFNlYW4pDQoxOCBG ZXJuYW5kbyBHb250DQoxOSBHbGVuIFpvcm4NCjIwIFJlaW5hbGRvIFBlbm5vDQoyMSBLbGFhcyBX aWVyZW5nYQ0KMjIgUGFzY2FsIFRodWJlcnQNCjIzIE1laG1ldCBFcnN1ZQ0KMjQgT2xlIFRyb2Fu DQoyNSBKb3VuaSBLb3Job25lbg0KMjYgR2lsZXMgSGVyb24NCjI3IEd1bnRlciBWYW4gZGUgVmVs ZGUNCjI4IEFydHVybyBTZXJ2aW4NCjI5IEVyaWMgVnluY2tlDQozMCBDdWxsZW4gSmVubmluZ3MN CjMxIFRpbmEgVHNvdQ0KMzIgRGhydXYgRGhvZHkNCjMzIEhvbmd5dSBMSSAoSnVsaW8pDQozNCBT Y290dCBNYW5zZmllbGQNCjM1IEpvaG4gRHJha2UNCjM2IEFuZHJldyBNY0xhY2hsYW4NCjM3IERl cmVrIEF0a2lucw0KMzggU3VoYXMgTmFuZGFrdW1hcg0KMzkgRXJpYyBSZXNjb3JsYQ0KNDAgS2Fy ZW4gU2VvDQo0MSBTdGlnIFZlbmFhcw0KNDIgU3RhbiBSYXRsaWZmDQo0MyBJZ25hcyBCYWdkb25h cw0KNDQgUGV0ZXIgWWVlDQo0NSBEb25hbGQgRWFzdGxha2UNCjQ2IFpIT1UgUWlhbiAoQ2F0aHkp DQo0NyBTYW0gSGFydG1hbg0KNDggTGl4aWEgWmhhbmcNCjQ5IFRlZW11IFNhdm9sYWluZW4NCjUw IEFsdmFybyBSZXRhbmENCjUxIFRlcnJ5IE1hbmRlcnNvbg0KNTIgQmlsbCBWZXJTdGVlZw0KNTMg TWVsaW5kYSBTaG9yZQ0KNTQgSUpzYnJhbmQgV2lqbmFuZHMNCjU1IEthcmVuIE8nRG9ub2dodWUN CjU2IEJlbnNvbiBTY2hsaWVzc2VyDQo1NyBBcmkgS2Vyw6RuZW4NCjU4IEZhbmd3ZWkgSFUNCjU5 IE1hY2ggQ0hFTg0KNjAgSHVpIERlbmcNCjYxIExJVSBEYXBlbmcNCjYyIEphYXAgQWtrZXJodWlz DQo2MyBNYWdudXMgV2VzdGVybHVuZA0KNjQgWmVobiBDQU8NCjY1IFphaGVkdXp6YW1hbiBTYXJr ZXINCjY2IEJodW1pcCBLaGFzbmFiaXNoDQo2NyBBbmRyZXcgQ2hpDQo2OCBUaG9tYXMgTmFkZWF1 DQo2OSBTdGV2ZW4gQyAoQ3JhaWcpIFdoaWx0ZQ0KNzAgT3JpdCBMZXZpbg0KNzEgU2FtIEFsZHJp bg0KNzIgUGF1bCBFYmVyc21hbg0KNzMgQ2hyaXN0b3BoZXIgTGlsamVuc3RvbHBlDQo3NCBVbWEg Q2h1bmR1cmkNCjc1IFN1cmVzaCBLcmlzaG5hbg0KNzYgVmFydW4gU2luZ2gNCjc3IFJvbiBCb25p Y2ENCjc4IEJpbGwgKFdpbGxpYW0pIE1hbm5pbmcNCjc5IFJhZGlhIFBlcmxtYW4NCjgwIERhbmll bGUgQ2VjY2FyZWxsaQ0KODEgRGVib3JhaCBCcnVuZ2FyZA0KODIgS29zdGFzIFBlbnRpa291c2lz DQo4MyBHcmVnb3J5IE1pcnNreQ0KODQgRGF2ZSBTaW5pY3JvcGUNCjg1IFRob21hcyBXYWxzaA0K ODYgWmhhb2h1aSAoSmVmZnJleSkgWkhBTkcNCjg3IFhpYW4gWkhBTkcNCjg4IE1hcmsgVG93bnNs ZXkNCjg5IEhhbm5lcyBHcmVkbGVyDQo5MCBCcmlhbiBUcmFtbWVsbA0KOTEgQ2FybG9zIE1hcnRp bmV6DQo5MiBQZXRlciBLb2NoDQo5MyBEYW5pZWwgTWlnYXVsdA0KOTQgWWkgKEFhcm9uKSBEaW5n DQo5NSBNaWNoYWVsIFJpY2hhcmRzb24NCjk2IFNvaGVsIEtoYW4NCjk3IEpvaG4gQnJhZGxleQ0K OTggSHVhaW1vIENoZW4NCjk5IE1hdHRoZXcgQ2FtcGFnbmENCjEwMCBLZWl0aCBEcmFnZQ0KMTAx IENocmlzIEJvd2Vycw0KMTAyIEpha29iIEhlaXR6DQoxMDMgVG9tb2Z1bWkgT2t1Ym8NCjEwNCBF bWlsIEl2b3YNCjEwNSBUaW1vdGh5IEIuIFRlcnJpYmVycnkNCjEwNiBKSUFORyBZdWFubG9uZw0K MTA3IEx1aWdpIElhbm5vbmUNCjEwOCBEYW1pZW4gU2F1Y2V6DQoxMDkgTG91IEJlcmdlcg0KMTEw IFlhbmEgU3RhbWNoZXZhDQoxMTEgT25kxZllaiBTdXLDvQ0KMTEyIE1hcmNpbiBQaWxhcnNraQ0K MTEzIE1pY2hhZWwgU3RKb2hucw0KMTE0IFdlcyBHZW9yZ2UNCjExNSBDaHJpc3RpYW4gTydGbGFo ZXJ0eQ0KMTE2IFV3ZSBSYXVzY2hlbmJhY2gNCjExNyBPbGFmdXIgR3VkbXVuZHNzb24NCjExOCBT aHdldGhhIFN1YnJheSBCaGFuZGFyaSoNCjExOSBUb2JpYXMgR29uZHJvbQ0KMTIwIENocmlzdGVy IEhvbG1iZXJnDQoxMjEgU3VzYW4gSGFyZXMNCjEyMiBLaXJhbiBLdW1hciBDaGl0dGltYW5lbmkN CjEyMyBEb25hbGQgRmVkeWsNCjEyNCBTdGVwaGVuIEJvdHprbyoNCjEyNSBMaSBYdWUqDQoxMjYg Sm9obiBTYXVlcioNCg== From turners@ieca.com Mon Jun 24 05:43:26 2013 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 9E1EA11E813A for ; Mon, 24 Jun 2013 05:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 HoMnbofWpFT3 for ; Mon, 24 Jun 2013 05:43:21 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.126.20]) by ietfa.amsl.com (Postfix) with ESMTP id F375611E813D for ; Mon, 24 Jun 2013 05:43:15 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 75E6F92FDE7F2; Mon, 24 Jun 2013 07:43:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 69A5B92FDE7BC for ; Mon, 24 Jun 2013 07:43:08 -0500 (CDT) Received: from [173.73.135.101] (port=53554 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ur671-0005Aq-92 for sacm@ietf.org; Mon, 24 Jun 2013 07:43:15 -0500 Message-ID: <51C83EE2.2020508@ieca.com> Date: Mon, 24 Jun 2013 08:43:14 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:53554 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:43:26 -0000 In case your curious you can watch the IESG comments here: https://datatracker.ietf.org/doc/charter-ietf-sacm/ballot/ Barry's and Spencer provided some early comments that I think are worth while and I thought I'd share them with you: 1) Identify the other SDOs, groups and organizations. This is really for the IAB to know who we'll be dealing with because they're responsible for liaisons. Shot me a couple ;) 2) Avoid some duplication (this is more of an FYI): OLD: Automating these routine tasks would free security practitioners to focus on high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. This working group will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security, freeing them to focus on more advanced tasks. NEW: Automating these routine tasks would allow security practitioners to work more effectively, focusing on more advanced and high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. To that end, this working group will define security automation protocols and data format standards in support of information security processes and practices. 3) From dbharrington@comcast.net Mon Jun 24 06:09:11 2013 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 4991921F8E77 for ; Mon, 24 Jun 2013 06:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 Iapw-0gDJeKs for ; Mon, 24 Jun 2013 06:09:05 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC8621E80E9 for ; Mon, 24 Jun 2013 06:09:05 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta15.westchester.pa.mail.comcast.net with comcast id sC8i1l0050ldTLk5FD94ND; Mon, 24 Jun 2013 13:09:04 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta04.westchester.pa.mail.comcast.net with comcast id sD941l00W2yZEBF01D944v; Mon, 24 Jun 2013 13:09:04 +0000 From: "David Harrington" To: "'Sean Turner'" , References: <51C83EE2.2020508@ieca.com> In-Reply-To: <51C83EE2.2020508@ieca.com> Date: Mon, 24 Jun 2013 09:08:51 -0400 Message-ID: <00ce01ce70db$f8ebba30$eac32e90$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbhKhFEIIJ9trysPKJwCV51ALq4Jiqrf1w Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372079344; bh=HhwXpkfIdh6xJiouZ8jjXpjZ8pr25x+xaZzRXlxQDR0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=NXrkYr4Z5fBDKpMsf6wMtsdLyOB17fv2v32ON/kVxV8dovMlvuYyP+1IIQzBVllcD +rxwx8cuBFAXnFXVTvXzKpRpG7k42pwWA6AMu9Q0tPgTZhmcYKfsIZwRT3a0h0ZyVY srHG6dqCFsGq83SINnEx7JAzg1ixyrr6tLA/FctexX+HD6uNGkLndhNPuPtLAMBchu Fymue/Gmxq4W0rwxSKEMkPlAs4Qak7wLiDj0wz8PImZqX0pyXPQAoCp/Zic6bB/7oy vcjI5v4lc3k1TL74/eVADXDRhom1y6n0bhADEQ0cASkMmqvR2nQLeB3qBTfmlvJD1h So5wr9Vuv3+4g== Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:09:11 -0000 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sean Turner Sent: Monday, June 24, 2013 8:43 AM To: sacm@ietf.org Subject: [sacm] sacm charter review [...] Automating these routine tasks would allow security practitioners to work more effectively, focusing on more advanced and high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. To that end, this working group will define security automation protocols and data format standards in support of information security processes and practices. [dbh>] Which information security processes and practices? As I try to edit the use-cases document, I am not finding much information about which processes and practices will be considered. David Harrington dbharrington@comcast.net +1-603-828-1401 _______________________________________________ From kathleen.moriarty@emc.com Mon Jun 24 07:35:19 2013 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 7FB0221E8110 for ; Mon, 24 Jun 2013 07:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 z4XMeqdQnAjd for ; Mon, 24 Jun 2013 07:35:15 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id EFFD721E8115 for ; Mon, 24 Jun 2013 07:35:12 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5OEZ5Fx001886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 10:35:06 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 24 Jun 2013 10:34:49 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5OEYi6C027766; Mon, 24 Jun 2013 10:34:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Mon, 24 Jun 2013 10:34:33 -0400 From: "Moriarty, Kathleen" To: Sean Turner , "sacm@ietf.org" Date: Mon, 24 Jun 2013 10:33:26 -0400 Thread-Topic: [sacm] sacm charter review Thread-Index: Ac5w2IQjCcWO1cazTFu0V3Bo+OrYdQAD0XhY Message-ID: References: <51C83EE2.2020508@ieca.com> In-Reply-To: <51C83EE2.2020508@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:35:19 -0000 The DMTF is a possibility for references to the Common Interface Model. We= will likely have interface points. Best regards, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Sean Turne= r [turners@ieca.com] Sent: Monday, June 24, 2013 8:43 AM To: sacm@ietf.org Subject: [sacm] sacm charter review In case your curious you can watch the IESG comments here: https://datatracker.ietf.org/doc/charter-ietf-sacm/ballot/ Barry's and Spencer provided some early comments that I think are worth while and I thought I'd share them with you: 1) Identify the other SDOs, groups and organizations. This is really for the IAB to know who we'll be dealing with because they're responsible for liaisons. Shot me a couple ;) 2) Avoid some duplication (this is more of an FYI): OLD: Automating these routine tasks would free security practitioners to focus on high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. This working group will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security, freeing them to focus on more advanced tasks= . NEW: Automating these routine tasks would allow security practitioners to work more effectively, focusing on more advanced and high priority tasks, and should improve operators' ability to prioritize risk based on timely information about threats and vulnerabilities. To that end, this working group will define security automation protocols and data format standards in support of information security processes and practices. 3) _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Mon Jun 24 07:43:46 2013 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 C022F21E8107 for ; Mon, 24 Jun 2013 07:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 lpyQDTcbc4WL for ; Mon, 24 Jun 2013 07:43:36 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id EB41A21F99EC for ; Mon, 24 Jun 2013 07:43:34 -0700 (PDT) Received: from mail49-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 14:43:34 +0000 Received: from mail49-ch1 (localhost [127.0.0.1]) by mail49-ch1-R.bigfish.com (Postfix) with ESMTP id 3EFE5100241 for ; Mon, 24 Jun 2013 14:43:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz9371I1b0bI542I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail49-ch1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=shanna@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1 (MessageSwitch) id 1372085012746428_11436; Mon, 24 Jun 2013 14:43:32 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail49-ch1.bigfish.com (Postfix) with ESMTP id A98E312004B for ; Mon, 24 Jun 2013 14:43:32 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.51) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 14:43:31 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 07:43:30 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 07:43:30 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 07:55:25 -0700 Received: from mail200-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 14:43:29 +0000 Received: from mail200-va3 (localhost [127.0.0.1]) by mail200-va3-R.bigfish.com (Postfix) with ESMTP id AB4DFD802EE for ; Mon, 24 Jun 2013 14:43:29 +0000 (UTC) Received: from mail200-va3 (localhost.localdomain [127.0.0.1]) by mail200-va3 (MessageSwitch) id 1372085007738947_24630; Mon, 24 Jun 2013 14:43:27 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.245]) by mail200-va3.bigfish.com (Postfix) with ESMTP id A78E5C0004B; Mon, 24 Jun 2013 14:43:27 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 14:43:27 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.63]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 14:43:26 +0000 From: Stephen Hanna To: "Moriarty, Kathleen" , Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh37nKSnCbwB0KyXIYmhwU2yplE7eEAgAAB5fA= Date: Mon, 24 Jun 2013 14:43:26 +0000 Message-ID: References: <51C83EE2.2020508@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%EMC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:43:47 -0000 Trusted Computing Group (TCG) has several standards such as IF-MAP that seem quite useful for SACM. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Monday, June 24, 2013 10:33 AM > To: Sean Turner; sacm@ietf.org > Subject: Re: [sacm] sacm charter review >=20 > The DMTF is a possibility for references to the Common Interface Model. > We will likely have interface points. >=20 > Best regards, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Sean > Turner [turners@ieca.com] > Sent: Monday, June 24, 2013 8:43 AM > To: sacm@ietf.org > Subject: [sacm] sacm charter review >=20 > In case your curious you can watch the IESG comments here: > https://datatracker.ietf.org/doc/charter-ietf-sacm/ballot/ >=20 > Barry's and Spencer provided some early comments that I think are worth > while and I thought I'd share them with you: >=20 > 1) Identify the other SDOs, groups and organizations. This is really > for the IAB to know who we'll be dealing with because they're > responsible for liaisons. Shot me a couple ;) >=20 > 2) Avoid some duplication (this is more of an FYI): >=20 > OLD: >=20 > Automating these routine tasks would free security practitioners to > focus on high priority tasks, and should improve operators' ability to > prioritize risk based on timely information about threats and > vulnerabilities. This working group will define security automation > protocols and data format standards in support of information security > processes and practices. These standards will help security > practitioners to be more effective by automating routine tasks related > to client and server security, freeing them to focus on more advanced > tasks. >=20 > NEW: >=20 > Automating these routine tasks would allow security practitioners to > work more effectively, focusing on more advanced and high priority > tasks, and should improve operators' ability to prioritize risk based > on > timely information about threats and vulnerabilities. To that end, > this > working group will define security automation protocols and data format > standards in support of information security processes and practices. >=20 > 3) > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Adam.Montville@cisecurity.org Mon Jun 24 08:54:01 2013 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 D9C4B21E8105 for ; Mon, 24 Jun 2013 08:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuHSmi5DNxCe for ; Mon, 24 Jun 2013 08:53:56 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.202]) by ietfa.amsl.com (Postfix) with ESMTP id ED24121E80E9 for ; Mon, 24 Jun 2013 08:53:55 -0700 (PDT) Received: from [216.82.242.179:17257] by server-10.bemta-8.messagelabs.com id F8/B2-02860-29B68C15; Mon, 24 Jun 2013 15:53:54 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-11.tower-86.messagelabs.com!1372089174!33181489!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 19433 invoked from network); 24 Jun 2013 15:52:54 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-11.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 24 Jun 2013 15:52:54 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 11:52:44 -0400 From: Adam Montville To: Stephen Hanna , "Moriarty, Kathleen" , Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh2rk93O9jxYkmrJ3EeM8R9BZlFMPAAgAACywD//87U8A== Date: Mon, 24 Jun 2013 15:52:43 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> References: <51C83EE2.2020508@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:54:01 -0000 There are a variety of other SDOs in which we could be interested now or i= n the future. The short-story list: * FIRST (vulnerability scoring) * DMTF (already mentioned) * TCG (already mentioned) * The Open Group (XDAS and others) * ISO (i.e. TagVault) * W3C (i.e. obvious things like XML DigSig, and potentially less obvious t= hings like RDF, OWL, SWRL, etc.) * OASIS (i.e. security assertions, key management, alerting) * OMG (i.e. Business Process Model Notation and/or Execution Language, etc= .) Please keep in mind the "or in the future" part of the first sentence :-) Adam > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Monday, June 24, 2013 7:44 AM > To: Moriarty, Kathleen; Sean Turner; sacm@ietf.org > Subject: Re: [sacm] sacm charter review >=20 > Trusted Computing Group (TCG) has several standards such as IF-MAP that > seem quite useful for SACM. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Moriarty, Kathleen > > Sent: Monday, June 24, 2013 10:33 AM > > To: Sean Turner; sacm@ietf.org > > Subject: Re: [sacm] sacm charter review > > > > The DMTF is a possibility for references to the Common Interface Model= . > > We will likely have interface points. > > > > Best regards, > > Kathleen > > ________________________________________ > > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Sean > > Turner [turners@ieca.com] > > Sent: Monday, June 24, 2013 8:43 AM > > To: sacm@ietf.org > > Subject: [sacm] sacm charter review > > > > In case your curious you can watch the IESG comments here: > > https://datatracker.ietf.org/doc/charter-ietf-sacm/ballot/ > > > > Barry's and Spencer provided some early comments that I think are > > worth while and I thought I'd share them with you: > > > > 1) Identify the other SDOs, groups and organizations. This is really > > for the IAB to know who we'll be dealing with because they're > > responsible for liaisons. Shot me a couple ;) > > > > 2) Avoid some duplication (this is more of an FYI): > > > > OLD: > > > > Automating these routine tasks would free security practitioners to > > focus on high priority tasks, and should improve operators' ability to= > > prioritize risk based on timely information about threats and > > vulnerabilities. This working group will define security automation > > protocols and data format standards in support of information security= > > processes and practices. These standards will help security > > practitioners to be more effective by automating routine tasks related= > > to client and server security, freeing them to focus on more advanced > > tasks. > > > > NEW: > > > > Automating these routine tasks would allow security practitioners to > > work more effectively, focusing on more advanced and high priority > > tasks, and should improve operators' ability to prioritize risk based > > on timely information about threats and vulnerabilities. To that end,= > > this working group will define security automation protocols and data > > format standards in support of information security processes and > > practices. > > > > 3) > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... 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 tony@yaanatech.com Mon Jun 24 09:48:03 2013 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 F040921E811E for ; Mon, 24 Jun 2013 09:48:02 -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 z9vPktS2TDOw for ; Mon, 24 Jun 2013 09:47:57 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id E021221E8139 for ; Mon, 24 Jun 2013 09:47:57 -0700 (PDT) Received: from [192.168.0.7] (pool-173-72-136-225.clppva.fios.verizon.net [173.72.136.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id AE4055808A; Mon, 24 Jun 2013 16:47:55 +0000 (UTC) Message-ID: <51C8783A.4040402@yaanatech.com> Date: Mon, 24 Jun 2013 12:47:54 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Montville References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080204050409070200070409" Cc: Sean Turner , Stephen Hanna , "Moriarty, Kathleen" , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:48:03 -0000 This is a cryptographically signed message in MIME format. --------------ms080204050409070200070409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable SDO is an undesirable legacy term. Pathetically, the old SDO club still does not regard the IETF as a "SDO!" http://www.tta.or.kr/English/new/external_relations/gsc17_communique.jsp Perhaps it is better to simply use "standards fora." You should consider including: NIST, MITRE, and 3GPP - all of which are well recognized as key standards bodies currently engaged in SACM related work with whom you should be interested now. -t On 6/24/2013 11:52 AM, Adam Montville wrote: > There are a variety of other SDOs in which we could be interested now o= r in the future. The short-story list: > > * FIRST (vulnerability scoring) > * DMTF (already mentioned) > * TCG (already mentioned) > * The Open Group (XDAS and others) > * ISO (i.e. TagVault) > * W3C (i.e. obvious things like XML DigSig, and potentially less obviou= s things like RDF, OWL, SWRL, etc.) > * OASIS (i.e. security assertions, key management, alerting) > * OMG (i.e. Business Process Model Notation and/or Execution Language, = etc.) --------------ms080204050409070200070409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINDTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbDMIIFq6ADAgECAhBT hNb1O1n4bTJo0Ah1+gicMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAzMDgwMDAwMDBa Fw0xNDAzMDkyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzYyNzM4NTgzNTAzMSEwHwYJKoZIhvcNAQkBFhJ0b255QHlhYW5hdGVjaC5jb20xDzANBgNV BAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTsANG1JvM4PXw45I4MAIPHPeu6urf2 ml82bH8tuyaGBzUX8AaxBPzChNDbng2wU264FzNKHOVQbiFAH14Xxb1Ih5uPvWh45feCO7PU tSlkdHQSzilC8aOWEdy4+DZXzujp331xSZkjbT1iNWBhjhXubJTDwiYQWT0MBiN3A2IWC+1a PVQvzSZyLLrM7QexO0A3fGuzWtJ9RMUBw++KuB3FQ/nM5iyKhfu2tfP7yiBV4rlwWdbbNe02 PLs2qwMPxIja/JT6tUdgjTn04XUynFgAbTVZniUkra+OodXxk9JGeIGgB+GorAwT0x/TcDeN +DXoHfiBSso2Vmvwx+JkFNECAwEAAaOCAsswggLHMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/ BAQDAgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU+ENL NB52WskhlVdfucmC2XHR4Y8wHQYDVR0RBBYwFIESdG9ueUB5YWFuYXRlY2guY29tMB8GA1Ud IwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUG CCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIw U3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTIw LSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRhdGVkJTJDJTIw T1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7 YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0g BGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGgu Y29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpg hkgBhvhFARADBBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUA A4IBAQDGN/ju6G1Df12wYlBSOzo39vOfJuVASX31X0WWvLieGYzIFPY1IRubH/TCfsUmdGxT 12q1Y6zm1nK+wmPg1xOFhgJNK9+Tfixu2WoKtkG5ZCeWcv48tyUGcr6+UHfvSdLxSQfmNuEU 6T30xH9zEkzChmI9FoUP4V+DjS49bbP9b3KlMNkJDOKrVNI5I233qmYxZZYatMartahrBIwy Qfgor3+M/O8QYzYCAeSMwtpNYNqNXOlLBSCbGt4Y1Kdz7Xgg0fD49vMvRloZ3cMCCv2cLeg2 WlbxotVsn9IbWHq4CZbUKytgREtcbHUgbiIrYnlC4rcSxjX71W1W/u/gDNqgMYIEUjCCBE4C AQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEf MB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEc0AhBThNb1O1n4bTJo0Ah1+gicMAkGBSsOAwIaBQCgggJrMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYyNDE2NDc1NFowIwYJKoZI hvcNAQkEMRYEFHU94i1RxaLONDtlpJp159C5srXCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcwGCSsGAQQBgjcQBDGBvjCBuzCB pjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzQCEFOE1vU7WfhtMmjQCHX6CJwwgc4GCyqGSIb3DQEJEAILMYG+oIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQ U4TW9TtZ+G0yaNAIdfoInDANBgkqhkiG9w0BAQEFAASCAQAIXwxta7/gJQYFD/7ypZTTsfLV o82HnmFUh7h0WL0gWeQBoP8dqrA8BwNEghF2t8i7d7RudCBdWXMQbMuserB0PYDWKt2JqZNp Pn2QeUO4csf5salf+OYir5A6PM07gLyoUTEsDwX0XVptKzkJP6vL2NNgSagViwNr96dxAykB roRzBziDqmvDNwl65dbapVhuHbeYdSEk+C9McqwzhmaCtmsQhN0fVRiuntd4Dt56FfqCdxQy lbpw2/DR4Ofrr6Lbvyw9ntogGXWzzBWOEzIscVXv59tmkOsNl3/uYYAITmStKm0AyHX3YEwX Axb746XcyLAQKEXGQ4tc0IbRVbVnAAAAAAAA --------------ms080204050409070200070409-- From turners@ieca.com Mon Jun 24 16:05:51 2013 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 C7C8A21F9F44 for ; Mon, 24 Jun 2013 16:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 eCJ2DCQ9QwAj for ; Mon, 24 Jun 2013 16:05:46 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.41.247.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2691821F9EE2 for ; Mon, 24 Jun 2013 16:05:41 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 62242A3ED20CC; Mon, 24 Jun 2013 18:05:33 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 56852A3ED2089 for ; Mon, 24 Jun 2013 18:05:33 -0500 (CDT) Received: from [173.73.135.101] (port=54329 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UrFpM-0003Lj-9j; Mon, 24 Jun 2013 18:05:40 -0500 Message-ID: <51C8D0C3.3000909@ieca.com> Date: Mon, 24 Jun 2013 19:05:39 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tony@yaanatech.com References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> <51C8783A.4040402@yaanatech.com> In-Reply-To: <51C8783A.4040402@yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:54329 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Moriarty, Kathleen" , Stephen Hanna , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 23:05:51 -0000 On 6/24/13 12:47 PM, Tony Rutkowski wrote: > SDO is an undesirable legacy term. > Pathetically, the old SDO club still > does not regard the IETF as a "SDO!" > http://www.tta.or.kr/English/new/external_relations/gsc17_communique.jsp > > Perhaps it is better to simply use > "standards fora." I'm not against just saying organization too. I don't want to get in to arguments about what's an SDO and what's not. spt > You should consider including: NIST, > MITRE, and 3GPP - all of which are > well recognized as key standards bodies > currently engaged in SACM related work > with whom you should be interested now. > > -t > > On 6/24/2013 11:52 AM, Adam Montville wrote: >> There are a variety of other SDOs in which we could be interested now >> or in the future. The short-story list: >> >> * FIRST (vulnerability scoring) >> * DMTF (already mentioned) >> * TCG (already mentioned) >> * The Open Group (XDAS and others) >> * ISO (i.e. TagVault) >> * W3C (i.e. obvious things like XML DigSig, and potentially less >> obvious things like RDF, OWL, SWRL, etc.) >> * OASIS (i.e. security assertions, key management, alerting) >> * OMG (i.e. Business Process Model Notation and/or Execution Language, >> etc.) > > From dromasca@avaya.com Tue Jun 25 01:08:00 2013 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 DFA5521F9FCB for ; Tue, 25 Jun 2013 01:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py3lMUOP0AEw for ; Tue, 25 Jun 2013 01:07:55 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A828E21F9362 for ; Tue, 25 Jun 2013 01:07:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoIAI5OyVGHCzI1/2dsb2JhbABagmghMUmrLZQKfxZ0giMBAQEBAgEBAQEPKDQEBwUHBAIBCA0EBAEBAQoUCQcnCxQJCAIEAQ0FCBqHZgYBC55qm3sXjx4xBwaCfGEDngeLAIMQgig X-IronPort-AV: E=Sophos;i="4.87,934,1363147200"; d="scan'208";a="17577613" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 25 Jun 2013 04:07:44 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jun 2013 04:02:27 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 04:07:42 -0400 From: "Romascanu, Dan (Dan)" To: Sean Turner , "tony@yaanatech.com" Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh6y/yJrU4AjEmUc/AYGz5tQplFMPAAgAACywCAABNbgIAAD2sAgAAE9oCAALVK8A== Date: Tue, 25 Jun 2013 08:07:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.com> References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> <51C8783A.4040402@yaanatech.com> <51C8D0C3.3000909@ieca.com> In-Reply-To: <51C8D0C3.3000909@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Montville , Stephen Hanna , "Moriarty, Kathleen" , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:08:01 -0000 The proposed text in the charter already says:=20 > In accordance with existing IETF processes, the group will communicate wi= th and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or req= uest the establishment of new liaison relationships. 'standard bodies and regulatory organizations' are neutral terms enough IMO= , as Sean says we should not enter the 'what is an SDO dispute'. We are dea= ling not only with standards organizations and this is also reflected in th= e current text.=20 Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Tuesday, June 25, 2013 2:06 AM > To: tony@yaanatech.com > Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org > Subject: Re: [sacm] sacm charter review >=20 > On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > SDO is an undesirable legacy term. > > Pathetically, the old SDO club still > > does not regard the IETF as a "SDO!" > > http://www.tta.or.kr/English/new/external_relations/gsc17_communique.j > > sp > > > > Perhaps it is better to simply use > > "standards fora." >=20 > I'm not against just saying organization too. I don't want to get in to > arguments about what's an SDO and what's not. >=20 > spt >=20 > > You should consider including: NIST, > > MITRE, and 3GPP - all of which are > > well recognized as key standards bodies currently engaged in SACM > > related work with whom you should be interested now. > > > > -t > > > > On 6/24/2013 11:52 AM, Adam Montville wrote: > >> There are a variety of other SDOs in which we could be interested now > >> or in the future. The short-story list: > >> > >> * FIRST (vulnerability scoring) > >> * DMTF (already mentioned) > >> * TCG (already mentioned) > >> * The Open Group (XDAS and others) > >> * ISO (i.e. TagVault) > >> * W3C (i.e. obvious things like XML DigSig, and potentially less > >> obvious things like RDF, OWL, SWRL, etc.) > >> * OASIS (i.e. security assertions, key management, alerting) > >> * OMG (i.e. Business Process Model Notation and/or Execution > >> Language, > >> etc.) > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Jun 25 04:42:16 2013 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 01BEE21F9E07 for ; Tue, 25 Jun 2013 04:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 9dJ1Msn4Q3bi for ; Tue, 25 Jun 2013 04:42:11 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6744821F915B for ; Tue, 25 Jun 2013 04:42: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.3.123.3; Tue, 25 Jun 2013 07:41:51 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 25 Jun 2013 07:42:06 -0400 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , Sean Turner , "tony@yaanatech.com" Date: Tue, 25 Jun 2013 07:42:06 -0400 Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh6y/yJrU4AjEmUc/AYGz5tQplFMPAAgAACywCAABNbgIAAD2sAgAAE9oCAALVK8IAAOWAQ Message-ID: References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> <51C8783A.4040402@yaanatech.com> <51C8D0C3.3000909@ieca.com> <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.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: "Moriarty, Kathleen" , Stephen Hanna , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:42:16 -0000 It sounds like there are two items under discussion in this thread. 1) Sean's original question, what other SDOs, groups and organizations will the IAB need to deal with regarding liaison relationships? The ISO/IEC 18180:2013, Information technology -- Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.2 was published on June 15, 2013. It is freely available here: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ISO JTC1 is ready to consider placement of the document in SC27 or transfer to the IETF SACM WG. If we are interested in transitioning this to the IETF we need to start this discussion at the July INCITS EB meeting. This is something that we need to consider as a WG and is something that the IAB will likely need to work on if we want to bring it here. Sean, do you have any thoughts/guidance on this item. 2) What organizations would might have work that is relevant to contribute to SACM? +1 on Dan's point. The "what is a SDO debate?" is not helpful here. If an organization outside the IETF is interested in contributing work that supports SACM, we should encourage those contributions per the IETFs rules on IPR. I think the wording in the charter is supportive of this. Thanks, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Tuesday, June 25, 2013 4:08 AM > To: Sean Turner; tony@yaanatech.com > Cc: Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org > Subject: Re: [sacm] sacm charter review > > The proposed text in the charter already says: > > > In accordance with existing IETF processes, the group will communicate > > with and > invite participation from other relevant standards bodies and regulatory > organizations, and if necessary reuse existing liaison relationships or request > the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough > IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are > dealing not only with standards organizations and this is also reflected in the > current text. > > Regards, > > Dan > > > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Sean Turner > > Sent: Tuesday, June 25, 2013 2:06 AM > > To: tony@yaanatech.com > > Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org > > Subject: Re: [sacm] sacm charter review > > > > On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > > SDO is an undesirable legacy term. > > > Pathetically, the old SDO club still does not regard the IETF as a > > > "SDO!" > > > > http://www.tta.or.kr/English/new/external_relations/gsc17_communique > > > .j > > > sp > > > > > > Perhaps it is better to simply use > > > "standards fora." > > > > I'm not against just saying organization too. I don't want to get in > > to arguments about what's an SDO and what's not. > > > > spt > > > > > You should consider including: NIST, MITRE, and 3GPP - all of which > > > are well recognized as key standards bodies currently engaged in > > > SACM related work with whom you should be interested now. > > > > > > -t > > > > > > On 6/24/2013 11:52 AM, Adam Montville wrote: > > >> There are a variety of other SDOs in which we could be interested > > >> now or in the future. The short-story list: > > >> > > >> * FIRST (vulnerability scoring) > > >> * DMTF (already mentioned) > > >> * TCG (already mentioned) > > >> * The Open Group (XDAS and others) > > >> * ISO (i.e. TagVault) > > >> * W3C (i.e. obvious things like XML DigSig, and potentially less > > >> obvious things like RDF, OWL, SWRL, etc.) > > >> * OASIS (i.e. security assertions, key management, alerting) > > >> * OMG (i.e. Business Process Model Notation and/or Execution > > >> Language, > > >> etc.) > > > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Tue Jun 25 05:47:01 2013 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 3D74021F9385 for ; Tue, 25 Jun 2013 05:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 G6uxftM6DnGr for ; Tue, 25 Jun 2013 05:46:56 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.164.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC9321F9605 for ; Tue, 25 Jun 2013 05:46:56 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 13992A5EC42E0; Tue, 25 Jun 2013 07:46:56 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 07573A5EC42AE for ; Tue, 25 Jun 2013 07:46:56 -0500 (CDT) Received: from [173.73.135.101] (port=55713 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UrSe6-0002E5-LH; Tue, 25 Jun 2013 07:46:54 -0500 Message-ID: <51C9913D.4000007@ieca.com> Date: Tue, 25 Jun 2013 08:46:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> <51C8783A.4040402@yaanatech.com> <51C8D0C3.3000909@ieca.com> <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:55713 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Moriarty, Kathleen" , Stephen Hanna , Adam Montville , "sacm@ietf.org" , "tony@yaanatech.com" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:47:01 -0000 At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will communicate with and > invite participation from other relevant standards bodies and regulatory > organizations, and if necessary reuse existing liaison relationships or request > the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To: tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still >>> does not regard the IETF as a "SDO!" >>> http://www.tta.or.kr/English/new/external_relations/gsc17_communique.j >>> sp >>> >>> Perhaps it is better to simply use >>> "standards fora." >> >> I'm not against just saying organization too. I don't want to get in to >> arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, >>> MITRE, and 3GPP - all of which are >>> well recognized as key standards bodies currently engaged in SACM >>> related work with whom you should be interested now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be interested now >>>> or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 dromasca@avaya.com Tue Jun 25 06:17:53 2013 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 0A80A21E8096 for ; Tue, 25 Jun 2013 06:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kPGpzb-Z65aE for ; Tue, 25 Jun 2013 06:17:47 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52421E8082 for ; Tue, 25 Jun 2013 06:17:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtULAKWXyVHGmAcF/2dsb2JhbABagmghMUmrLpQLgQEWdIIjAQEBAQMBAQEPKDQEBwwEAgEIDQQEAQEBChQJBycLFAkIAgQOBQgah2wBC55/m3kXjxQxBwaCfGEDngeLAIMQgig X-IronPort-AV: E=Sophos;i="4.87,936,1363147200"; d="scan'208";a="14355627" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jun 2013 09:17:44 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jun 2013 09:15:23 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 09:17:42 -0400 From: "Romascanu, Dan (Dan)" To: Sean Turner Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh6y/yJrU4AjEmUc/AYGz5tQplFMPAAgAACywCAABNbgIAAD2sAgAAE9oCAALVK8IAAlL6A///CuBA= Date: Tue, 25 Jun 2013 13:17:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1ADBBD@AZ-FFEXMB04.global.avaya.com> References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> <51C8783A.4040402@yaanatech.com> <51C8D0C3.3000909@ieca.com> <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.com> <51C9913D.4000007@ieca.com> In-Reply-To: <51C9913D.4000007@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Moriarty, Kathleen" , Stephen Hanna , Adam Montville , "sacm@ietf.org" , "tony@yaanatech.com" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:17:53 -0000 Hi Sean, A list of organizations that are involved in the area, as identified in thi= s discussion includes:=20 - TCG - DMTF - FIRST=20 - The Open Group=20 - ISO/IEC=20 - W3C=20 - OASIS=20 - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) exp= licitly, or we should leave to the WG after its formation is approved to in= itiate communication and invite participation.=20 Regards, Dan > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tuesday, June 25, 2013 3:47 PM > To: Romascanu, Dan (Dan) > Cc: tony@yaanatech.com; Adam Montville; Stephen Hanna; Moriarty, > Kathleen; sacm@ietf.org > Subject: Re: [sacm] sacm charter review >=20 > At this point 3 ADs have asked about what other SDOs are involved. I'm > not sure if they want names in the charter or if they're just interested > in knowing. >=20 > spt >=20 > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > The proposed text in the charter already says: > > > >> In accordance with existing IETF processes, the group will > >> communicate with and > > invite participation from other relevant standards bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > > > 'standard bodies and regulatory organizations' are neutral terms > enough IMO, as Sean says we should not enter the 'what is an SDO > dispute'. We are dealing not only with standards organizations and this > is also reflected in the current text. > > > > Regards, > > > > Dan > > > > > > > > > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of Sean Turner > >> Sent: Tuesday, June 25, 2013 2:06 AM > >> To: tony@yaanatech.com > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org > >> Subject: Re: [sacm] sacm charter review > >> > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > >>> SDO is an undesirable legacy term. > >>> Pathetically, the old SDO club still does not regard the IETF as a > >>> "SDO!" > >>> http://www.tta.or.kr/English/new/external_relations/gsc17_communique > >>> .j > >>> sp > >>> > >>> Perhaps it is better to simply use > >>> "standards fora." > >> > >> I'm not against just saying organization too. I don't want to get in > >> to arguments about what's an SDO and what's not. > >> > >> spt > >> > >>> You should consider including: NIST, MITRE, and 3GPP - all of which > >>> are well recognized as key standards bodies currently engaged in > >>> SACM related work with whom you should be interested now. > >>> > >>> -t > >>> > >>> On 6/24/2013 11:52 AM, Adam Montville wrote: > >>>> There are a variety of other SDOs in which we could be interested > >>>> now or in the future. The short-story list: > >>>> > >>>> * FIRST (vulnerability scoring) > >>>> * DMTF (already mentioned) > >>>> * TCG (already mentioned) > >>>> * The Open Group (XDAS and others) > >>>> * ISO (i.e. TagVault) > >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less > >>>> obvious things like RDF, OWL, SWRL, etc.) > >>>> * OASIS (i.e. security assertions, key management, alerting) > >>>> * OMG (i.e. Business Process Model Notation and/or Execution > >>>> Language, > >>>> etc.) > >>> > >>> > >> _______________________________________________ > >> 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 dbharrington@comcast.net Tue Jun 25 06:43:11 2013 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 C861411E810F for ; Tue, 25 Jun 2013 06:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 eVEaOoaIMcru for ; Tue, 25 Jun 2013 06:43:07 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 341A71F0D34 for ; Tue, 25 Jun 2013 06:43:07 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id sb9P1l0060bG4ec5Cdj6RE; Tue, 25 Jun 2013 13:43:06 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta03.westchester.pa.mail.comcast.net with comcast id sdj61l00T2yZEBF3Pdj6E4; Tue, 25 Jun 2013 13:43:06 +0000 From: "David Harrington" To: "'Sean Turner'" , References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> <51C8783A.4040402@yaanatech.com> <51C8D0C3.3000909@ieca.com> <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.com> <51C9913D.4000007@ieca.com> <9904FB1B0159DA42B0B887B7FA8119CA1ADBBD@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1ADBBD@AZ-FFEXMB04.global.avaya.com> Date: Tue, 25 Jun 2013 09:42:52 -0400 Message-ID: <019801ce71a9$e417f4b0$ac47de10$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbhKhFEIIJ9trysPKJwCV51ALq4AHPoLQaAczTuSkBu7umygHh6Eo7AqL3tE0BxepIogL8ahP8AgmFZ42YJwGIEA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372167786; bh=tclStll0tuvP4gTwT/JiekfJ4Iw4V3MD0BO6iFa7Rdg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=LQTCjp9Yn3M8K7TNu74xiuMmxU0Ienak62MA6bDm+CfPmKG7kqotY2bDlF4Vyfh5Z NTGg5R0xQZBT/wayOY7clR93rSwRM2ptZssk2lZtnGHXto5s2Imc+WzLT8bf6HIT+O 3IJADO+Ea3TcJH4xrTOr12oUe5PTzp2n3Z+GL5EfBklzztrfbJBJNbXZ0aUSUzzzw9 bG0s1Nqroh44h5pPcvoQmSQEAVPMX4sCuZ7ToWaqsfsOBfqqYFzKQDB+EPz8GbYpJZ nPYU6IvY5AdQIR78jIi7hcK0jfVeg3Wu3IlMXjKtsrv3r8+zTREjqoxslM4TTWiB/l wAKX0ErdWjqaw== Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:43:12 -0000 Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tuesday, June 25, 2013 3:47 PM > To: Romascanu, Dan (Dan) > Cc: tony@yaanatech.com; Adam Montville; Stephen Hanna; Moriarty, > Kathleen; sacm@ietf.org > Subject: Re: [sacm] sacm charter review > > At this point 3 ADs have asked about what other SDOs are involved. > I'm not sure if they want names in the charter or if they're just > interested in knowing. > > spt > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > The proposed text in the charter already says: > > > >> In accordance with existing IETF processes, the group will > >> communicate with and > > invite participation from other relevant standards bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > > > 'standard bodies and regulatory organizations' are neutral terms > enough IMO, as Sean says we should not enter the 'what is an SDO > dispute'. We are dealing not only with standards organizations and > this is also reflected in the current text. > > > > Regards, > > > > Dan > > > > > > > > > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf Of Sean Turner > >> Sent: Tuesday, June 25, 2013 2:06 AM > >> To: tony@yaanatech.com > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; > >> sacm@ietf.org > >> Subject: Re: [sacm] sacm charter review > >> > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > >>> SDO is an undesirable legacy term. > >>> Pathetically, the old SDO club still does not regard the IETF as a > >>> "SDO!" > >>> http://www.tta.or.kr/English/new/external_relations/gsc17_communiq > >>> ue > >>> .j > >>> sp > >>> > >>> Perhaps it is better to simply use "standards fora." > >> > >> I'm not against just saying organization too. I don't want to get > >> in to arguments about what's an SDO and what's not. > >> > >> spt > >> > >>> You should consider including: NIST, MITRE, and 3GPP - all of > >>> which are well recognized as key standards bodies currently > >>> engaged in SACM related work with whom you should be interested now. > >>> > >>> -t > >>> > >>> On 6/24/2013 11:52 AM, Adam Montville wrote: > >>>> There are a variety of other SDOs in which we could be interested > >>>> now or in the future. The short-story list: > >>>> > >>>> * FIRST (vulnerability scoring) > >>>> * DMTF (already mentioned) > >>>> * TCG (already mentioned) > >>>> * The Open Group (XDAS and others) > >>>> * ISO (i.e. TagVault) > >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less > >>>> obvious things like RDF, OWL, SWRL, etc.) > >>>> * OASIS (i.e. security assertions, key management, alerting) > >>>> * OMG (i.e. Business Process Model Notation and/or Execution > >>>> Language, > >>>> etc.) > >>> > >>> > >> _______________________________________________ > >> 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 Adam.Montville@cisecurity.org Tue Jun 25 08:15:24 2013 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 5FD8821F9D65 for ; Tue, 25 Jun 2013 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk4D2gF9zk8B for ; Tue, 25 Jun 2013 08:15:19 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.99]) by ietfa.amsl.com (Postfix) with ESMTP id B1B1421F9E45 for ; Tue, 25 Jun 2013 08:15:19 -0700 (PDT) Received: from [216.82.253.243:37096] by server-3.bemta-7.messagelabs.com id 0D/C8-21527-604B9C15; Tue, 25 Jun 2013 15:15:18 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-14.tower-171.messagelabs.com!1372173316!19374568!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 24480 invoked from network); 25 Jun 2013 15:15:17 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-14.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jun 2013 15:15:17 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 11:15:04 -0400 From: Adam Montville To: David Harrington , 'Sean Turner' , "sacm@ietf.org" Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh2rk93O9jxYkmrJ3EeM8R9BZlFMPAAgAACywD//87U8IAAU/IAgABpi4CAAJdzAIAATgCAgAAInQCAAAcIAP//1J+w Date: Tue, 25 Jun 2013 15:15:04 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6701AAF@CISEXCHANGE1.msisac.org.local> References: <51C83EE2.2020508@ieca.com> <05BCCEB107AF88469B9F99783D47C1D67005D7@CISEXCHANGE1.msisac.org.local> <51C8783A.4040402@yaanatech.com> <51C8D0C3.3000909@ieca.com> <9904FB1B0159DA42B0B887B7FA8119CA1AD4B0@AZ-FFEXMB04.global.avaya.com> <51C9913D.4000007@ieca.com> <9904FB1B0159DA42B0B887B7FA8119CA1ADBBD@AZ-FFEXMB04.global.avaya.com>, <019801ce71a9$e417f4b0$ac47de10$@comcast.net> In-Reply-To: <019801ce71a9$e417f4b0$ac47de10$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:15:24 -0000 Hi David, I respectfully disagree. =20 While this may be a commentary on the potential, eventual reach of SACM, o= ur charter's scope is far reduced from including all of these organization= s at the outset. In other words, our scope is limited by the language in = the charter, against which this list really has no bearing other than to s= atisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizatio= ns is a commentary on the ubiquitous nature of assessment - it is a capabi= lity that "touches" a lot of different areas, which is precisely why it wa= rrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David Har= rington [dbharrington@comcast.net] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too= broad,=20and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in th= is discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) explicitly, or we should leave to the WG after its formation is approved t= o initiate communication and invite participation. Regards, Dan > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tuesday, June 25, 2013 3:47 PM > To: Romascanu, Dan (Dan) > Cc: tony@yaanatech.com; Adam Montville; Stephen Hanna; Moriarty, > Kathleen; sacm@ietf.org > Subject: Re: [sacm] sacm charter review > > At this point 3 ADs have asked about what other SDOs are involved. > I'm not sure if they want names in the charter or if they're just > interested in knowing. > > spt > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > The proposed text in the charter already says: > > > >> In accordance with existing IETF processes, the group will > >> communicate with and > > invite participation from other relevant standards bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > > > 'standard bodies and regulatory organizations' are neutral terms > enough IMO, as Sean says we should not enter the 'what is an SDO > dispute'. We are dealing not only with standards organizations and > this is also reflected in the current text. > > > > Regards, > > > > Dan > > > > > > > > > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf Of Sean Turner > >> Sent: Tuesday, June 25, 2013 2:06 AM > >> To: tony@yaanatech.com > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; > >> sacm@ietf.org > >> Subject: Re: [sacm] sacm charter review > >> > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > >>> SDO is an undesirable legacy term. > >>> Pathetically, the old SDO club still does not regard the IETF as a > >>> "SDO!" > >>> http://www.tta.or.kr/English/new/external_relations/gsc17_communiq > >>> ue > >>> .j > >>> sp > >>> > >>> Perhaps it is better to simply use "standards fora." > >> > >> I'm not against just saying organization too. I don't want to get > >> in to arguments about what's an SDO and what's not. > >> > >> spt > >> > >>> You should consider including: NIST, MITRE, and 3GPP - all of > >>> which are well recognized as key standards bodies currently > >>> engaged in SACM related work with whom you should be interested now.= > >>> > >>> -t > >>> > >>> On 6/24/2013 11:52 AM, Adam=20Montville wrote: > >>>> There are a variety of other SDOs in which we could be interested > >>>> now or in the future. The short-story list: > >>>> > >>>> * FIRST (vulnerability scoring) > >>>> * DMTF (already mentioned) > >>>> * TCG (already mentioned) > >>>> * The Open Group (XDAS and others) > >>>> * ISO (i.e. TagVault) > >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less > >>>> obvious things like RDF, OWL, SWRL, etc.) > >>>> * OASIS (i.e. security assertions, key management, alerting) > >>>> * OMG (i.e. Business Process Model Notation and/or Execution > >>>> Language, > >>>> etc.) > >>> > >>> > >> _______________________________________________ > >> 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 ... 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 Kent_Landfield@mcafee.com Tue Jun 25 08:26:18 2013 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 C55ED11E80EF for ; Tue, 25 Jun 2013 08:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw+dT5k0qtJo for ; Tue, 25 Jun 2013 08:26:14 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6D82021E8091 for ; Tue, 25 Jun 2013 08:26:14 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 5c88_3bde_8651d15c_826c_46f5_ae78_d3dbeb62a010; Tue, 25 Jun 2013 10:26:08 -0500 Received: from MIVEXENGN3.corp.nai.org (10.48.48.53) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 25 Jun 2013 11:24:13 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXENGN3.corp.nai.org ([169.254.3.84]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 11:24:13 -0400 From: To: , , , Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhuvQoRthgPdUqZE3J5Z9Ln/5lFMPAAgAACywCAABNbgIAAD2wAgABpioCAAJdzAIAATgCAgAAInQCAAAcIAIAAGcIAgAAkFIA= Date: Tue, 25 Jun 2013 15:24:12 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2B5BD7@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6701AAF@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2B5BD7MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:26:18 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2B5BD7MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well said Adam. I totally agree with your comments. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Tuesday, June 25, 2013 5:15 PM To: David Harrington >, Sean Turner >, "sacm@ietf.= org" > Subject: Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, ou= r charter's scope is far reduced from including all of these organizations = at the outset. In other words, our scope is limited by the language in the= charter, against which this list really has no bearing other than to satis= fy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organization= s is a commentary on the ubiquitous nature of assessment - it is a capabili= ty that "touches" a lot of different areas, which is precisely why it warra= nts its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] on behalf of David Harrington [dbharri= ngton@comcast.net] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in thi= s discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com; Adam Montville; Stephen = Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-b= ounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To: tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >> sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF as a >>> "SDO!" >>> http://www.tta.or.kr/English/new/external_relations/gsc17_communiq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be interested now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be interested >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF2B5BD7MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

From: Adam Montville <Adam.Montville@cisecurity.org>= ;
Date: Tuesday, June 25, 2013 5:15 P= M
To: David Harrington <dbharrington@comcast.net>, Sean Tu= rner <turners@ieca.com>, &quo= t;sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] sacm charter re= view

Hi David,

I respectfully disagree.  

While this may be a commentary on the potential, eventual reach of SAC= M, our charter's scope is far reduced from including all of these organizat= ions at the outset.  In other words, our scope is limited by the = language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, l= end some vision to the future.

In fact, it might be more properly construed that this list of organiz= ations is a commentary on the ubiquitous nature of assessment - it is a cap= ability that "touches" a lot of different areas, which is precise= ly why it warrants its own working group, IMO.

Regards,

Adam



________________________________________
Sent: Tuesday, June 25, 2013 6:43 AM
To: 'Sean Turner'; sacm@ietf.org<= /div>
Subject: Re: [sacm] sacm charter review

Wow!
I think this is an excellent commentary on the scope of SACM being way= too
broad, and poorly scoped for engineering purposes.

David Harrington
+1-603-828-1401

-----Original Message-----
Romascanu, Dan (Dan)
Sent: Tuesday, June 25, 2013 9:18 AM
To: Sean Turner
Subject: Re: [sacm] sacm charter review

Hi Sean,

A list of organizations that are involved in the area, as identified i= n this
discussion includes:

- TCG
- DMTF
- FIRST
- The Open Group
- ISO/IEC
- W3C
- OASIS
- OMG
- NIST
- MITRE
- 3GPP

It's up to the IESG to decide if we should list these (or some of them= )
explicitly, or we should leave to the WG after its formation is approv= ed to
initiate communication and invite participation.

Regards,

Dan




-----Original Message-----
From: Sean Turner [mailto:turners@= ieca.com]
Sent: Tuesday, June 25, 2013 3:47 PM
To: Romascanu, Dan (Dan)
Cc: tony@yaanatech.com; Adam= Montville; Stephen Hanna; Moriarty,
Kathleen; sacm@ietf.org
Subject: Re: [sacm] sacm charter review

At this point 3 ADs have asked about what other SDOs are involved.
I'm not sure if they want names in the charter or if they're just
interested in knowing.

spt

On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote:
> The proposed text in the charter already says:
>
>> In accordance with existing IETF processes, the group will
>> communicate with and
> invite participation from other relevant standards bodies and
> regulatory organizations, and if necessary reuse existing liaison=
> relationships or request the establishment of new liaison
relationships.
>
> 'standard bodies and regulatory organizations' are neutral terms<= /div>
enough IMO, as Sean says we should not enter the 'what is an SDO
dispute'. We are dealing not only with standards organizations and
this is also reflected in the current text.
>
> Regards,
>
> Dan
>
>
>
>
>
>> -----Original Message-----
>> Behalf Of Sean Turner
>> Sent: Tuesday, June 25, 2013 2:06 AM
>> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville;
>> Subject: Re: [sacm] sacm charter review
>>
>> On 6/24/13 12:47 PM, Tony Rutkowski wrote:
>>> SDO is an undesirable legacy term.
>>> Pathetically, the old SDO club still does not regard the = IETF as a
>>> "SDO!"
>>> http://www.tta.or.kr/English/new/external_relations/gsc17_communiq
>>> ue
>>> .j
>>> sp
>>>
>>> Perhaps it is better to simply use "standards fora.&= quot;
>>
>> I'm not against just saying organization too.  I do= n't want to get
>> in to arguments about what's an SDO and what's not.
>>
>> spt
>>
>>> You should consider including: NIST, MITRE, and 3GPP - al= l of
>>> which are well recognized as key standards bodies current= ly
>>> engaged in SACM related work with whom you should be inte= rested now.
>>>
>>> -t
>>>
>>> On 6/24/2013 11:52 AM, Adam Montville wrote:
>>>> There are a variety of other SDOs in which we could b= e interested
>>>> now or in the future.  The short-story list= :
>>>>
>>>> * FIRST (vulnerability scoring)
>>>> * DMTF (already mentioned)
>>>> * TCG (already mentioned)
>>>> * The Open Group (XDAS and others)
>>>> * ISO (i.e. TagVault)
>>>> * W3C (i.e. obvious things like XML DigSig, and poten= tially less
>>>> obvious things like RDF, OWL, SWRL, etc.)
>>>> * OASIS (i.e. security assertions, key management, al= erting)
>>>> * OMG (i.e. Business Process Model Notation and/or Ex= ecution
>>>> Language,
>>>> etc.)
>>>
>>>
>> _______________________________________________
>> sacm mailing list
> _______________________________________________
> sacm mailing list
>
_______________________________________________
sacm mailing list

_______________________________________________
sacm mailing list

...

This message and attachments may contain confidential information.&nbs= p; If it appears that this message was sent to you by mistake, any ret= ention, dissemination, distribution or copying of this message and attachme= nts is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachme= nts.
_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2B5BD7MIVEXAMER1N1corpn_-- From michael.hammer@yaanatech.com Tue Jun 25 08:41:01 2013 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 C5F4221E80A6 for ; Tue, 25 Jun 2013 08:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg92EYqfS9AE for ; Tue, 25 Jun 2013 08:40:57 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id AA11721E809C for ; Tue, 25 Jun 2013 08:40:57 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 25 Jun 2013 08:40:57 -0700 From: Michael Hammer To: "Kent_Landfield@McAfee.com" , "Adam.Montville@cisecurity.org" , "dbharrington@comcast.net" , "turners@ieca.com" , "sacm@ietf.org" Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhu98VDEe21tkiWWwHzJzVnzZlFYzoAgAACzACAABNbgIAAD2sAgABpi4CAAJdyAIAATgGAgAAInACAAAcIAIAAGcMAgAACjQD//48/0A== Date: Tue, 25 Jun 2013 15:40:56 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0BFFF@EX2K10MB1.corp.yaanatech.com> References: <05BCCEB107AF88469B9F99783D47C1D6701AAF@CISEXCHANGE1.msisac.org.local> <3CBA099FBA0AB843895D72474092B8CF2B5BD7@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2B5BD7@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0042_01CE717F.B5D6C6A0" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:41:01 -0000 ------=_NextPart_000_0042_01CE717F.B5D6C6A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0043_01CE717F.B5D6C6A0" ------=_NextPart_001_0043_01CE717F.B5D6C6A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit +1 This just means many groups are interested in the same scope. Mike From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, June 25, 2013 8:24 AM To: Adam.Montville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville Date: Tuesday, June 25, 2013 5:15 PM To: David Harrington , Sean Turner , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David Harrington [dbharrington@comcast.net] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To: tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >> sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF as a >>> "SDO!" >>> http://www.tta.or.kr/English/new/external_relations/gsc17_communiq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be interested now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be interested >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_001_0043_01CE717F.B5D6C6A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

+1  This just means many groups are interested in the same = scope.

 

Mike

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Kent_Landfield@McAfee.com
Sent: Tuesday, June 25, 2013 = 8:24 AM
To: Adam.Montville@cisecurity.org; = dbharrington@comcast.net; turners@ieca.com; = sacm@ietf.org
Subject: Re: [sacm] sacm charter = review

 

Well said Adam. I totally = agree with your comments.

 

= Kent Landfield=

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

 

From: Adam Montville <Adam.Montville@cisecurity.o= rg>
Date: Tuesday, June 25, 2013 5:15 PM
To: = David Harrington <dbharrington@comcast.net>= , Sean Turner <turners@ieca.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: = Re: [sacm] sacm charter review

 

Hi = David,

 

I respectfully = disagree.  

 

While this may be a = commentary on the potential, eventual reach of SACM, our charter's scope = is far reduced from including all of these organizations at the = outset.  In other words, our scope is limited by the language = in the charter, against which this list really has no bearing other than = to satisfy curiosity and, perhaps, lend some vision to the = future.

 

In fact, it might be more = properly construed that this list of organizations is a commentary on = the ubiquitous nature of assessment - it is a capability that = "touches" a lot of different areas, which is precisely why it = warrants its own working group, IMO.

 

Regards,

 

Adam

 

 

 

________________________________________=

From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on = behalf of David Harrington [dbharrington@comcast.net]

Sent: Tuesday, June 25, 2013 6:43 = AM

To: 'Sean Turner'; sacm@ietf.org

Subject: Re: = [sacm] sacm charter review

 

Wow!

I think this is an = excellent commentary on the scope of SACM being way = too

broad, and poorly scoped for engineering = purposes.

 

David = Harrington

+1-603-828-1401

 

-----Original = Message-----

Romascanu, Dan = (Dan)

Sent: Tuesday, June 25, 2013 9:18 = AM

To: Sean Turner

Cc: Moriarty, Kathleen; = Stephen Hanna; Adam Montville; sacm@ietf.org;

Subject: Re: [sacm] sacm charter = review

 

Hi = Sean,

 

A list of organizations = that are involved in the area, as identified in = this

discussion = includes:

 

- = TCG

- DMTF

- = FIRST

- The Open = Group

- ISO/IEC

- = W3C

- OASIS

- = OMG

- NIST

- = MITRE

- 3GPP

 

It's up to the IESG to = decide if we should list these (or some of = them)

explicitly, or we should leave to the WG after its = formation is approved to

initiate communication and = invite participation.

 

Regards,

 

Dan

 

 

 

 

-----Original = Message-----

From: Sean Turner [mailto:turners@ieca.com]<= /span>

Sent: Tuesday, June 25, 2013 3:47 = PM

To: Romascanu, Dan = (Dan)

Cc: tony@yaanatech.com; Adam = Montville; Stephen Hanna; Moriarty,

Kathleen; sacm@ietf.org

Subject: Re: = [sacm] sacm charter review

 

At this point 3 ADs have = asked about what other SDOs are = involved.

I'm not sure if they want names in the charter or = if they're just

interested in = knowing.

 

spt

 

On 6/25/13 4:07 AM, = Romascanu, Dan (Dan) wrote:

> The proposed text in = the charter already says:

> 

>> In accordance = with existing IETF processes, the group = will

>> communicate with = and

> invite participation from other relevant = standards bodies and

> regulatory = organizations, and if necessary reuse existing = liaison

> relationships or request the establishment of = new liaison

relationships.

> 

> 'standard bodies and = regulatory organizations' are neutral = terms

enough IMO, as Sean says we should not enter the = 'what is an SDO

dispute'. We are dealing = not only with standards organizations = and

this is also reflected in the current = text.

> 

> = Regards,

> 

> = Dan

> 

> 

> 

> 

> 

>> -----Original = Message-----

>> Behalf Of Sean = Turner

>> Sent: Tuesday, June 25, 2013 2:06 = AM

>> Cc: Moriarty, Kathleen; Stephen Hanna; = Adam Montville;

>> sacm@ietf.org

>> = Subject: Re: [sacm] sacm charter = review

>> 

>> On 6/24/13 12:47 = PM, Tony Rutkowski wrote:

>>> SDO is an = undesirable legacy term.

>>> Pathetically, = the old SDO club still does not regard the IETF as = a

>>> = "SDO!"

>>> ue

>>> = .j

>>> sp

>>> 

=

>>> Perhaps it = is better to simply use "standards = fora."

>> 

>> I'm not against = just saying organization too.  I don't want to = get

>> in to arguments about what's an SDO and = what's not.

>> 

>> = spt

>> 

>>> You should = consider including: NIST, MITRE, and 3GPP - all = of

>>> which are well recognized as key = standards bodies currently

>>> engaged in = SACM related work with whom you should be interested = now.

>>> 

=

>>> = -t

>>> 

=

>>> On = 6/24/2013 11:52 AM, Adam Montville = wrote:

>>>> There are a variety of other SDOs = in which we could be interested

>>>> now or in = the future.  The short-story = list:

>>>> 

<= div>

>>>> * = FIRST (vulnerability scoring)

>>>> * DMTF = (already mentioned)

>>>> * TCG = (already mentioned)

>>>> * The = Open Group (XDAS and others)

>>>> * ISO = (i.e. TagVault)

>>>> * W3C = (i.e. obvious things like XML DigSig, and potentially = less

>>>> obvious things like RDF, OWL, = SWRL, etc.)

>>>> * OASIS (i.e. security = assertions, key management, alerting)

>>>> * OMG = (i.e. Business Process Model Notation and/or = Execution

>>>> = Language,

>>>> = etc.)

>>> 

=

>>> 

=

>> = _______________________________________________

>> sacm = mailing list

>> sacm@ietf.org

> = _______________________________________________

> sacm = mailing list

=

_______________________________________________

sacm mailing = list

sacm@ietf.org

 

_______________________________________________

sacm mailing = list

sacm@ietf.org

 

...

 

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.

_______________________________________________

sacm mailing = list

------=_NextPart_001_0043_01CE717F.B5D6C6A0-- ------=_NextPart_000_0042_01CE717F.B5D6C6A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow 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+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTE1NDA1NlowIwYJKoZIhvcNAQkEMRYEFALg2u1EhxBJv8KlRJhSuMiL5f80MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAZIVuYac98ua5d9J+IQ2KRaZ9a1pF2FTxEWFt8Z0R eU2swO/IpomNmEYpNYqjZnNot24Q+LObMFMobIdTF41gQNUaabG7IC4l+Rd/c3T27Y44SqVFrIVj 4q4OFPFeKlyFb934qWdqUvv8w7E3eBnq8kcrE/G0eC6jeVt591U5f73j9d0htoa3FDXiFXVZDh8J je0wrHz5q3GE135lJwDIOLmPKheu8xdhwUxYwAc8g76igfLcbT16pl4KLNwDVJNt8egcWzSpzFLj fqw0MAS5sBxj7DcQuNWYETkXMwmlA4boWw7lCQe3KXXSRxefmHe90Qa50b+RmNGSkBeg9MR3twAA AAAAAA== ------=_NextPart_000_0042_01CE717F.B5D6C6A0-- From dromasca@avaya.com Wed Jun 26 01:33:54 2013 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 26F0821F9A2A for ; Wed, 26 Jun 2013 01:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IduUilXn35bD for ; Wed, 26 Jun 2013 01:33:45 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0F21F93E0 for ; Wed, 26 Jun 2013 01:33:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8IANSmylHGmAcF/2dsb2JhbABXA4JFIyExSapulAmBBhZ0giMBAQEBAgEBAQEPGxwlBAwHBAIBCAcGBAMBAQEBChYBBgcnCxQJCAIEARIIEweHWgMJBgELnh+THgiIQBeOEoEHAQUHAhEBCwEBAgcBAgQLgnFhA54HiwGDEYFoQA X-IronPort-AV: E=Sophos;i="4.87,941,1363147200"; d="scan'208,217";a="17775038" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 Jun 2013 04:33:39 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jun 2013 04:31:16 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 04:33:38 -0400 From: "Romascanu, Dan (Dan)" To: Michael Hammer , "Kent_Landfield@McAfee.com" , "Adam.Montville@cisecurity.org" , "dbharrington@comcast.net" , "turners@ieca.com" , "sacm@ietf.org" Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh6y/yJrU4AjEmUc/AYGz5tQplFMPAAgAACywCAABNbgIAAD2sAgAAE9oCAALVK8IAAlL6A///CuBCAAEztAIAAGcIA//+d+ACAAGlCAIAA1WPA Date: Wed, 26 Jun 2013 08:33:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1AE9E5@AZ-FFEXMB04.global.avaya.com> References: <05BCCEB107AF88469B9F99783D47C1D6701AAF@CISEXCHANGE1.msisac.org.local> <3CBA099FBA0AB843895D72474092B8CF2B5BD7@MIVEXAMER1N1.corp.nai.org> <00C069FD01E0324C9FFCADF539701DB3BBC0BFFF@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0BFFF@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1AE9E5AZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:33:55 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1AE9E5AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. The fact that other organizations are interested in the scope of SACM = does not mean that they do the same work, and certainly the future WG must = avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SD= Os which can be used as-is or as a starting point for developing solutions to = the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SD= Os which can be used as-is or as a starting point for developing solutions to = the SACM requirements. The working group may decide to refer or document these = in An Informational RFC, but this is not a mandatory deliverable. The working = group will not duplicate work already done or in progress in other places. Regards, Dan From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mic= hael Hammer Sent: Tuesday, June 25, 2013 6:41 PM To: Kent_Landfield@McAfee.com; Adam.Montville@cisecurity.org; dbharrington@= comcast.net; turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Tuesday, June 25, 2013 8:24 AM To: Adam.Montville@cisecurity.org; db= harrington@comcast.net; turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Adam Montville > Date: Tuesday, June 25, 2013 5:15 PM To: David Harrington >, Sean Turner >, "sacm@ietf.= org" > Subject: Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, ou= r charter's scope is far reduced from including all of these organizations = at the outset. In other words, our scope is limited by the language in the= charter, against which this list really has no bearing other than to satis= fy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organization= s is a commentary on the ubiquitous nature of assessment - it is a capabili= ty that "touches" a lot of different areas, which is precisely why it warra= nts its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] on behalf of David Harrington [dbharri= ngton@comcast.net] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in thi= s discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com; Adam Montville; Stephen = Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-b= ounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To: tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >> sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF as a >>> "SDO!" >>> http://www.tta.or.kr/English/new/external_relations/gsc17_communiq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be interested now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be interested >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissemi= nation, distribution or copying of this message and attachments is strictly= prohibited. Please notify the sender immediately and permanently delete t= he message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_9904FB1B0159DA42B0B887B7FA8119CA1AE9E5AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes. The fact that other = organizations are interested in the scope of SACM does not mean that they d= o the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: <= /span>

 <= /p>

OLD:

 <= /p>

The working group will create= an overview of related standards work

Internet-Draft which will doc= ument existing work in the IETF or in other SDOs

which can be used as-is or as= a starting point for developing solutions to the

SACM requirements. The workin= g group may decide to make of this document an

Informational RFC, but this i= s not a mandatory deliverable.

 

 <= /p>

 <= /p>

NEW:

 <= /p>

 <= /p>

The working group will create= an overview of related standards work

Internet-Draft which will doc= ument existing work in the IETF or in other SDOs

which can be used as-is or as= a starting point for developing solutions to the

SACM requirements. The workin= g group may decide to refer or document these in

An Informational RFC, but thi= s is not a mandatory deliverable. The working group

will not duplicate work alrea= dy done or in progress in other places.

 

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Michael Hammer
Sent: Tuesday, June 25, 2013 6:41 PM
To: Kent_Landfield@McAfee.com; Adam.Montville@cisecurity.org; dbharr= ington@comcast.net; turners@ieca.com; sacm@ietf.org
Subject: Re: [sacm] sacm charter review

 

+1  This just me= ans many groups are interested in the same scope.

 <= /p>

Mike

 <= /p>

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Tuesday, June 25, 2013 8:24 AM
To: Adam.Montville@= cisecurity.org; dbharrington@comcast.net; <= a href=3D"mailto:turners@ieca.com"> turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review

 

Well said Adam. I totall= y agree with your comments.

 =

Kent Landfield

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

 =

From: Adam Montville <Adam.Montville@cisecurity.org>
Date: Tuesday, June 25, 2013 5:15 PM
To: David Harrington <dbharrington@comcast.net>, Sean Turner <turners@ieca.com>, "sacm@ietf.org" <sacm@ietf.or= g>
Subject: Re: [sacm] sacm charter review

 =

Hi David,

 =

I respectfully disagree.=   

 =

While this may be a comm= entary on the potential, eventual reach of SACM, our charter's scope is far= reduced from including all of these organizations at the outset. &nbs= p;In other words, our scope is limited by the language in the charter, against which this list really has no bearing oth= er than to satisfy curiosity and, perhaps, lend some vision to the future.<= o:p>

 =

In fact, it might be mor= e properly construed that this list of organizations is a commentary on the= ubiquitous nature of assessment - it is a capability that "touches&qu= ot; a lot of different areas, which is precisely why it warrants its own working group, IMO.

 =

Regards,

 =

Adam

 =

 =

 =

________________________= ________________

Sent: Tuesday, June 25, = 2013 6:43 AM

To: 'Sean Turner'; sacm@ietf.org

Subject: Re: [sacm] sacm= charter review

 =

Wow!

I think this is an excel= lent commentary on the scope of SACM being way too

broad, and poorly scoped= for engineering purposes.

 =

David Harrington

+1-603-828-1401=

 =

-----Original Message---= --

Romascanu, Dan (Dan)

Sent: Tuesday, June 25, = 2013 9:18 AM

To: Sean Turner

Cc: Moriarty, Kathleen; = Stephen Hanna; Adam Montville; sacm@ietf.org;

Subject: Re: [sacm] sacm= charter review

 =

Hi Sean,

 =

A list of organizations = that are involved in the area, as identified in this

discussion includes:

 =

- TCG<= /p>

- DMTF=

- FIRST

- The Open Group

- ISO/IEC

- W3C<= /p>

- OASIS

- OMG<= /p>

- NIST=

- MITRE

- 3GPP=

 =

It's up to the IESG to d= ecide if we should list these (or some of them)

explicitly, or we should= leave to the WG after its formation is approved to

initiate communication a= nd invite participation.

 =

Regards,

 =

Dan

 =

 =

 =

 =

-----Original Message---= --

From: Sean Turner [mailto:turners@ieca.com]

Sent: Tuesday, June 25, = 2013 3:47 PM

To: Romascanu, Dan (Dan)=

Cc: tony@yaanatech.com; Adam Montville; Stephen Hanna; Moriarty,=

Kathleen; sacm@ietf.org

Subject: Re: [sacm] sacm= charter review

 =

At this point 3 ADs have= asked about what other SDOs are involved.

I'm not sure if they wan= t names in the charter or if they're just

interested in knowing.

 =

spt

 =

On 6/25/13 4:07 AM, Roma= scanu, Dan (Dan) wrote:

> The proposed text i= n the charter already says:

> 

>> In accordance w= ith existing IETF processes, the group will

>> communicate wit= h and

> invite participatio= n from other relevant standards bodies and

> regulatory organiza= tions, and if necessary reuse existing liaison

> relationships or re= quest the establishment of new liaison

relationships.

> 

> 'standard bodies an= d regulatory organizations' are neutral terms

enough IMO, as Sean says= we should not enter the 'what is an SDO

dispute'. We are dealing= not only with standards organizations and

this is also reflected i= n the current text.

> 

> Regards,=

> 

> Dan

> 

> 

> 

> 

> 

>> -----Original M= essage-----

>> Behalf Of Sean = Turner

>> Sent: Tuesday, = June 25, 2013 2:06 AM

>> Cc: Moriarty, K= athleen; Stephen Hanna; Adam Montville;

>> Subject: Re: [s= acm] sacm charter review

>> 

>> On 6/24/13 12:4= 7 PM, Tony Rutkowski wrote:

>>> SDO is an u= ndesirable legacy term.

>>> Patheticall= y, the old SDO club still does not regard the IETF as a

>>> "SDO!&= quot;

>>> ue

>>> .j

>>> sp

>>> <= /o:p>

>>> Perhaps it = is better to simply use "standards fora."

>> 

>> I'm not against= just saying organization too.  I don't want to get

>> in to arguments= about what's an SDO and what's not.

>> 

>> spt<= /span>

>> 

>>> You should = consider including: NIST, MITRE, and 3GPP - all of

>>> which are w= ell recognized as key standards bodies currently

>>> engaged in = SACM related work with whom you should be interested now.=

>>> <= /o:p>

>>> -t

>>> <= /o:p>

>>> On 6/24/201= 3 11:52 AM, Adam Montville wrote:

>>>> There a= re a variety of other SDOs in which we could be interested

>>>> now or = in the future.  The short-story list:

>>>>&nb= sp;

>>>> * FIRST= (vulnerability scoring)

>>>> * DMTF = (already mentioned)

>>>> * TCG (= already mentioned)

>>>> * The O= pen Group (XDAS and others)

>>>> * ISO (= i.e. TagVault)

>>>> * W3C (= i.e. obvious things like XML DigSig, and potentially less=

>>>> obvious= things like RDF, OWL, SWRL, etc.)

>>>> * OASIS= (i.e. security assertions, key management, alerting)

>>>> * OMG (= i.e. Business Process Model Notation and/or Execution

>>>> Languag= e,

>>>> etc.)

>>> <= /o:p>

>>> <= /o:p>

>> _______________= ________________________________

>> sacm mailing li= st

> ___________________= ____________________________

> sacm mailing list

> 

________________________= _______________________

sacm mailing list

 =

________________________= _______________________

sacm mailing list

 =

...

 =

This message and attachm= ents may contain confidential information.  If it appears that th= is message was sent to you by mistake, any retention, dissemination, distri= bution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately an= d permanently delete the message and any attachments.

________________________= _______________________

sacm mailing list

 =

--_000_9904FB1B0159DA42B0B887B7FA8119CA1AE9E5AZFFEXMB04globala_-- From turners@ieca.com Wed Jun 26 04:56:48 2013 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 A94D911E80DC for ; Wed, 26 Jun 2013 04:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 7oZaZTBjQLlu for ; Wed, 26 Jun 2013 04:56:43 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.56.144.13]) by ietfa.amsl.com (Postfix) with ESMTP id C7F1D21F9057 for ; Wed, 26 Jun 2013 04:56:43 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 92460BA5392B0; Wed, 26 Jun 2013 06:56:42 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 8619BBA53928C for ; Wed, 26 Jun 2013 06:56:42 -0500 (CDT) Received: from [173.73.135.101] (port=62678 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UroL4-000234-4q for sacm@ietf.org; Wed, 26 Jun 2013 06:56:42 -0500 Message-ID: <51CAD6F9.5040503@ieca.com> Date: Wed, 26 Jun 2013 07:56:41 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "sacm@ietf.org" References: <05BCCEB107AF88469B9F99783D47C1D6701AAF@CISEXCHANGE1.msisac.org.local> <3CBA099FBA0AB843895D72474092B8CF2B5BD7@MIVEXAMER1N1.corp.nai.org> <00C069FD01E0324C9FFCADF539701DB3BBC0BFFF@EX2K10MB1.corp.yaanatech.com> <9904FB1B0159DA42B0B887B7FA8119CA1AE9E5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1AE9E5@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:62678 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 11:56:48 -0000 It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: > Yes. The fact that other organizations are interested in the scope of > SACM does not mean that they do the same work, and certainly the future > WG must avoid duplication. Maybe we should make this explicit. For example: > > OLD: > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in other > SDOs > > which can be used as-is or as a starting point for developing solutions > to the > > SACM requirements. The working group may decide to make of this document an > > Informational RFC, but this is not a mandatory deliverable. > > NEW: > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or in other > SDOs > > which can be used as-is or as a starting point for developing solutions > to the > > SACM requirements. The working group may decide to refer or document > these in > > An Informational RFC, but this is not a mandatory deliverable. The > working group > > will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. > Regards, > > Dan > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Michael Hammer > *Sent:* Tuesday, June 25, 2013 6:41 PM > *To:* Kent_Landfield@McAfee.com; Adam.Montville@cisecurity.org; > dbharrington@comcast.net; turners@ieca.com; sacm@ietf.org > *Subject:* Re: [sacm] sacm charter review > > +1 This just means many groups are interested in the same scope. > > Mike > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com > > *Sent:* Tuesday, June 25, 2013 8:24 AM > *To:* Adam.Montville@cisecurity.org > ; dbharrington@comcast.net > ; turners@ieca.com > ; sacm@ietf.org > *Subject:* Re: [sacm] sacm charter review > > Well said Adam. I totally agree with your comments. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *Adam Montville > > *Date: *Tuesday, June 25, 2013 5:15 PM > *To: *David Harrington >, Sean Turner >, "sacm@ietf.org " > > > *Subject: *Re: [sacm] sacm charter review > > Hi David, > > I respectfully disagree. > > While this may be a commentary on the potential, eventual reach of > SACM, our charter's scope is far reduced from including all of these > organizations at the outset. In other words, our scope is limited > by the language in the charter, against which this list really has > no bearing other than to satisfy curiosity and, perhaps, lend some > vision to the future. > > In fact, it might be more properly construed that this list of > organizations is a commentary on the ubiquitous nature of assessment > - it is a capability that "touches" a lot of different areas, which > is precisely why it warrants its own working group, IMO. > > Regards, > > Adam > > ________________________________________ > > From: sacm-bounces@ietf.org > [sacm-bounces@ietf.org ] on behalf of > David Harrington [dbharrington@comcast.net > ] > > Sent: Tuesday, June 25, 2013 6:43 AM > > To: 'Sean Turner'; sacm@ietf.org > > Subject: Re: [sacm] sacm charter review > > Wow! > > I think this is an excellent commentary on the scope of SACM being > way too > > broad, and poorly scoped for engineering purposes. > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > > -----Original Message----- > > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Romascanu, Dan (Dan) > > Sent: Tuesday, June 25, 2013 9:18 AM > > To: Sean Turner > > Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org > ; > > tony@yaanatech.com > > Subject: Re: [sacm] sacm charter review > > Hi Sean, > > A list of organizations that are involved in the area, as identified > in this > > discussion includes: > > - TCG > > - DMTF > > - FIRST > > - The Open Group > > - ISO/IEC > > - W3C > > - OASIS > > - OMG > > - NIST > > - MITRE > > - 3GPP > > It's up to the IESG to decide if we should list these (or some of them) > > explicitly, or we should leave to the WG after its formation is > approved to > > initiate communication and invite participation. > > Regards, > > Dan > > -----Original Message----- > > From: Sean Turner [mailto:turners@ieca.com] > > Sent: Tuesday, June 25, 2013 3:47 PM > > To: Romascanu, Dan (Dan) > > Cc: tony@yaanatech.com ; Adam > Montville; Stephen Hanna; Moriarty, > > Kathleen; sacm@ietf.org > > Subject: Re: [sacm] sacm charter review > > At this point 3 ADs have asked about what other SDOs are involved. > > I'm not sure if they want names in the charter or if they're just > > interested in knowing. > > spt > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > > The proposed text in the charter already says: > > > > > >> In accordance with existing IETF processes, the group will > > >> communicate with and > > > invite participation from other relevant standards bodies and > > > regulatory organizations, and if necessary reuse existing liaison > > > relationships or request the establishment of new liaison > > relationships. > > > > > > 'standard bodies and regulatory organizations' are neutral terms > > enough IMO, as Sean says we should not enter the 'what is an SDO > > dispute'. We are dealing not only with standards organizations and > > this is also reflected in the current text. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From:sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On > > >> Behalf Of Sean Turner > > >> Sent: Tuesday, June 25, 2013 2:06 AM > > >> To:tony@yaanatech.com > > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; > > >>sacm@ietf.org > > >> Subject: Re: [sacm] sacm charter review > > >> > > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > >>> SDO is an undesirable legacy term. > > >>> Pathetically, the old SDO club still does not regard the IETF as a > > >>> "SDO!" > > >>>http://www.tta.or.kr/English/new/external_relations/gsc17_communiq > > >>> ue > > >>> .j > > >>> sp > > >>> > > >>> Perhaps it is better to simply use "standards fora." > > >> > > >> I'm not against just saying organization too. I don't want to get > > >> in to arguments about what's an SDO and what's not. > > >> > > >> spt > > >> > > >>> You should consider including: NIST, MITRE, and 3GPP - all of > > >>> which are well recognized as key standards bodies currently > > >>> engaged in SACM related work with whom you should be interested now. > > >>> > > >>> -t > > >>> > > >>> On 6/24/2013 11:52 AM, Adam Montville wrote: > > >>>> There are a variety of other SDOs in which we could be interested > > >>>> now or in the future. The short-story list: > > >>>> > > >>>> * FIRST (vulnerability scoring) > > >>>> * DMTF (already mentioned) > > >>>> * TCG (already mentioned) > > >>>> * The Open Group (XDAS and others) > > >>>> * ISO (i.e. TagVault) > > >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less > > >>>> obvious things like RDF, OWL, SWRL, etc.) > > >>>> * OASIS (i.e. security assertions, key management, alerting) > > >>>> * OMG (i.e. Business Process Model Notation and/or Execution > > >>>> Language, > > >>>> etc.) > > >>> > > >>> > > >> _______________________________________________ > > >> 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 > > ... > > 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. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > From Kent_Landfield@mcafee.com Wed Jun 26 05:10:54 2013 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 1524321F9A94 for ; Wed, 26 Jun 2013 05:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bb-84Xb3+zA for ; Wed, 26 Jun 2013 05:10:49 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE8921F9A8D for ; Wed, 26 Jun 2013 05:10:49 -0700 (PDT) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 6c5d_1bee_4d577566_8ad5_40a1_a5f6_5522e22dfb8d; Wed, 26 Jun 2013 07:10:48 -0500 Received: from MIVEXAPP1N3.corp.nai.org (10.48.48.63) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 26 Jun 2013 08:10:38 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAPP1N3.corp.nai.org ([169.254.3.112]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 08:10:38 -0400 From: To: , Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhuvQoRthgPdUqZE3J5Z9Ln/5lFMPAAgAACywCAABNbgIAAD2wAgABpioCAAJdzAIAATgCAgAAInQCAAAcIAIAAGcIAgAAkFID//+MmAIABGvGAgAA4vYCAACVpgA== Date: Wed, 26 Jun 2013 12:10:37 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2B6BC0@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <51CAD6F9.5040503@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.48.48.243] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2B6BC0MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:10:54 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2B6BC0MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From my perspective the initial organizations we will be dealing with are - ISO/IEC - NIST - MITRE Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 1:56 PM To: "sacm@ietf.org" > Subject: Re: [sacm] sacm charter review It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: Yes. The fact that other organizations are interested in the scope of SACM does not mean that they do the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to refer or document these in An Informational RFC, but this is not a mandatory deliverable. The working group will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. Regards, Dan *From:*sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, June 25, 2013 6:41 PM *To:* Kent_Landfield@McAfee.com; Adam.Mon= tville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com= ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com *Sent:* Tuesday, June 25, 2013 8:24 AM *To:* Adam.Montville@cisecurity.org ; dbharrington@comcast.net ; turners@ieca.com ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *Adam Montville > *Date: *Tuesday, June 25, 2013 5:15 PM *To: *David Harrington >, Sean Turner >, "sacm@ietf.org " > *Subject: *Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org ] on behalf of David Harrington [dbharrington@comcast.net ] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org ; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them= ) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com ; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaiso= n > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From:sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To:tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >>sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF = as a >>> "SDO!" >>>http://www.tta.or.kr/English/new/external_relations/gsc17_commu= niq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to = get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be intereste= d now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be intere= sted >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially l= ess >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ 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_3CBA099FBA0AB843895D72474092B8CF2B6BC0MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: <9EF7FA3A3ECB4346B2744267C60C76B2@McAfee.com> Content-Transfer-Encoding: quoted-printable

From: Sean Turner <turners@ieca.com>
Date: Wednesday, June 26, 2013 1:56= PM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: Re: [sacm] sacm charter re= view

It looks like Joel wants to know now some of the organizations (i.e., =
there's block on the charter).  Can we whittle this list dow= n to just
orgs we're going to be dealing with at the initial stages?  = For asset
identification it's possibly going to be ISO+NIST+?, for endpo= int
elements to assess it's ?, for comparison it's ?, for interacting with=
repositories it's NEA.

More inline.

On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote:
Yes. The fact that other organizations are interested in the scope of<= /div>
SACM does not mean that they do the same work, and certainly the futur= e
WG must avoid duplication. Maybe we should make this explicit. For exa= mple:

OLD:

The working group will create an overview of related standards work

Internet-Draft which will document existing work in the IETF or in oth= er
SDOs

which can be used as-is or as a starting point for developing solution= s
to the

SACM requirements. The working group may decide to make of this docume= nt an

Informational RFC, but this is not a mandatory deliverable.

NEW:

The working group will create an overview of related standards work

Internet-Draft which will document existing work in the IETF or in oth= er
SDOs

which can be used as-is or as a starting point for developing solution= s
to the

SACM requirements. The working group may decide to refer or document
these in

An Informational RFC, but this is not a mandatory deliverable. The
working group

will not duplicate work already done or in progress in other places.

We were on the same wavelength.  I'm not sure we need to rep= eated the we
won't duplicate work because there's already a blurb about reuse. = ; What
I proposed to Barry/Joel/Spencer:

OLD:

The working group will create an overview of related standards work
Internet-Draft which will document existing work in the IETF or in oth= er
SDOs which can be used as-is or as a starting point for developing
solutions to the SACM requirements.

NEW:

The working group will create an Internet-Draft documenting the existi= ng
work in the IETF and in other organizations that might
be used as-is or as a starting point for developing solutions to
the SACM requirements.

OLD:

In accordance with existing IETF processes, the group will communicate=
with and invite participation from other relevant standards bodies and=
regulatory organizations, and if necessary reuse existing liaison
relationships or request the establishment of new liaison relationship= s.

NEW:

In accordance with existing IETF processes, the working group will
communicate with and invite participation from other relevant groups a= nd
regulatory organizations, and if necessary reuse existing liaison
relationships or request the establishment of new liaison relationship= s.


Regards,

Dan

Of *Michael Hammer
*Sent:* Tuesday, June 25, 2013 6:41 PM
dbharrington@comcast.net; turners@ieca.com; sacm@ietf.org
*Subject:* Re: [sacm] sacm charter review

+1  This just means many groups are interested in the sa= me scope.

Mike

*Sent:* Tuesday, June 25, 2013 8:24 AM
<mailto:Adam.Montv= ille@cisecurity.org>; dbharrington@comcast.net
*Subject:* Re: [sacm] sacm charter review

Well said Adam. I totally agree with your comments.

*Kent Landfield*

*McAfee | An Intel Company*
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
*Web: *www.mcafee.com <http://ww= w.mcafee.com/>

*From: *Adam Montville <Adam.Montville@cisecurity.org
*Date: *Tuesday, June 25, 2013 5:15 PM
*To: *David Harrington <dbharrington@comcast.net
*Subject: *Re: [sacm] sacm charter review

     Hi David,

     I respectfully disagree.

     While this may be a commentary on the potenti= al, eventual reach of
     SACM, our charter's scope is far reduced from= including all of these
     organizations at the outset.  In ot= her words, our scope is limited
     by the language in the charter, against which= this list really has
     no bearing other than to satisfy curiosity an= d, perhaps, lend some
     vision to the future.

     In fact, it might be more properly construed = that this list of
     organizations is a commentary on the ubiquito= us nature of assessment
     - it is a capability that "touches"= a lot of different areas, which
     is precisely why it warrants its own working = group, IMO.

     Regards,

     Adam

     ________________________________________

     David Harrington [dbharrington@comcast.net

     Sent: Tuesday, June 25, 2013 6:43 AM

     To: 'Sean Turner'; sacm@ietf.org <mailto:sacm@i= etf.org>

     Subject: Re: [sacm] sacm charter review

     Wow!

     I think this is an excellent commentary on th= e scope of SACM being
     way too

     broad, and poorly scoped for engineering purp= oses.

     David Harrington


     +1-603-828-1401

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

     [mai= lto:sacm-bounces@ietf.org] On Behalf Of

     Romascanu, Dan (Dan)

     Sent: Tuesday, June 25, 2013 9:18 AM

     To: Sean Turner

     Cc: Moriarty, Kathleen; Stephen Hanna; Adam M= ontville; sacm@ietf.org


     Subject: Re: [sacm] sacm charter review

     Hi Sean,

     A list of organizations that are involved in = the area, as identified
     in this

     discussion includes:

     - TCG

     - DMTF

     - FIRST

     - The Open Group

     - ISO/IEC

     - W3C

     - OASIS

     - OMG

     - NIST

     - MITRE

     - 3GPP

     It's up to the IESG to decide if we should li= st these (or some of them)

     explicitly, or we should leave to the WG afte= r its formation is
     approved to

     initiate communication and invite participati= on.

     Regards,

     Dan

         -----Original Message= -----

         From: Sean Turner [mailto:turners@ieca.com]

         Sent: Tuesday, June 2= 5, 2013 3:47 PM

         To: Romascanu, Dan (D= an)

         Cc: tony@yaanatech.com <mailto:tony@yaanatech.com>; Adam
         Montville; Stephen Ha= nna; Moriarty,

         Kathleen; sacm@ietf.org <mailto:sacm@ietf.org>

         Subject: Re: [sacm] s= acm charter review

         At this point 3 ADs h= ave asked about what other SDOs are involved.

         I'm not sure if they = want names in the charter or if they're just

         interested in knowing= .

         spt

         On 6/25/13 4:07 AM, R= omascanu, Dan (Dan) wrote:

         > The proposed tex= t in the charter already says:

         >

         >> In accordanc= e with existing IETF processes, the group will

         >> communicate = with and

         > invite participa= tion from other relevant standards bodies and

         > regulatory organ= izations, and if necessary reuse existing liaison

         > relationships or= request the establishment of new liaison

         relationships.

         >

         > 'standard bodies= and regulatory organizations' are neutral terms

         enough IMO, as Sean s= ays we should not enter the 'what is an SDO

         dispute'. We are deal= ing not only with standards organizations and

         this is also reflecte= d in the current text.

         >

         > Regards,

         >

         > Dan

         >

         >

         >

         >

         >

         >> -----Origina= l Message-----

         [mailto:sacm-bounces@ietf.org] On

         >> Behalf Of Se= an Turner

         >> Sent: Tuesda= y, June 25, 2013 2:06 AM


         >> Cc: Moriarty= , Kathleen; Stephen Hanna; Adam Montville;


         >> Subject: Re:= [sacm] sacm charter review

         >>

         >> On 6/24/13 1= 2:47 PM, Tony Rutkowski wrote:

         >>> SDO is a= n undesirable legacy term.

         >>> Pathetic= ally, the old SDO club still does not regard the IETF as a

         >>> "SD= O!"


         >>> ue

         >>> .j

         >>> sp

         >>>

         >>> Perhaps = it is better to simply use "standards fora."

         >>

         >> I'm not agai= nst just saying organization too.  I don't want to get

         >> in to argume= nts about what's an SDO and what's not.

         >>

         >> spt

         >>

         >>> You shou= ld consider including: NIST, MITRE, and 3GPP - all of

         >>> which ar= e well recognized as key standards bodies currently

         >>> engaged = in SACM related work with whom you should be interested now.

         >>>

         >>> -t

         >>>

         >>> On 6/24/= 2013 11:52 AM, Adam Montville wrote:

         >>>> Ther= e are a variety of other SDOs in which we could be interested

         >>>> now = or in the future.  The short-story list:

         >>>>

         >>>> * FI= RST (vulnerability scoring)

         >>>> * DM= TF (already mentioned)

         >>>> * TC= G (already mentioned)

         >>>> * Th= e Open Group (XDAS and others)

         >>>> * IS= O (i.e. TagVault)

         >>>> * W3= C (i.e. obvious things like XML DigSig, and potentially less

         >>>> obvi= ous things like RDF, OWL, SWRL, etc.)

         >>>> * OA= SIS (i.e. security assertions, key management, alerting)

         >>>> * OM= G (i.e. Business Process Model Notation and/or Execution

         >>>> Lang= uage,

         >>>> etc.= )

         >>>

         >>>

         >> ____________= ___________________________________

         >> sacm mailing= list



         > ________________= _______________________________

         > sacm mailing lis= t



         >

     _____________________________________________= __

     sacm mailing list

     sacm@ietf.or= g <mailto:sacm@ietf.org>


     _____________________________________________= __

     sacm mailing list

     sacm@ietf.or= g <mailto:sacm@ietf.org>


     ...

     This message and attachments may contain conf= idential
     information.  If it appears that th= is message was sent to you by
     mistake, any retention, dissemination, distri= bution or copying of
     this message and attachments is strictly proh= ibited.  Please notify
     the sender immediately and permanently delete= the message and any
     attachments.

     _____________________________________________= __

     sacm mailing list

_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2B6BC0MIVEXAMER1N1corpn_-- From Kent_Landfield@mcafee.com Wed Jun 26 05:19:30 2013 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 190B221E8088 for ; Wed, 26 Jun 2013 05:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BanLwT9NjGim for ; Wed, 26 Jun 2013 05:19:25 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 69DAA21E808C for ; Wed, 26 Jun 2013 05:19:25 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 6c57_16f1_1d9b0390_8266_4289_8da7_fc4dd1eb5c5a; Wed, 26 Jun 2013 07:19:17 -0500 Received: from MIVEXENGN3.corp.nai.org (10.48.48.53) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 26 Jun 2013 08:18:59 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXENGN3.corp.nai.org ([169.254.3.84]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 08:18:59 -0400 From: To: , , Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhuvQoRthgPdUqZE3J5Z9Ln/5lFMPAAgAACywCAABNbgIAAD2wAgABpioCAAJdzAIAATgCAgAAInQCAAAcIAIAAGcIAgAAkFID//+MmAIABGvGAgAA4vYCAACVpgIAAAlSA Date: Wed, 26 Jun 2013 12:18:58 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2B6BE2@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2B6BC0@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.48.48.243] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2B6BE2MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:19:30 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2B6BE2MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It should also be noted that NIST and MITRE have been participating in the = SACM side meetings and BoFs and have expressed interest in participating in= SACM once the working group is formed. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kent Landfield > Date: Wednesday, June 26, 2013 2:10 PM To: Sean Turner >, "sacm@ietf.org= " > Subject: Re: [sacm] sacm charter review >From my perspective the initial organizations we will be dealing with are - ISO/IEC - NIST - MITRE Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 1:56 PM To: "sacm@ietf.org" > Subject: Re: [sacm] sacm charter review It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: Yes. The fact that other organizations are interested in the scope of SACM does not mean that they do the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to refer or document these in An Informational RFC, but this is not a mandatory deliverable. The working group will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. Regards, Dan *From:*sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, June 25, 2013 6:41 PM *To:* Kent_Landfield@McAfee.com; Adam.Mon= tville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com= ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com *Sent:* Tuesday, June 25, 2013 8:24 AM *To:* Adam.Montville@cisecurity.org ; dbharrington@comcast.net ; turners@ieca.com ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *Adam Montville > *Date: *Tuesday, June 25, 2013 5:15 PM *To: *David Harrington >, Sean Turner >, "sacm@ietf.org " > *Subject: *Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org ] on behalf of David Harrington [dbharrington@comcast.net ] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org ; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them= ) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com ; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaiso= n > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From:sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To:tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >>sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF = as a >>> "SDO!" >>>http://www.tta.or.kr/English/new/external_relations/gsc17_commu= niq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to = get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be intereste= d now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be intere= sted >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially l= ess >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ 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_3CBA099FBA0AB843895D72474092B8CF2B6BE2MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
It should also be noted that NIST and MITRE have been participating in= the SACM side meetings and BoFs and have expressed interest in participati= ng in SACM once the working group is formed.

Kent Landfield

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

From: <Landfield>, Kent Landf= ield <Kent_Landfield@McAfee= .com>
Date: Wednesday, June 26, 2013 2:10= PM
To: Sean Turner <turners@ieca.com>, "sacm@ietf.org" <sac= m@ietf.org>
Subject: Re: [sacm] sacm charter re= view

From my perspective the initial organizations we will be dealing with = are

     - ISO/IEC
     - NIST
     - MITRE

Kent Landfield

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

From: Sean Turner <turners@ieca.com>
Date: Wednesday, June 26, 2013 1:56= PM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: Re: [sacm] sacm charter re= view

It looks like Joel wants to know now some of the organizations (i.e., =
there's block on the charter).  Can we whittle this list dow= n to just
orgs we're going to be dealing with at the initial stages?  = For asset
identification it's possibly going to be ISO+NIST+?, for endpo= int
elements to assess it's ?, for comparison it's ?, for interacting with=
repositories it's NEA.

More inline.

On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote:
Yes. The fact that other organizations are interested in the scope of<= /div>
SACM does not mean that they do the same work, and certainly the futur= e
WG must avoid duplication. Maybe we should make this explicit. For exa= mple:

OLD:

The working group will create an overview of related standards work

Internet-Draft which will document existing work in the IETF or in oth= er
SDOs

which can be used as-is or as a starting point for developing solution= s
to the

SACM requirements. The working group may decide to make of this docume= nt an

Informational RFC, but this is not a mandatory deliverable.

NEW:

The working group will create an overview of related standards work

Internet-Draft which will document existing work in the IETF or in oth= er
SDOs

which can be used as-is or as a starting point for developing solution= s
to the

SACM requirements. The working group may decide to refer or document
these in

An Informational RFC, but this is not a mandatory deliverable. The
working group

will not duplicate work already done or in progress in other places.

We were on the same wavelength.  I'm not sure we need to rep= eated the we
won't duplicate work because there's already a blurb about reuse. = ; What
I proposed to Barry/Joel/Spencer:

OLD:

The working group will create an overview of related standards work
Internet-Draft which will document existing work in the IETF or in oth= er
SDOs which can be used as-is or as a starting point for developing
solutions to the SACM requirements.

NEW:

The working group will create an Internet-Draft documenting the existi= ng
work in the IETF and in other organizations that might
be used as-is or as a starting point for developing solutions to
the SACM requirements.

OLD:

In accordance with existing IETF processes, the group will communicate=
with and invite participation from other relevant standards bodies and=
regulatory organizations, and if necessary reuse existing liaison
relationships or request the establishment of new liaison relationship= s.

NEW:

In accordance with existing IETF processes, the working group will
communicate with and invite participation from other relevant groups a= nd
regulatory organizations, and if necessary reuse existing liaison
relationships or request the establishment of new liaison relationship= s.


Regards,

Dan

Of *Michael Hammer
*Sent:* Tuesday, June 25, 2013 6:41 PM
dbharrington@comcast.net; turners@ieca.com; sacm@ietf.org
*Subject:* Re: [sacm] sacm charter review

+1  This just means many groups are interested in the sa= me scope.

Mike

*Sent:* Tuesday, June 25, 2013 8:24 AM
<mailto:Adam.Montv= ille@cisecurity.org>; dbharrington@comcast.net
*Subject:* Re: [sacm] sacm charter review

Well said Adam. I totally agree with your comments.

*Kent Landfield*

*McAfee | An Intel Company*
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
*Web: *www.mcafee.com <http://ww= w.mcafee.com/>

*From: *Adam Montville <Adam.Montville@cisecurity.org
*Date: *Tuesday, June 25, 2013 5:15 PM
*To: *David Harrington <dbharrington@comcast.net
*Subject: *Re: [sacm] sacm charter review

     Hi David,

     I respectfully disagree.

     While this may be a commentary on the potenti= al, eventual reach of
     SACM, our charter's scope is far reduced from= including all of these
     organizations at the outset.  In ot= her words, our scope is limited
     by the language in the charter, against which= this list really has
     no bearing other than to satisfy curiosity an= d, perhaps, lend some
     vision to the future.

     In fact, it might be more properly construed = that this list of
     organizations is a commentary on the ubiquito= us nature of assessment
     - it is a capability that "touches"= a lot of different areas, which
     is precisely why it warrants its own working = group, IMO.

     Regards,

     Adam

     ________________________________________

     David Harrington [dbharrington@comcast.net

     Sent: Tuesday, June 25, 2013 6:43 AM

     To: 'Sean Turner'; sacm@ietf.org <mailto:sacm@i= etf.org>

     Subject: Re: [sacm] sacm charter review

     Wow!

     I think this is an excellent commentary on th= e scope of SACM being
     way too

     broad, and poorly scoped for engineering purp= oses.

     David Harrington


     +1-603-828-1401

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

     [mai= lto:sacm-bounces@ietf.org] On Behalf Of

     Romascanu, Dan (Dan)

     Sent: Tuesday, June 25, 2013 9:18 AM

     To: Sean Turner

     Cc: Moriarty, Kathleen; Stephen Hanna; Adam M= ontville; sacm@ietf.org


     Subject: Re: [sacm] sacm charter review

     Hi Sean,

     A list of organizations that are involved in = the area, as identified
     in this

     discussion includes:

     - TCG

     - DMTF

     - FIRST

     - The Open Group

     - ISO/IEC

     - W3C

     - OASIS

     - OMG

     - NIST

     - MITRE

     - 3GPP

     It's up to the IESG to decide if we should li= st these (or some of them)

     explicitly, or we should leave to the WG afte= r its formation is
     approved to

     initiate communication and invite participati= on.

     Regards,

     Dan

         -----Original Message= -----

         From: Sean Turner [mailto:turners@ieca.com]

         Sent: Tuesday, June 2= 5, 2013 3:47 PM

         To: Romascanu, Dan (D= an)

         Cc: tony@yaanatech.com <mailto:tony@yaanatech.com>; Adam
         Montville; Stephen Ha= nna; Moriarty,

         Kathleen; sacm@ietf.org <mailto:sacm@ietf.org>

         Subject: Re: [sacm] s= acm charter review

         At this point 3 ADs h= ave asked about what other SDOs are involved.

         I'm not sure if they = want names in the charter or if they're just

         interested in knowing= .

         spt

         On 6/25/13 4:07 AM, R= omascanu, Dan (Dan) wrote:

         > The proposed tex= t in the charter already says:

         >

         >> In accordanc= e with existing IETF processes, the group will

         >> communicate = with and

         > invite participa= tion from other relevant standards bodies and

         > regulatory organ= izations, and if necessary reuse existing liaison

         > relationships or= request the establishment of new liaison

         relationships.

         >

         > 'standard bodies= and regulatory organizations' are neutral terms

         enough IMO, as Sean s= ays we should not enter the 'what is an SDO

         dispute'. We are deal= ing not only with standards organizations and

         this is also reflecte= d in the current text.

         >

         > Regards,

         >

         > Dan

         >

         >

         >

         >

         >

         >> -----Origina= l Message-----

         [mailto:sacm-bounces@ietf.org] On

         >> Behalf Of Se= an Turner

         >> Sent: Tuesda= y, June 25, 2013 2:06 AM


         >> Cc: Moriarty= , Kathleen; Stephen Hanna; Adam Montville;


         >> Subject: Re:= [sacm] sacm charter review

         >>

         >> On 6/24/13 1= 2:47 PM, Tony Rutkowski wrote:

         >>> SDO is a= n undesirable legacy term.

         >>> Pathetic= ally, the old SDO club still does not regard the IETF as a

         >>> "SD= O!"


         >>> ue

         >>> .j

         >>> sp

         >>>

         >>> Perhaps = it is better to simply use "standards fora."

         >>

         >> I'm not agai= nst just saying organization too.  I don't want to get

         >> in to argume= nts about what's an SDO and what's not.

         >>

         >> spt

         >>

         >>> You shou= ld consider including: NIST, MITRE, and 3GPP - all of

         >>> which ar= e well recognized as key standards bodies currently

         >>> engaged = in SACM related work with whom you should be interested now.

         >>>

         >>> -t

         >>>

         >>> On 6/24/= 2013 11:52 AM, Adam Montville wrote:

         >>>> Ther= e are a variety of other SDOs in which we could be interested

         >>>> now = or in the future.  The short-story list:

         >>>>

         >>>> * FI= RST (vulnerability scoring)

         >>>> * DM= TF (already mentioned)

         >>>> * TC= G (already mentioned)

         >>>> * Th= e Open Group (XDAS and others)

         >>>> * IS= O (i.e. TagVault)

         >>>> * W3= C (i.e. obvious things like XML DigSig, and potentially less

         >>>> obvi= ous things like RDF, OWL, SWRL, etc.)

         >>>> * OA= SIS (i.e. security assertions, key management, alerting)

         >>>> * OM= G (i.e. Business Process Model Notation and/or Execution

         >>>> Lang= uage,

         >>>> etc.= )

         >>>

         >>>

         >> ____________= ___________________________________

         >> sacm mailing= list



         > ________________= _______________________________

         > sacm mailing lis= t



         >

     _____________________________________________= __

     sacm mailing list

     sacm@ietf.or= g <mailto:sacm@ietf.org>


     _____________________________________________= __

     sacm mailing list

     sacm@ietf.or= g <mailto:sacm@ietf.org>


     ...

     This message and attachments may contain conf= idential
     information.  If it appears that th= is message was sent to you by
     mistake, any retention, dissemination, distri= bution or copying of
     this message and attachments is strictly proh= ibited.  Please notify
     the sender immediately and permanently delete= the message and any
     attachments.

     _____________________________________________= __

     sacm mailing list

_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2B6BE2MIVEXAMER1N1corpn_-- From david.waltermire@nist.gov Wed Jun 26 05:23:15 2013 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 301DD21E808C for ; Wed, 26 Jun 2013 05:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[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 UIEU5xxj9de4 for ; Wed, 26 Jun 2013 05:23:10 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 51AEA21F9A5B for ; Wed, 26 Jun 2013 05:23:09 -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.3.123.3; Wed, 26 Jun 2013 08:22:51 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 26 Jun 2013 08:23:08 -0400 From: "Waltermire, David A." To: "Kent_Landfield@McAfee.com" , "turners@ieca.com" , "sacm@ietf.org" Date: Wed, 26 Jun 2013 08:23:07 -0400 Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhuvQoRthgPdUqZE3J5Z9Ln/5lFMPAAgAACywCAABNbgIAAD2wAgABpioCAAJdzAIAATgCAgAAInQCAAAcIAIAAGcIAgAAkFID//+MmAIABGvGAgAA4vYCAACVpgP//nCbw Message-ID: References: <51CAD6F9.5040503@ieca.com> <3CBA099FBA0AB843895D72474092B8CF2B6BC0@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2B6BC0@MIVEXAMER1N1.corp.nai.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_D7A0423E5E193F40BE6E94126930C4930C07324549MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:23:15 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930C07324549MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" We may want to bring in updates of the existing NEA protocols and/or new work created within the TCG. We may also want to consider O-ACEML from the OpenGroup. These have been discussed as options on the list and during the BoFs. Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:11 AM To: turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review >From my perspective the initial organizations we will be dealing with are - ISO/IEC - NIST - MITRE Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 1:56 PM To: "sacm@ietf.org" > Subject: Re: [sacm] sacm charter review It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: Yes. The fact that other organizations are interested in the scope of SACM does not mean that they do the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to refer or document these in An Informational RFC, but this is not a mandatory deliverable. The working group will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. Regards, Dan *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, June 25, 2013 6:41 PM *To:* Kent_Landfield@McAfee.com; Adam.Montville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com *Sent:* Tuesday, June 25, 2013 8:24 AM *To:* Adam.Montville@cisecurity.org ; dbharrington@comcast.net ; turners@ieca.com ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *Adam Montville > *Date: *Tuesday, June 25, 2013 5:15 PM *To: *David Harrington >, Sean Turner >, "sacm@ietf.org " > *Subject: *Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org ] on behalf of David Harrington [dbharrington@comcast.net ] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org ; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com ; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From:sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To:tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >>sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF as a >>> "SDO!" >>>http://www.tta.or.kr/English/new/external_relations/gsc17_communiq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be interested now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be interested >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ 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_D7A0423E5E193F40BE6E94126930C4930C07324549MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFu O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t PjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFz cz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ V2UgbWF5IHdhbnQgdG8gYnJpbmcgaW4gdXBkYXRlcyBvZiB0aGUgZXhpc3RpbmcgTkVBIHByb3Rv Y29scyBhbmQvb3IgbmV3IHdvcmsgY3JlYXRlZCB3aXRoaW4gdGhlIFRDRy4mbmJzcDsgV2UgbWF5 IGFsc28gd2FudCB0byBjb25zaWRlciBPLUFDRU1MIGZyb20gdGhlIE9wZW5Hcm91cC4gVGhlc2Ug aGF2ZSBiZWVuIGRpc2N1c3NlZCBhcyBvcHRpb25zIG9uIHRoZSBsaXN0IGFuZCBkdXJpbmcgdGhl IEJvRnMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIDxi Pk9uIEJlaGFsZiBPZiA8L2I+S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTxicj48Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKdW5lIDI2LCAyMDEzIDg6MTEgQU08YnI+PGI+VG86PC9iPiB0dXJuZXJz QGllY2EuY29tOyBzYWNtQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhY21dIHNh Y20gY2hhcnRlciByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5Gcm9tIG15IHBlcnNwZWN0aXZlIHRoZSBp bml0aWFsIG9yZ2FuaXphdGlvbnMgd2Ugd2lsbCBiZSBkZWFsaW5nIHdpdGggYXJlPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0gSVNPL0lFQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtIE5JU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LSBNSVRSRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+ S2VudCBMYW5kZmllbGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojNjA2QTcxJz48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPk1jQWZlZSB8IEFuIEludGVsIENvbXBhbnk8L3NwYW4+PC9zdHJvbmc+ PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0OiArMS45NzIuOTYzLjcwOTYm bmJzcDs8L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+TW9iaWxlOiArMS44 MTcuNjM3LjgwMjY8L3NwYW4+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz5XZWI6Jm5ic3A7PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNz PWFwcGxlLXN0eWxlLXNwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5tY2FmZWUuY29tLyI+d3d3Lm1j YWZlZS5jb208L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+U2VhbiBUdXJu ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIj50dXJuZXJzQGllY2EuY29t PC9hPiZndDs8YnI+PGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAyNiwgMjAxMyAxOjU2IFBN PGJyPjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21A aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2Fj bUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6IDwvYj5SZTogW3NhY21dIHNhY20gY2hh cnRlciByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1 cHQ7bWFyZ2luLXJpZ2h0OjBpbicgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVP VEUiPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPkl0IGxvb2tzIGxpa2UgSm9lbCB3YW50cyB0byBrbm93IG5vdyBzb21lIG9mIHRoZSBv cmdhbml6YXRpb25zIChpLmUuLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz50aGVyZSdzIGJsb2NrIG9u IHRoZSBjaGFydGVyKS4mbmJzcDsmbmJzcDtDYW4gd2Ugd2hpdHRsZSB0aGlzIGxpc3QgZG93biB0 byBqdXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPm9yZ3Mgd2UncmUgZ29pbmcgdG8gYmUgZGVhbGlu ZyB3aXRoIGF0IHRoZSBpbml0aWFsIHN0YWdlcz8mbmJzcDsmbmJzcDtGb3IgYXNzZXQgPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+aWRlbnRpZmljYXRpb24gaXQncyBwb3NzaWJseSBnb2luZyB0byBiZSBJ U08rTklTVCs/LCBmb3IgZW5kcG9pbnQgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ZWxlbWVudHMgdG8g YXNzZXNzIGl0J3MgPywgZm9yIGNvbXBhcmlzb24gaXQncyA/LCBmb3IgaW50ZXJhY3Rpbmcgd2l0 aCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5yZXBvc2l0b3JpZXMgaXQncyBORUEuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+TW9yZSBpbmxpbmUuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T24gNi8yNi8xMyA0OjMzIEFN LCBSb21hc2NhbnUsIERhbiAoRGFuKSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYg NC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu LXJpZ2h0OjBpbicgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+WWVzLiBUaGUgZmFj dCB0aGF0IG90aGVyIG9yZ2FuaXphdGlvbnMgYXJlIGludGVyZXN0ZWQgaW4gdGhlIHNjb3BlIG9m PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+U0FDTSBkb2VzIG5vdCBtZWFuIHRoYXQgdGhleSBkbyB0aGUg c2FtZSB3b3JrLCBhbmQgY2VydGFpbmx5IHRoZSBmdXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5X RyBtdXN0IGF2b2lkIGR1cGxpY2F0aW9uLiBNYXliZSB3ZSBzaG91bGQgbWFrZSB0aGlzIGV4cGxp Y2l0LiBGb3IgZXhhbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5PTEQ6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjcmVhdGUgYW4gb3ZlcnZpZXcgb2YgcmVsYXRlZCBz dGFuZGFyZHMgd29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPkludGVybmV0LURyYWZ0IHdoaWNoIHdpbGwgZG9jdW1lbnQgZXhpc3Rpbmcgd29yayBpbiB0 aGUgSUVURiBvciBpbiBvdGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlNET3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz53aGljaCBjYW4gYmUgdXNlZCBhcy1p cyBvciBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciBkZXZlbG9waW5nIHNvbHV0aW9uczxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPnRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPlNBQ00gcmVxdWlyZW1lbnRzLiBUaGUgd29ya2luZyBncm91cCBtYXkgZGVjaWRl IHRvIG1ha2Ugb2YgdGhpcyBkb2N1bWVudCBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPkluZm9ybWF0aW9uYWwgUkZDLCBidXQgdGhpcyBpcyBub3QgYSBt YW5kYXRvcnkgZGVsaXZlcmFibGUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY3JlYXRlIGFuIG92ZXJ2aWV3IG9mIHJlbGF0 ZWQgc3RhbmRhcmRzIHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5JbnRlcm5ldC1EcmFmdCB3aGljaCB3aWxsIGRvY3VtZW50IGV4aXN0aW5nIHdvcmsg aW4gdGhlIElFVEYgb3IgaW4gb3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TRE9zPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+d2hpY2ggY2FuIGJlIHVzZWQg YXMtaXMgb3IgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgZGV2ZWxvcGluZyBzb2x1dGlvbnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz50byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5TQUNNIHJlcXVpcmVtZW50cy4gVGhlIHdvcmtpbmcgZ3JvdXAgbWF5IGRl Y2lkZSB0byByZWZlciBvciBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnRoZXNlIGluPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QW4gSW5mb3JtYXRp b25hbCBSRkMsIGJ1dCB0aGlzIGlzIG5vdCBhIG1hbmRhdG9yeSBkZWxpdmVyYWJsZS4gVGhlPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+d29ya2luZyBncm91cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPndpbGwgbm90IGR1cGxpY2F0ZSB3b3JrIGFscmVhZHkgZG9u ZSBvciBpbiBwcm9ncmVzcyBpbiBvdGhlciBwbGFjZXMuPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPldlIHdlcmUgb24gdGhlIHNhbWUg d2F2ZWxlbmd0aC4mbmJzcDsmbmJzcDtJJ20gbm90IHN1cmUgd2UgbmVlZCB0byByZXBlYXRlZCB0 aGUgd2UgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+d29uJ3QgZHVwbGljYXRlIHdvcmsgYmVjYXVzZSB0 aGVyZSdzIGFscmVhZHkgYSBibHVyYiBhYm91dCByZXVzZS4mbmJzcDsmbmJzcDtXaGF0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPkkgcHJvcG9zZWQgdG8gQmFycnkvSm9lbC9TcGVuY2VyOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk9MRDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGUgd29ya2luZyBncm91cCB3aWxs IGNyZWF0ZSBhbiBvdmVydmlldyBvZiByZWxhdGVkIHN0YW5kYXJkcyB3b3JrIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPkludGVybmV0LURyYWZ0IHdoaWNoIHdpbGwgZG9jdW1lbnQgZXhpc3Rpbmcgd29y ayBpbiB0aGUgSUVURiBvciBpbiBvdGhlciA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TRE9zIHdoaWNo IGNhbiBiZSB1c2VkIGFzLWlzIG9yIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGRldmVsb3Bpbmcg PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+c29sdXRpb25zIHRvIHRoZSBTQUNNIHJlcXVpcmVtZW50cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5ORVc6PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhlIHdvcmtpbmcgZ3Jv dXAgd2lsbCBjcmVhdGUgYW4gSW50ZXJuZXQtRHJhZnQgZG9jdW1lbnRpbmcgdGhlIGV4aXN0aW5n IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPndvcmsgaW4gdGhlIElFVEYgYW5kIGluIG90aGVyIG9yZ2Fu aXphdGlvbnMgdGhhdCBtaWdodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmJlIHVzZWQgYXMtaXMgb3Ig YXMgYSBzdGFydGluZyBwb2ludCBmb3IgZGV2ZWxvcGluZyBzb2x1dGlvbnMgdG88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz50aGUgU0FDTSByZXF1aXJlbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPkluIGFjY29yZGFuY2Ugd2l0aCBleGlzdGluZyBJRVRGIHByb2Nl c3NlcywgdGhlIGdyb3VwIHdpbGwgY29tbXVuaWNhdGUgPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+d2l0 aCBhbmQgaW52aXRlIHBhcnRpY2lwYXRpb24gZnJvbSBvdGhlciByZWxldmFudCBzdGFuZGFyZHMg Ym9kaWVzIGFuZCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5yZWd1bGF0b3J5IG9yZ2FuaXphdGlvbnMs IGFuZCBpZiBuZWNlc3NhcnkgcmV1c2UgZXhpc3RpbmcgbGlhaXNvbiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5yZWxhdGlvbnNoaXBzIG9yIHJlcXVlc3QgdGhlIGVzdGFibGlzaG1lbnQgb2YgbmV3IGxp YWlzb24gcmVsYXRpb25zaGlwcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz5ORVc6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+SW4gYWNjb3JkYW5jZSB3aXRoIGV4aXN0aW5nIElFVEYgcHJvY2Vzc2VzLCB0aGUgd29y a2luZyBncm91cCB3aWxsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmNvbW11bmljYXRlIHdpdGggYW5k IGludml0ZSBwYXJ0aWNpcGF0aW9uIGZyb20gb3RoZXIgcmVsZXZhbnQgZ3JvdXBzIGFuZCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5yZWd1bGF0b3J5IG9yZ2FuaXphdGlvbnMsIGFuZCBpZiBuZWNlc3Nh cnkgcmV1c2UgZXhpc3RpbmcgbGlhaXNvbiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5yZWxhdGlvbnNo aXBzIG9yIHJlcXVlc3QgdGhlIGVzdGFibGlzaG1lbnQgb2YgbmV3IGxpYWlzb24gcmVsYXRpb25z aGlwcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbicgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4qRnJvbTo8YSBocmVmPSJtYWlsdG86KnNhY20tYm91bmNlc0BpZXRmLm9yZyI+ KnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSAqT24gQmVoYWxmPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+T2YgKk1pY2hhZWwgSGFtbWVyPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ KlNlbnQ6KiBUdWVzZGF5LCBKdW5lIDI1LCAyMDEzIDY6NDEgUE08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4qVG86KiA8YSBocmVmPSJtYWlsdG86S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbSI+S2VudF9M YW5kZmllbGRATWNBZmVlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpBZGFtLk1vbnR2aWxsZUBj aXNlY3VyaXR5Lm9yZyI+QWRhbS5Nb250dmlsbGVAY2lzZWN1cml0eS5vcmc8L2E+OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpkYmhhcnJpbmd0b25AY29tY2FzdC5uZXQiPmRi aGFycmluZ3RvbkBjb21jYXN0Lm5ldDwvYT47IDxhIGhyZWY9Im1haWx0bzp0dXJuZXJzQGllY2Eu Y29tIj50dXJuZXJzQGllY2EuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmci PnNhY21AaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+KlN1YmplY3Q6KiBSZTogW3Nh Y21dIHNhY20gY2hhcnRlciByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4rMSZuYnNwOyZuYnNwO1RoaXMganVzdCBtZWFucyBtYW55IGdyb3VwcyBh cmUgaW50ZXJlc3RlZCBpbiB0aGUgc2FtZSBzY29wZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5NaWtlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+KkZyb206PGEgaHJlZj0ibWFpbHRvOipzYWNtLWJvdW5jZXNAaWV0 Zi5vcmciPipzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2Fj bS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5bPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2YgPGEgaHJl Zj0ibWFpbHRvOipLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tIj4qS2VudF9MYW5kZmllbGRATWNB ZmVlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbHQ7PGEgaHJlZj0ibWFpbHRvOktlbnRf TGFuZGZpZWxkQE1jQWZlZS5jb20iPm1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPC9h PiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4qU2VudDoqIFR1ZXNkYXksIEp1bmUgMjUsIDIwMTMg ODoyNCBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPipUbzoqIDxhIGhyZWY9Im1haWx0bzpBZGFtLk1v bnR2aWxsZUBjaXNlY3VyaXR5Lm9yZyI+QWRhbS5Nb250dmlsbGVAY2lzZWN1cml0eS5vcmc8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jmx0OzxhIGhyZWY9Im1haWx0bzpBZGFtLk1vbnR2aWxsZUBj aXNlY3VyaXR5Lm9yZyI+bWFpbHRvOkFkYW0uTW9udHZpbGxlQGNpc2VjdXJpdHkub3JnPC9hPiZn dDs7IDxhIGhyZWY9Im1haWx0bzpkYmhhcnJpbmd0b25AY29tY2FzdC5uZXQiPmRiaGFycmluZ3Rv bkBjb21jYXN0Lm5ldDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbHQ7PGEgaHJlZj0ibWFpbHRv OmRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCI+bWFpbHRvOmRiaGFycmluZ3RvbkBjb21jYXN0Lm5l dDwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86dHVybmVyc0BpZWNhLmNvbSI+dHVybmVyc0BpZWNh LmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbHQ7PGEgaHJlZj0ibWFpbHRvOnR1cm5lcnNA aWVjYS5jb20iPm1haWx0bzp0dXJuZXJzQGllY2EuY29tPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0 bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNh Y21AaWV0Zi5vcmciPm1haWx0bzpzYWNtQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4qU3ViamVjdDoqIFJlOiBbc2FjbV0gc2FjbSBjaGFydGVyIHJldmlldzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPldlbGwgc2FpZCBBZGFtLiBJIHRv dGFsbHkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPipLZW50IExhbmRmaWVsZCo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4qTWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueSo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5EaXJlY3Q6ICsxLjk3Mi45NjMuNzA5NjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPk1vYmlsZTogKzEuODE3LjYzNy44MDI2PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+KldlYjog Knd3dy5tY2FmZWUuY29tICZsdDs8YSBocmVmPSJodHRwOi8vd3d3Lm1jYWZlZS5jb20vIj5odHRw Oi8vd3d3Lm1jYWZlZS5jb20vPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4qRnJvbTogKkFkYW0gTW9udHZpbGxlICZsdDs8YSBocmVmPSJtYWls dG86QWRhbS5Nb250dmlsbGVAY2lzZWN1cml0eS5vcmciPkFkYW0uTW9udHZpbGxlQGNpc2VjdXJp dHkub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZsdDs8YSBocmVmPSJtYWlsdG86QWRhbS5N b250dmlsbGVAY2lzZWN1cml0eS5vcmclM2UiPm1haWx0bzpBZGFtLk1vbnR2aWxsZUBjaXNlY3Vy aXR5Lm9yZyZndDs8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPipEYXRlOiAqVHVlc2RheSwg SnVuZSAyNSwgMjAxMyA1OjE1IFBNPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+KlRvOiAqRGF2aWQgSGFy cmluZ3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCI+ZGJo YXJyaW5ndG9uQGNvbWNhc3QubmV0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZsdDs8YSBocmVm PSJtYWlsdG86ZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0JTNlIj5tYWlsdG86ZGJoYXJyaW5ndG9u QGNvbWNhc3QubmV0Jmd0OzwvYT4mZ3Q7LCBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRv OnR1cm5lcnNAaWVjYS5jb20iPnR1cm5lcnNAaWVjYS5jb208L2E+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jmx0OzxhIGhyZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29tJTNlIj5tYWlsdG86dHVybmVy c0BpZWNhLmNvbSZndDs8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5v cmciPnNhY21AaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyUz ZSI+bWFpbHRvOnNhY21AaWV0Zi5vcmcmZ3Q7PC9hPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4gJmx0 OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnJTNlIj5tYWlsdG86c2FjbUBpZXRmLm9yZyZn dDs8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPipTdWJqZWN0OiAqUmU6IFtzYWNtXSBzYWNt IGNoYXJ0ZXIgcmV2aWV3PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIERhdmlkLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJ IHJlc3BlY3RmdWxseSBkaXNhZ3JlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hpbGUgdGhpcyBtYXkgYmUg YSBjb21tZW50YXJ5IG9uIHRoZSBwb3RlbnRpYWwsIGV2ZW50dWFsIHJlYWNoIG9mPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNBQ00sIG91ciBjaGFydGVyJ3Mg c2NvcGUgaXMgZmFyIHJlZHVjZWQgZnJvbSBpbmNsdWRpbmcgYWxsIG9mIHRoZXNlPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yZ2FuaXphdGlvbnMgYXQgdGhl IG91dHNldC4mbmJzcDsmbmJzcDtJbiBvdGhlciB3b3Jkcywgb3VyIHNjb3BlIGlzIGxpbWl0ZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkgdGhlIGxhbmd1 YWdlIGluIHRoZSBjaGFydGVyLCBhZ2FpbnN0IHdoaWNoIHRoaXMgbGlzdCByZWFsbHkgaGFzPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vIGJlYXJpbmcgb3Ro ZXIgdGhhbiB0byBzYXRpc2Z5IGN1cmlvc2l0eSBhbmQsIHBlcmhhcHMsIGxlbmQgc29tZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2aXNpb24gdG8gdGhlIGZ1 dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gZmFjdCwgaXQgbWlnaHQgYmUgbW9yZSBwcm9wZXJseSBj b25zdHJ1ZWQgdGhhdCB0aGlzIGxpc3Qgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgb3JnYW5pemF0aW9ucyBpcyBhIGNvbW1lbnRhcnkgb24gdGhlIHViaXF1 aXRvdXMgbmF0dXJlIG9mIGFzc2Vzc21lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBpdCBpcyBhIGNhcGFiaWxpdHkgdGhhdCAmcXVvdDt0b3VjaGVzJnF1 b3Q7IGEgbG90IG9mIGRpZmZlcmVudCBhcmVhcywgd2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgcHJlY2lzZWx5IHdoeSBpdCB3YXJyYW50cyBpdHMg b3duIHdvcmtpbmcgZ3JvdXAsIElNTy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQWRhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb206IDxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5j ZXNAaWV0Zi5vcmciPnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0 bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbPGEgaHJl Zj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyI+c2FjbS1ib3VuY2VzQGlldGYub3JnPC9h PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyUzZSI+bWFpbHRvOnNh Y20tYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+XSBvbiBiZWhhbGYgb2Y8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF2aWQgSGFycmluZ3RvbiBbPGEgaHJlZj0i bWFpbHRvOmRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCI+ZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0 PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCUzZSI+bWFpbHRvOmRiaGFycmlu Z3RvbkBjb21jYXN0Lm5ldCZndDs8L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZW50OiBUdWVzZGF5LCBK dW5lIDI1LCAyMDEzIDY6NDMgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG86ICdTZWFuIFR1cm5lcic7IDxh IGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPm1haWx0bzpzYWNtQGlldGYub3JnPC9hPiZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU3ViamVjdDogUmU6IFtzYWNtXSBzYWNtIGNoYXJ0ZXIgcmV2aWV3PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFdvdyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayB0aGlzIGlzIGFuIGV4Y2VsbGVu dCBjb21tZW50YXJ5IG9uIHRoZSBzY29wZSBvZiBTQUNNIGJlaW5nPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdheSB0b288bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnJvYWQs IGFuZCBwb29ybHkgc2NvcGVkIGZvciBlbmdpbmVlcmluZyBwdXJwb3Nlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgRGF2aWQgSGFycmluZ3RvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86ZGJoYXJy aW5ndG9uQGNvbWNhc3QubmV0Ij5kYmhhcnJpbmd0b25AY29tY2FzdC5uZXQ8L2E+ICZsdDs8YSBo cmVmPSJtYWlsdG86ZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0Ij5tYWlsdG86ZGJoYXJyaW5ndG9u QGNvbWNhc3QubmV0PC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKzEtNjAzLTgyOC0xNDAxPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb206 IDxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmciPnNhY20tYm91bmNlc0BpZXRm Lm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBbPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBSb21hc2NhbnUsIERhbiAoRGFuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZW50OiBUdWVzZGF5 LCBKdW5lIDI1LCAyMDEzIDk6MTggQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG86IFNlYW4gVHVybmVyPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENjOiBNb3JpYXJ0eSwgS2F0aGxlZW47IFN0ZXBoZW4gSGFubmE7IEFkYW0g TW9udHZpbGxlOyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5tYWlsdG86c2FjbUBpZXRmLm9yZzwvYT4mZ3Q7Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86dG9ueUB5YWFuYXRlY2guY29tIj50b255QHlh YW5hdGVjaC5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueUB5YWFuYXRlY2guY29tIj5t YWlsdG86dG9ueUB5YWFuYXRlY2guY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3ViamVjdDog UmU6IFtzYWNtXSBzYWNtIGNoYXJ0ZXIgcmV2aWV3PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIFNlYW4sPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEEgbGlzdCBvZiBvcmdhbml6YXRpb25zIHRoYXQgYXJlIGludm9sdmVkIGlu IHRoZSBhcmVhLCBhcyBpZGVudGlmaWVkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGluIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlzY3Vzc2lvbiBpbmNsdWRlczo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBUQ0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBETVRGPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0gRklSU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBUaGUgT3BlbiBHcm91cDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt IElTTy9JRUM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBXM0M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBPQVNJUzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtIE9NRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE5JU1Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBN SVRSRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtIDNHUFA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQncyB1cCB0byB0aGUg SUVTRyB0byBkZWNpZGUgaWYgd2Ugc2hvdWxkIGxpc3QgdGhlc2UgKG9yIHNvbWUgb2YgdGhlbSk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZXhwbGljaXRseSwgb3Igd2Ugc2hvdWxkIGxlYXZlIHRvIHRoZSBXRyBh ZnRlciBpdHMgZm9ybWF0aW9uIGlzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGFwcHJvdmVkIHRvPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluaXRpYXRlIGNvbW11bmljYXRp b24gYW5kIGludml0ZSBwYXJ0aWNpcGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBEYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgRnJvbTogU2VhbiBUdXJuZXIgWzxhIGhyZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29t Ij5tYWlsdG86dHVybmVyc0BpZWNhLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMjUsIDIwMTMgMzo0NyBQTTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUbzogUm9tYXNjYW51LCBEYW4gKERhbik8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2M6IDxhIGhyZWY9Im1haWx0 bzp0b255QHlhYW5hdGVjaC5jb20iPnRvbnlAeWFhbmF0ZWNoLmNvbTwvYT4gJmx0OzxhIGhyZWY9 Im1haWx0bzp0b255QHlhYW5hdGVjaC5jb20iPm1haWx0bzp0b255QHlhYW5hdGVjaC5jb208L2E+ Jmd0OzsgQWRhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNb250dmlsbGU7IFN0ZXBoZW4gSGFubmE7IE1vcmlhcnR5 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBLYXRobGVlbjsgPGEgaHJl Zj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86c2FjbUBpZXRmLm9yZyI+bWFpbHRvOnNhY21AaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdWJqZWN0OiBSZTogW3NhY21dIHNhY20g Y2hhcnRlciByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXQg dGhpcyBwb2ludCAzIEFEcyBoYXZlIGFza2VkIGFib3V0IHdoYXQgb3RoZXIgU0RPcyBhcmUgaW52 b2x2ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEknbSBub3Qgc3Vy ZSBpZiB0aGV5IHdhbnQgbmFtZXMgaW4gdGhlIGNoYXJ0ZXIgb3IgaWYgdGhleSdyZSBqdXN0PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyZXN0ZWQgaW4ga25vd2lu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3B0PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIDYvMjUvMTMgNDowNyBBTSwgUm9tYXNjYW51 LCBEYW4gKERhbikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgVGhlIHByb3Bvc2VkIHRleHQgaW4gdGhlIGNoYXJ0ZXIgYWxyZWFkeSBzYXlzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEluIGFjY29yZGFuY2Ugd2l0aCBleGlzdGlu ZyBJRVRGIHByb2Nlc3NlcywgdGhlIGdyb3VwIHdpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgY29tbXVuaWNhdGUgd2l0aCBhbmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpbnZpdGUgcGFydGljaXBhdGlvbiBmcm9t IG90aGVyIHJlbGV2YW50IHN0YW5kYXJkcyBib2RpZXMgYW5kPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcmVndWxhdG9yeSBvcmdhbml6YXRpb25zLCBhbmQgaWYg bmVjZXNzYXJ5IHJldXNlIGV4aXN0aW5nIGxpYWlzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyByZWxhdGlvbnNoaXBzIG9yIHJlcXVlc3QgdGhlIGVzdGFibGlz aG1lbnQgb2YgbmV3IGxpYWlzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcmVsYXRpb25zaGlwcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICdzdGFuZGFy ZCBib2RpZXMgYW5kIHJlZ3VsYXRvcnkgb3JnYW5pemF0aW9ucycgYXJlIG5ldXRyYWwgdGVybXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5vdWdoIElNTywgYXMgU2Vh biBzYXlzIHdlIHNob3VsZCBub3QgZW50ZXIgdGhlICd3aGF0IGlzIGFuIFNETzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkaXNwdXRlJy4gV2UgYXJlIGRlYWxpbmcgbm90 IG9ubHkgd2l0aCBzdGFuZGFyZHMgb3JnYW5pemF0aW9ucyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBpcyBhbHNvIHJlZmxlY3RlZCBpbiB0aGUgY3VycmVu dCB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgUmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IERhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgRnJvbTo8YSBocmVmPSJtYWlsdG86c2FjbS1ib3Vu Y2VzQGlldGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWls dG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPC9h PiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgWzxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBCZWhhbGYgT2YgU2VhbiBUdXJuZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgU2VudDogVHVlc2RheSwg SnVuZSAyNSwgMjAxMyAyOjA2IEFNPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7IFRvOjxhIGhyZWY9Im1haWx0bzp0b255QHlhYW5hdGVjaC5jb20iPnRvbnlA eWFhbmF0ZWNoLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255QHlhYW5hdGVjaC5jb20i Pm1haWx0bzp0b255QHlhYW5hdGVjaC5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBDYzogTW9yaWFydHksIEthdGhsZWVuOyBTdGVwaGVu IEhhbm5hOyBBZGFtIE1vbnR2aWxsZTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5tYWlsdG86c2FjbUBpZXRm Lm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7IFN1YmplY3Q6IFJlOiBbc2FjbV0gc2FjbSBjaGFydGVyIHJldmlldzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBPbiA2LzI0LzEzIDEyOjQ3IFBNLCBUb255IFJ1dGtv d3NraSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7IFNETyBpcyBhbiB1bmRlc2lyYWJsZSBsZWdhY3kgdGVybS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFBhdGhldGljYWxseSwgdGhlIG9s ZCBTRE8gY2x1YiBzdGlsbCBkb2VzIG5vdCByZWdhcmQgdGhlIElFVEYgYXMgYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgJnF1b3Q7U0RPISZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8YSBo cmVmPSJodHRwOi8vd3d3LnR0YS5vci5rci9FbmdsaXNoL25ldy9leHRlcm5hbF9yZWxhdGlvbnMv Z3NjMTdfY29tbXVuaXEiPmh0dHA6Ly93d3cudHRhLm9yLmtyL0VuZ2xpc2gvbmV3L2V4dGVybmFs X3JlbGF0aW9ucy9nc2MxN19jb21tdW5pcTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IHVlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyAuajxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgc3A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyBQZXJoYXBzIGl0IGlzIGJldHRlciB0byBzaW1wbHkgdXNlICZxdW90O3N0 YW5kYXJkcyBmb3JhLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyBJJ20gbm90IGFnYWluc3QganVzdCBzYXlpbmcgb3JnYW5pemF0aW9uIHRvby4mbmJzcDsmbmJz cDtJIGRvbid0IHdhbnQgdG8gZ2V0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7IGluIHRvIGFyZ3VtZW50cyBhYm91dCB3aGF0J3MgYW4gU0RPIGFuZCB3aGF0 J3Mgbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBzcHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFlvdSBzaG91bGQgY29uc2lkZXIg aW5jbHVkaW5nOiBOSVNULCBNSVRSRSwgYW5kIDNHUFAgLSBhbGwgb2Y8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IHdoaWNoIGFyZSB3ZWxsIHJlY29n bml6ZWQgYXMga2V5IHN0YW5kYXJkcyBib2RpZXMgY3VycmVudGx5PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBlbmdhZ2VkIGluIFNBQ00gcmVsYXRl ZCB3b3JrIHdpdGggd2hvbSB5b3Ugc2hvdWxkIGJlIGludGVyZXN0ZWQgbm93LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IC10PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgT24gNi8yNC8yMDEzIDExOjUyIEFNLCBBZGFt IE1vbnR2aWxsZSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBhcmUgYSB2YXJpZXR5IG9mIG90aGVyIFNET3MgaW4gd2hp Y2ggd2UgY291bGQgYmUgaW50ZXJlc3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdyBvciBpbiB0aGUgZnV0dXJlLiZuYnNwOyZuYnNw O1RoZSBzaG9ydC1zdG9yeSBsaXN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsgKiBGSVJTVCAodnVsbmVyYWJpbGl0eSBzY29yaW5nKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7ICogRE1U RiAoYWxyZWFkeSBtZW50aW9uZWQpPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsgKiBUQ0cgKGFscmVhZHkgbWVudGlvbmVkKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7ICogVGhlIE9wZW4g R3JvdXAgKFhEQVMgYW5kIG90aGVycyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyAqIElTTyAoaS5lLiBUYWdWYXVsdCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyAqIFczQyAoaS5lLiBv YnZpb3VzIHRoaW5ncyBsaWtlIFhNTCBEaWdTaWcsIGFuZCBwb3RlbnRpYWxseSBsZXNzPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgb2J2aW91 cyB0aGluZ3MgbGlrZSBSREYsIE9XTCwgU1dSTCwgZXRjLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyAqIE9BU0lTIChpLmUuIHNlY3VyaXR5 IGFzc2VydGlvbnMsIGtleSBtYW5hZ2VtZW50LCBhbGVydGluZyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyAqIE9NRyAoaS5lLiBCdXNpbmVz cyBQcm9jZXNzIE1vZGVsIE5vdGF0aW9uIGFuZC9vciBFeGVjdXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBMYW5ndWFnZSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBldGMuKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7IHNhY20gbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmci PnNhY21AaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+bWFp bHRvOnNhY21AaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FjbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc2FjbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3Jn Ij5zYWNtQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPm1h aWx0bzpzYWNtQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FjbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNhY20gbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpz YWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY21A aWV0Zi5vcmciPm1haWx0bzpzYWNtQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNhY20gbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpzYWNt QGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0 Zi5vcmciPm1haWx0bzpzYWNtQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGlzIG1lc3NhZ2UgYW5kIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp bmZvcm1hdGlvbi4mbmJzcDsmbmJzcDtJZiBpdCBhcHBlYXJzIHRoYXQgdGhpcyBtZXNzYWdlIHdh cyBzZW50IHRvIHlvdSBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBtaXN0YWtlLCBhbnkgcmV0ZW50aW9uLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGlzIG1lc3NhZ2UgYW5kIGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5i c3A7Jm5ic3A7UGxlYXNlIG5vdGlmeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG1lc3NhZ2UgYW5kIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2FjbSBtYWlsaW5nIGxp c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0 Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+bWFpbHRvOnNhY21A aWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5zYWNtIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2FjbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zYWNtPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRt bD4= --_000_D7A0423E5E193F40BE6E94126930C4930C07324549MBCLUSTERxcha_-- From Kent_Landfield@mcafee.com Wed Jun 26 05:45:26 2013 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 13F7011E81AB for ; Wed, 26 Jun 2013 05:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEib5Dk3YHF2 for ; Wed, 26 Jun 2013 05:45:21 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 43BA511E81A0 for ; Wed, 26 Jun 2013 05:45:20 -0700 (PDT) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 6c68_2bd3_afca133a_d625_4cc5_a05f_6f3385529851; Wed, 26 Jun 2013 07:45:20 -0500 Received: from MIVEXAMER2N3.corp.nai.org (10.48.48.23) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 26 Jun 2013 08:44:41 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER2N3.corp.nai.org ([169.254.3.200]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 08:44:41 -0400 From: To: , , Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhuvQoRthgPdUqZE3J5Z9Ln/5lFMPAAgAACywCAABNbgIAAD2wAgABpioCAAJdzAIAATgCAgAAInQCAAAcIAIAAGcIAgAAkFID//+MmAIABGvGAgAA4vYCAACVpgP//nCbwgABtXIA= Date: Wed, 26 Jun 2013 12:44:41 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.48.48.243] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2B6C55MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:45:26 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2B6C55MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I assumed that MILE and NEA were already identified from charter references= and was looking at only organizations external to the IETF. Individuals fr= om the organizations I listed either are or have had active discussions to = contribute to the proposed WG. I am not sure initially we are talking abou= t TCG related work. Yes, it could be possible but that is up to the TCG to = contribute their work into the group as a proposal. Same for O-ACEML. Those= proposals need to fit the proposed charter and be made to the working grou= p itself. If they are making proposals for work items to the SACM WG then = they would be following the IETF IPR rules for documents contributed. The k= ey here is that the work would be done in SACM and should not be duplicatin= g work elsewhere. I guess I need clarity from Sean. I was looking at what organizations woul= d be directly working with the SACM initially. Liaison or otherwise. I full= y expect we would invite others to participate in SACM. I personally plan = on trying to assure all are aware of the SACM efforts and goals. Developin= g a list of who to invite is different from the perspective I responded wit= h. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Wednesday, June 26, 2013 2:23 PM To: Kent Landfield >, Sean Turner >, "sacm@ietf.= org" > Subject: RE: [sacm] sacm charter review We may want to bring in updates of the existing NEA protocols and/or new wo= rk created within the TCG. We may also want to consider O-ACEML from the O= penGroup. These have been discussed as options on the list and during the B= oFs. Dave From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:11 AM To: turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review >From my perspective the initial organizations we will be dealing with are - ISO/IEC - NIST - MITRE Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 1:56 PM To: "sacm@ietf.org" > Subject: Re: [sacm] sacm charter review It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: Yes. The fact that other organizations are interested in the scope of SACM does not mean that they do the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to refer or document these in An Informational RFC, but this is not a mandatory deliverable. The working group will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. Regards, Dan *From:*sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, June 25, 2013 6:41 PM *To:* Kent_Landfield@McAfee.com; Adam.Mon= tville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com= ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com *Sent:* Tuesday, June 25, 2013 8:24 AM *To:* Adam.Montville@cisecurity.org ; dbharrington@comcast.net ; turners@ieca.com ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *Adam Montville > *Date: *Tuesday, June 25, 2013 5:15 PM *To: *David Harrington >, Sea= n Turner >, "sacm@ietf.org " > *Subject: *Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org ] on behalf of David Harrington [dbharrington@comcast.net ] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org ; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them= ) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com ; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaiso= n > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From:sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To:tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >>sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF = as a >>> "SDO!" >>>http://www.tta.or.kr/English/new/external_relations/gsc17_commu= niq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to = get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be intereste= d now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be intere= sted >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially l= ess >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ 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_3CBA099FBA0AB843895D72474092B8CF2B6C55MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Dave,

I assumed that MILE and NEA were already identified from charter refer= ences and was looking at only organizations external to the IETF. Individua= ls from the organizations I listed either are or have had active discussion= s to contribute to the proposed WG.  I am not sure initially we are talking about TCG related work. Y= es, it could be possible but that is up to the TCG to contribute their work= into the group as a proposal. Same for O-ACEML. Those proposals need to fi= t the proposed charter and be made to the working group itself.  If they are making proposals for work item= s to the SACM WG then they would be following the IETF IPR rules for docume= nts contributed. The key here is that the work would be done in SACM and sh= ould not be duplicating work elsewhere.

I guess I need clarity from Sean.  I was looking at what organiza= tions would be directly working with the SACM initially. Liaison or otherwi= se. I fully expect we would invite others to participate in SACM.  I p= ersonally plan on trying to assure all are aware of the SACM efforts and goals.  Developing a list of who to inv= ite is different from the perspective I responded with.

Kent Landfield

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

From: <Waltermire>, David Wal= termire <david.waltermire@n= ist.gov>
Date: Wednesday, June 26, 2013 2:23= PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, Sean Tu= rner <turners@ieca.com>, &quo= t;sacm@ietf.org" <sacm@ietf.org>
Subject: RE: [sacm] sacm charter re= view

We may want to bring in updates of= the existing NEA protocols and/or new work created within the TCG.  W= e may also want to consider O-ACEML from the OpenGroup. These have been discussed as options on the list and during= the BoFs.

 

Dave

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Wednesday, June 26, 2013 8:11 AM
To: turners@ieca.com; sacm@ietf.org
Subject: Re: [sacm] sacm charter review

 

From my perspective the = initial organizations we will be dealing with are

 =

    = - ISO/IEC

    = - NIST

    = - MITRE

 =

Kent Landfield


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

 =

From: Sean Turner <turne= rs@ieca.com>
Date: Wednesday, June 26, 2013 1:56 PM
To: "sacm@ietf.org" &= lt;sacm@ietf.org>
Subject: Re: [sacm] sacm charter review

 =

It looks like Joel wants= to know now some of the organizations (i.e.,

there's block on the cha= rter).  Can we whittle this list down to just

orgs we're going to be d= ealing with at the initial stages?  For asset

identification it's poss= ibly going to be ISO+NIST+?, for endpoint

elements to assess it's = ?, for comparison it's ?, for interacting with

repositories it's NEA.

 =

More inline.<= /span>

 =

On 6/26/13 4:33 AM, Roma= scanu, Dan (Dan) wrote:

Yes. The fact that other= organizations are interested in the scope of

SACM does not mean that = they do the same work, and certainly the future

WG must avoid duplicatio= n. Maybe we should make this explicit. For example:

 =

OLD:

 =

The working group will c= reate an overview of related standards work

 =

Internet-Draft which wil= l document existing work in the IETF or in other

SDOs

 =

which can be used as-is = or as a starting point for developing solutions

to the=

 =

SACM requirements. The w= orking group may decide to make of this document an

 =

Informational RFC, but t= his is not a mandatory deliverable.

 =

NEW:

 =

The working group will c= reate an overview of related standards work

 =

Internet-Draft which wil= l document existing work in the IETF or in other

SDOs

 =

which can be used as-is = or as a starting point for developing solutions

to the=

 =

SACM requirements. The w= orking group may decide to refer or document

these in

 =

An Informational RFC, bu= t this is not a mandatory deliverable. The

working group=

 =

will not duplicate work = already done or in progress in other places.

 =

We were on the same wave= length.  I'm not sure we need to repeated the we

won't duplicate work bec= ause there's already a blurb about reuse.  What

I proposed to Barry/Joel= /Spencer:

 =

OLD:

 =

The working group will c= reate an overview of related standards work

Internet-Draft which wil= l document existing work in the IETF or in other

SDOs which can be used a= s-is or as a starting point for developing

solutions to the SACM re= quirements.

 =

NEW:

 =

The working group will c= reate an Internet-Draft documenting the existing

work in the IETF and in = other organizations that might

be used as-is or as a st= arting point for developing solutions to

the SACM requirements.

 =

OLD:

 =

In accordance with exist= ing IETF processes, the group will communicate

with and invite particip= ation from other relevant standards bodies and

regulatory organizations= , and if necessary reuse existing liaison

relationships or request= the establishment of new liaison relationships.

 =

NEW:

 =

In accordance with exist= ing IETF processes, the working group will

communicate with and inv= ite participation from other relevant groups and

regulatory organizations= , and if necessary reuse existing liaison

relationships or request= the establishment of new liaison relationships.

 =

 =

Regards,

 =

Dan

 =

Of *Michael Hammer<= /o:p>

*Sent:* Tuesday, June 25= , 2013 6:41 PM

*Subject:* Re: [sacm] sa= cm charter review

 =

+1  This j= ust means many groups are interested in the same scope.

 =

Mike

 =

*Sent:* Tuesday, June 25= , 2013 8:24 AM

*Subject:* Re: [sacm] sa= cm charter review

 =

Well said Adam. I totall= y agree with your comments.

 =

*Kent Landfield*

 =

*McAfee | An Intel Compa= ny*

Direct: +1.972.963.7= 096

Mobile: +1.817.637.8= 026

*Web: *www.mcafee.com &l= t;http://www.mcafee.com/>

 =

*From: *Adam Montville &= lt;Adam.Montville@cisecuri= ty.org

*Date: *Tuesday, June 25= , 2013 5:15 PM

*Subject: *Re: [sacm] sa= cm charter review

 =

    = Hi David,

 =

    = I respectfully disagree.

 =

    = While this may be a commentary on the potential, eventual reach of

    = SACM, our charter's scope is far reduced from including all of these<= /o:p>

    = organizations at the outset.  In other words, our scope is limit= ed

    = by the language in the charter, against which this list really has

    = no bearing other than to satisfy curiosity and, perhaps, lend some

    = vision to the future.

 =

    = In fact, it might be more properly construed that this list of<= /span>

    = organizations is a commentary on the ubiquitous nature of assessment<= /o:p>

    = - it is a capability that "touches" a lot of different areas, wh= ich

    = is precisely why it warrants its own working group, IMO.=

 =

    = Regards,

 =

    = Adam

 =

    = ________________________________________

 =

    = [sacm-bounces@ietf.org <mailto:sacm-bounces@ietf.org><= /a>] on behalf of

    = David Harrington [dbharrington= @comcast.net

 =

    = Sent: Tuesday, June 25, 2013 6:43 AM

 =

    = To: 'Sean Turner'; sacm@ietf.org <mailto:sacm@ietf.org= >

 =

    = Subject: Re: [sacm] sacm charter review

 =

    = Wow!

 =

    = I think this is an excellent commentary on the scope of SACM being

    = way too

 =

    = broad, and poorly scoped for engineering purposes.

 =

    = David Harrington

 =

 =

    = +1-603-828-1401

 =

    = -----Original Message-----

 =

    = [mailto:sacm-bounces@ietf.org= ] On Behalf Of

 =

    = Romascanu, Dan (Dan)

 =

    = Sent: Tuesday, June 25, 2013 9:18 AM

 =

    = To: Sean Turner

 =

    = Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org

    = <mailto:sacm@ietf.org>;

 =

 =

    = Subject: Re: [sacm] sacm charter review

 =

    = Hi Sean,

 =

    = A list of organizations that are involved in the area, as identified<= /o:p>

    = in this

 =

    = discussion includes:

 =

    = - TCG

 =

    = - DMTF

 =

    = - FIRST

 =

    = - The Open Group

 =

    = - ISO/IEC

 =

    = - W3C

 =

    = - OASIS

 =

    = - OMG

 =

    = - NIST

 =

    = - MITRE

 =

    = - 3GPP

 =

    = It's up to the IESG to decide if we should list these (or some of them)

 =

    = explicitly, or we should leave to the WG after its formation is=

    = approved to

 =

    = initiate communication and invite participation.

 =

    = Regards,

 =

    = Dan

 =

    =      -----Original Message-----

 =

    =      From: Sean Turner [mailto:turners@ieca.com]

 =

    =      Sent: Tuesday, June 25, 2013 3:47 PM

 =

    =      To: Romascanu, Dan (Dan)

 =

    =      Cc: tony@yaanatech.com <mailto:ton= y@yaanatech.com>; Adam

    =      Montville; Stephen Hanna; Moriarty,

 =

    =      Kathleen; sacm@ietf.org <mailto:sacm@ietf.org= >

 =

    =      Subject: Re: [sacm] sacm charter review=

 =

    =      At this point 3 ADs have asked about what other SD= Os are involved.

 =

    =      I'm not sure if they want names in the charter or = if they're just

 =

    =      interested in knowing.

 =

    =      spt

 =

    =      On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote:

 =

    =      > The proposed text in the charter already says= :

 =

    =      >

 =

    =      >> In accordance with existing IETF processe= s, the group will

 =

    =      >> communicate with and

 =

    =      > invite participation from other relevant stan= dards bodies and

 =

    =      > regulatory organizations, and if necessary re= use existing liaison

 =

    =      > relationships or request the establishment of= new liaison

 =

    =      relationships.

 =

    =      >

 =

    =      > 'standard bodies and regulatory organizations= ' are neutral terms

 =

    =      enough IMO, as Sean says we should not enter the '= what is an SDO

 =

    =      dispute'. We are dealing not only with standards o= rganizations and

 =

    =      this is also reflected in the current text.

 =

    =      >

 =

    =      > Regards,

 =

    =      >

 =

    =      > Dan

 =

    =      >

 =

    =      >

 =

    =      >

 =

    =      >

 =

    =      >

 =

    =      >> -----Original Message-----

 =

    =      [mailto:s= acm-bounces@ietf.org] On

 =

    =      >> Behalf Of Sean Turner

 =

    =      >> Sent: Tuesday, June 25, 2013 2:06 AM=

 =

 =

    =      >> Cc: Moriarty, Kathleen; Stephen Hanna; Ad= am Montville;

 =

    =      >>sacm@ietf= .org <mailto:sacm@ietf.org><= o:p>

 =

    =      >> Subject: Re: [sacm] sacm charter review

 =

    =      >>

 =

    =      >> On 6/24/13 12:47 PM, Tony Rutkowski wrote= :

 =

    =      >>> SDO is an undesirable legacy term.

 =

    =      >>> Pathetically, the old SDO club still = does not regard the IETF as a

 =

    =      >>> "SDO!"

 =

 =

    =      >>> ue

 =

    =      >>> .j

 =

    =      >>> sp

 =

    =      >>>

 =

    =      >>> Perhaps it is better to simply use &q= uot;standards fora."

 =

    =      >>

 =

    =      >> I'm not against just saying organization = too.  I don't want to get

 =

    =      >> in to arguments about what's an SDO and w= hat's not.

 =

    =      >>

 =

    =      >> spt

 =

    =      >>

 =

    =      >>> You should consider including: NIST, = MITRE, and 3GPP - all of

 =

    =      >>> which are well recognized as key stan= dards bodies currently

 =

    =      >>> engaged in SACM related work with who= m you should be interested now.

 =

    =      >>>

 =

    =      >>> -t

 =

    =      >>>

 =

    =      >>> On 6/24/2013 11:52 AM, Adam Montville= wrote:

 =

    =      >>>> There are a variety of other SDOs= in which we could be interested

 =

    =      >>>> now or in the future.  = The short-story list:

 =

    =      >>>>

 =

    =      >>>> * FIRST (vulnerability scoring)

 =

    =      >>>> * DMTF (already mentioned)

 =

    =      >>>> * TCG (already mentioned)

 =

    =      >>>> * The Open Group (XDAS and others= )

 =

    =      >>>> * ISO (i.e. TagVault)<= /span>

 =

    =      >>>> * W3C (i.e. obvious things like X= ML DigSig, and potentially less

 =

    =      >>>> obvious things like RDF, OWL, SWR= L, etc.)

 =

    =      >>>> * OASIS (i.e. security assertions= , key management, alerting)

 =

    =      >>>> * OMG (i.e. Business Process Mode= l Notation and/or Execution

 =

    =      >>>> Language,

 =

    =      >>>> etc.)

 =

    =      >>>

 =

    =      >>>

 =

    =      >> _________________________________________= ______

 =

    =      >> sacm mailing list

 =

    =      >>sacm@ietf= .org <mailto:sacm@ietf.org><= o:p>

 =

 =

    =      > _____________________________________________= __

 =

    =      > sacm mailing list

 =

    =      >sacm@ietf.org= <mailto:sacm@ietf.org>=

 =

 =

    =      >

 =

    = _______________________________________________

 =

    = sacm mailing list

 =

 =

 =

    = _______________________________________________

 =

    = sacm mailing list

 =

 =

 =

    = ...

 =

    = 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 not= ify

    = the sender immediately and permanently delete the message and any

    = attachments.

 =

    = _______________________________________________

 =

    = sacm mailing list

 =

 =

 =

________________________= _______________________

sacm mailing list

 =

--_000_3CBA099FBA0AB843895D72474092B8CF2B6C55MIVEXAMER1N1corpn_-- From david.waltermire@nist.gov Wed Jun 26 06:02:18 2013 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 9645211E81BF for ; Wed, 26 Jun 2013 06:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[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 oLqKWK1oRZqB for ; Wed, 26 Jun 2013 06:02:13 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id C83E111E81AB for ; Wed, 26 Jun 2013 06:02:11 -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.3.123.3; Wed, 26 Jun 2013 09:01:50 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 26 Jun 2013 09:02:07 -0400 From: "Waltermire, David A." To: "Kent_Landfield@McAfee.com" , "turners@ieca.com" , "sacm@ietf.org" Date: Wed, 26 Jun 2013 09:02:06 -0400 Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhuvQoRthgPdUqZE3J5Z9Ln/5lFMPAAgAACywCAABNbgIAAD2wAgABpioCAAJdzAIAATgCAgAAInQCAAAcIAIAAGcIAgAAkFID//+MmAIABGvGAgAA4vYCAACVpgP//nCbwgABtXID//5wewA== Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.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_D7A0423E5E193F40BE6E94126930C4930C0732458AMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:02:18 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930C0732458AMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" I mentioned this work because it does align with some of the tentative requirements and use cases that have been floated. There is a potential for liaison with these orgs. Even for the NIST and MITRE work, we have options to reference it in place or bring the work in. You could say the same thing for TCG and OpenGroup efforts. It is too early to decide one way or another right now as we still have work to do on the use cases, requirements, and architecture documents. The determining factor will be if changes need to be made to the existing work and if the orgs are willing to make a contribution. If it is referenced, this will drive the liaison decision. If the work needs to brought in, then all of what you said about IPR would apply. Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:45 AM To: Waltermire, David A.; turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review Hi Dave, I assumed that MILE and NEA were already identified from charter references and was looking at only organizations external to the IETF. Individuals from the organizations I listed either are or have had active discussions to contribute to the proposed WG. I am not sure initially we are talking about TCG related work. Yes, it could be possible but that is up to the TCG to contribute their work into the group as a proposal. Same for O-ACEML. Those proposals need to fit the proposed charter and be made to the working group itself. If they are making proposals for work items to the SACM WG then they would be following the IETF IPR rules for documents contributed. The key here is that the work would be done in SACM and should not be duplicating work elsewhere. I guess I need clarity from Sean. I was looking at what organizations would be directly working with the SACM initially. Liaison or otherwise. I fully expect we would invite others to participate in SACM. I personally plan on trying to assure all are aware of the SACM efforts and goals. Developing a list of who to invite is different from the perspective I responded with. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Wednesday, June 26, 2013 2:23 PM To: Kent Landfield >, Sean Turner >, "sacm@ietf.org" > Subject: RE: [sacm] sacm charter review We may want to bring in updates of the existing NEA protocols and/or new work created within the TCG. We may also want to consider O-ACEML from the OpenGroup. These have been discussed as options on the list and during the BoFs. Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:11 AM To: turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review >From my perspective the initial organizations we will be dealing with are - ISO/IEC - NIST - MITRE Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 1:56 PM To: "sacm@ietf.org" > Subject: Re: [sacm] sacm charter review It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: Yes. The fact that other organizations are interested in the scope of SACM does not mean that they do the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to refer or document these in An Informational RFC, but this is not a mandatory deliverable. The working group will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. Regards, Dan *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, June 25, 2013 6:41 PM *To:* Kent_Landfield@McAfee.com; Adam.Montville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com *Sent:* Tuesday, June 25, 2013 8:24 AM *To:* Adam.Montville@cisecurity.org ; dbharrington@comcast.net ; turners@ieca.com ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *Adam Montville > *Date: *Tuesday, June 25, 2013 5:15 PM *To: *David Harrington >, Sean Turner >, "sacm@ietf.org " > *Subject: *Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org ] on behalf of David Harrington [dbharrington@comcast.net ] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org ; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com ; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaison > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From:sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To:tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >>sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF as a >>> "SDO!" >>>http://www.tta.or.kr/English/new/external_relations/gsc17_communiq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be interested now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be interested >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially less >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ 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_D7A0423E5E193F40BE6E94126930C4930C0732458AMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFu O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgbWVudGlvbmVk IHRoaXMgd29yayBiZWNhdXNlIGl0IGRvZXMgYWxpZ24gd2l0aCBzb21lIG9mIHRoZSB0ZW50YXRp dmUgcmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgdGhhdCBoYXZlIGJlZW4gZmxvYXRlZC4mbmJz cDsgVGhlcmUgaXMgYSBwb3RlbnRpYWwgZm9yIGxpYWlzb24gd2l0aCB0aGVzZSBvcmdzLiBFdmVu IGZvciB0aGUgTklTVCBhbmQgTUlUUkUgd29yaywgd2UgaGF2ZSBvcHRpb25zIHRvIHJlZmVyZW5j ZSBpdCBpbiBwbGFjZSBvciBicmluZyB0aGUgd29yayBpbi4mbmJzcDsgWW91IGNvdWxkIHNheSB0 aGUgc2FtZSB0aGluZyBmb3IgVENHIGFuZCBPcGVuR3JvdXAgZWZmb3J0cy4mbmJzcDsgSXQgaXMg dG9vIGVhcmx5IHRvIGRlY2lkZSBvbmUgd2F5IG9yIGFub3RoZXIgcmlnaHQgbm93IGFzIHdlIHN0 aWxsIGhhdmUgd29yayB0byBkbyBvbiB0aGUgdXNlIGNhc2VzLCByZXF1aXJlbWVudHMsIGFuZCBh cmNoaXRlY3R1cmUgZG9jdW1lbnRzLiBUaGUgZGV0ZXJtaW5pbmcgZmFjdG9yIHdpbGwgYmUgaWYg Y2hhbmdlcyBuZWVkIHRvIGJlIG1hZGUgdG8gdGhlIGV4aXN0aW5nIHdvcmsgYW5kIGlmIHRoZSBv cmdzIGFyZSB3aWxsaW5nIHRvIG1ha2UgYSBjb250cmlidXRpb24uIElmIGl0IGlzIHJlZmVyZW5j ZWQsIHRoaXMgd2lsbCBkcml2ZSB0aGUgbGlhaXNvbiBkZWNpc2lvbi4gSWYgdGhlIHdvcmsgbmVl ZHMgdG8gYnJvdWdodCBpbiwgdGhlbiBhbGwgb2Ygd2hhdCB5b3Ugc2FpZCBhYm91dCBJUFIgd291 bGQgYXBwbHkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmdd IDxiPk9uIEJlaGFsZiBPZiA8L2I+S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTxicj48Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDI2LCAyMDEzIDg6NDUgQU08YnI+PGI+VG86PC9iPiBXYWx0 ZXJtaXJlLCBEYXZpZCBBLjsgdHVybmVyc0BpZWNhLmNvbTsgc2FjbUBpZXRmLm9yZzxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBzYWNtIGNoYXJ0ZXIgcmV2aWV3PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ SGkgRGF2ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5J IGFzc3VtZWQgdGhhdCBNSUxFIGFuZCBORUEgd2VyZSBhbHJlYWR5IGlkZW50aWZpZWQgZnJvbSBj aGFydGVyIHJlZmVyZW5jZXMgYW5kIHdhcyBsb29raW5nIGF0IG9ubHkgb3JnYW5pemF0aW9ucyBl eHRlcm5hbCB0byB0aGUgSUVURi4gSW5kaXZpZHVhbHMgZnJvbSB0aGUgb3JnYW5pemF0aW9ucyBJ IGxpc3RlZCBlaXRoZXIgYXJlIG9yIGhhdmUgaGFkIGFjdGl2ZSBkaXNjdXNzaW9ucyB0byBjb250 cmlidXRlIHRvIHRoZSBwcm9wb3NlZCBXRy4gJm5ic3A7SSBhbSBub3Qgc3VyZSBpbml0aWFsbHkg d2UgYXJlIHRhbGtpbmcgYWJvdXQgVENHIHJlbGF0ZWQgd29yay4gWWVzLCBpdCBjb3VsZCBiZSBw b3NzaWJsZSBidXQgdGhhdCBpcyB1cCB0byB0aGUgVENHIHRvIGNvbnRyaWJ1dGUgdGhlaXIgd29y ayBpbnRvIHRoZSBncm91cCBhcyBhIHByb3Bvc2FsLiBTYW1lIGZvciBPLUFDRU1MLiBUaG9zZSBw cm9wb3NhbHMgbmVlZCB0byBmaXQgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYW5kIGJlIG1hZGUgdG8g dGhlIHdvcmtpbmcgZ3JvdXAgaXRzZWxmLiAmbmJzcDtJZiB0aGV5IGFyZSBtYWtpbmcgcHJvcG9z YWxzIGZvciB3b3JrIGl0ZW1zIHRvIHRoZSBTQUNNIFdHIHRoZW4gdGhleSB3b3VsZCBiZSBmb2xs b3dpbmcgdGhlIElFVEYgSVBSIHJ1bGVzIGZvciBkb2N1bWVudHMgY29udHJpYnV0ZWQuIFRoZSBr ZXkgaGVyZSBpcyB0aGF0IHRoZSB3b3JrIHdvdWxkIGJlIGRvbmUgaW4gU0FDTSBhbmQgc2hvdWxk IG5vdCBiZSBkdXBsaWNhdGluZyB3b3JrIGVsc2V3aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JIGd1ZXNzIEkgbmVlZCBjbGFyaXR5IGZyb20gU2Vh bi4gJm5ic3A7SSB3YXMgbG9va2luZyBhdCB3aGF0IG9yZ2FuaXphdGlvbnMgd291bGQgYmUgZGly ZWN0bHkgd29ya2luZyB3aXRoIHRoZSBTQUNNIGluaXRpYWxseS4gTGlhaXNvbiBvciBvdGhlcndp c2UuIEkgZnVsbHkgZXhwZWN0IHdlIHdvdWxkIGludml0ZSBvdGhlcnMgdG8gcGFydGljaXBhdGUg aW4gU0FDTS4gJm5ic3A7SSBwZXJzb25hbGx5IHBsYW4gb24gdHJ5aW5nIHRvIGFzc3VyZSBhbGwg YXJlIGF3YXJlIG9mIHRoZSBTQUNNIGVmZm9ydHMgYW5kIGdvYWxzLiAmbmJzcDtEZXZlbG9waW5n IGEgbGlzdCBvZiB3aG8gdG8gaW52aXRlIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBwZXJzcGVjdGl2 ZSBJIHJlc3BvbmRlZCB3aXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Ryb25nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzYwNkE3MSc+S2VudCBMYW5kZmllbGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjA2 QTcxJz48YnI+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz5NY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55PC9zcGFuPjwvc3Ryb25nPjxicj48 c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPkRpcmVjdDogKzEuOTcyLjk2My43MDk2Jm5ic3A7 PC9zcGFuPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPk1vYmlsZTogKzEuODE3LjYz Ny44MDI2PC9zcGFuPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+V2ViOiZuYnNwOzwvc3Bhbj48L3N0cm9uZz48c3BhbiBjbGFzcz1hcHBs ZS1zdHlsZS1zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cubWNhZmVlLmNvbS8iPnd3dy5tY2FmZWUu Y29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZsdDtXYWx0ZXJtaXJl Jmd0OywgRGF2aWQgV2FsdGVybWlyZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLndhbHRlcm1p cmVAbmlzdC5nb3YiPmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8L2E+Jmd0Ozxicj48Yj5EYXRl OiA8L2I+V2VkbmVzZGF5LCBKdW5lIDI2LCAyMDEzIDI6MjMgUE08YnI+PGI+VG86IDwvYj5LZW50 IExhbmRmaWVsZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb20i PktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb208L2E+Jmd0OywgU2VhbiBUdXJuZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIj50dXJuZXJzQGllY2EuY29tPC9hPiZndDssICZx dW90OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+Jmd0 Ozxicj48Yj5TdWJqZWN0OiA8L2I+UkU6IFtzYWNtXSBzYWNtIGNoYXJ0ZXIgcmV2aWV3PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1 b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDow aW4nIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgbWF5IHdhbnQgdG8gYnJp bmcgaW4gdXBkYXRlcyBvZiB0aGUgZXhpc3RpbmcgTkVBIHByb3RvY29scyBhbmQvb3IgbmV3IHdv cmsgY3JlYXRlZCB3aXRoaW4gdGhlIFRDRy4mbmJzcDsgV2UgbWF5IGFsc28gd2FudCB0byBjb25z aWRlciBPLUFDRU1MIGZyb20gdGhlIE9wZW5Hcm91cC4gVGhlc2UgaGF2ZSBiZWVuIGRpc2N1c3Nl ZCBhcyBvcHRpb25zIG9uIHRoZSBsaXN0IGFuZCBkdXJpbmcgdGhlIEJvRnMuPC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5EYXZlPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiA8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGll dGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86c2FjbS1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24g QmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbSI+ S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbTwvYT48YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SnVuZSAyNiwgMjAxMyA4OjExIEFNPGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnR1cm5l cnNAaWVjYS5jb20iPnR1cm5lcnNAaWVjYS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2FjbUBp ZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbc2FjbV0g c2FjbSBjaGFydGVyIHJldmlldzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkZyb20gbXkgcGVyc3Bl Y3RpdmUgdGhlIGluaXRpYWwgb3JnYW5pemF0aW9ucyB3ZSB3aWxsIGJlIGRlYWxpbmcgd2l0aCBh cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLSBJU08vSUVDPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gTklTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtIE1JVFJFPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJvbmc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojNjA2QTcxJz5LZW50IExhbmRmaWVsZDwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiM2MDZBNzEnPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwvc3Bh bj48L3N0cm9uZz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5EaXJlY3Q6ICsxLjk3 Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5N b2JpbGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjombmJzcDs8L3NwYW4+PC9zdHJvbmc+ PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3Lm1jYWZlZS5j b20vIj53d3cubWNhZmVlLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5TZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR1cm5lcnNAaWVjYS5jb20iPnR1cm5l cnNAaWVjYS5jb208L2E+Jmd0Ozxicj48Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdW5lIDI2LCAy MDEzIDE6NTYgUE08YnI+PGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRm Lm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGll dGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiZndDs8YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbc2Fj bV0gc2FjbSBjaGFydGVyIHJldmlldzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48Ymxv Y2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkl0IGxvb2tzIGxpa2UgSm9lbCB3YW50cyB0 byBrbm93IG5vdyBzb21lIG9mIHRoZSBvcmdhbml6YXRpb25zIChpLmUuLCA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz50aGVyZSdzIGJsb2NrIG9uIHRoZSBjaGFydGVyKS4mbmJzcDsmbmJzcDtDYW4gd2Ug d2hpdHRsZSB0aGlzIGxpc3QgZG93biB0byBqdXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPm9yZ3Mg d2UncmUgZ29pbmcgdG8gYmUgZGVhbGluZyB3aXRoIGF0IHRoZSBpbml0aWFsIHN0YWdlcz8mbmJz cDsmbmJzcDtGb3IgYXNzZXQgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+aWRlbnRpZmljYXRpb24gaXQn cyBwb3NzaWJseSBnb2luZyB0byBiZSBJU08rTklTVCs/LCBmb3IgZW5kcG9pbnQgPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+ZWxlbWVudHMgdG8gYXNzZXNzIGl0J3MgPywgZm9yIGNvbXBhcmlzb24gaXQn cyA/LCBmb3IgaW50ZXJhY3Rpbmcgd2l0aCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5yZXBvc2l0b3Jp ZXMgaXQncyBORUEuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+TW9yZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+T24gNi8yNi8xMyA0OjMzIEFNLCBSb21hc2NhbnUsIERhbiAoRGFuKSB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQnIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlllcy4gVGhl IGZhY3QgdGhhdCBvdGhlciBvcmdhbml6YXRpb25zIGFyZSBpbnRlcmVzdGVkIGluIHRoZSBzY29w ZSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlNBQ00gZG9lcyBub3QgbWVhbiB0aGF0IHRoZXkgZG8g dGhlIHNhbWUgd29yaywgYW5kIGNlcnRhaW5seSB0aGUgZnV0dXJlPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+V0cgbXVzdCBhdm9pZCBkdXBsaWNhdGlvbi4gTWF5YmUgd2Ugc2hvdWxkIG1ha2UgdGhpcyBl eHBsaWNpdC4gRm9yIGV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY3JlYXRlIGFuIG92ZXJ2aWV3IG9mIHJlbGF0 ZWQgc3RhbmRhcmRzIHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5JbnRlcm5ldC1EcmFmdCB3aGljaCB3aWxsIGRvY3VtZW50IGV4aXN0aW5nIHdvcmsg aW4gdGhlIElFVEYgb3IgaW4gb3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TRE9zPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+d2hpY2ggY2FuIGJlIHVzZWQg YXMtaXMgb3IgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgZGV2ZWxvcGluZyBzb2x1dGlvbnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz50byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5TQUNNIHJlcXVpcmVtZW50cy4gVGhlIHdvcmtpbmcgZ3JvdXAgbWF5IGRl Y2lkZSB0byBtYWtlIG9mIHRoaXMgZG9jdW1lbnQgYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JbmZvcm1hdGlvbmFsIFJGQywgYnV0IHRoaXMgaXMgbm90 IGEgbWFuZGF0b3J5IGRlbGl2ZXJhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz5UaGUgd29ya2luZyBncm91cCB3aWxsIGNyZWF0ZSBhbiBvdmVydmlldyBvZiBy ZWxhdGVkIHN0YW5kYXJkcyB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+SW50ZXJuZXQtRHJhZnQgd2hpY2ggd2lsbCBkb2N1bWVudCBleGlzdGluZyB3 b3JrIGluIHRoZSBJRVRGIG9yIGluIG90aGVyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U0RPczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPndoaWNoIGNhbiBiZSB1 c2VkIGFzLWlzIG9yIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGRldmVsb3Bpbmcgc29sdXRpb25z PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+dG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+U0FDTSByZXF1aXJlbWVudHMuIFRoZSB3b3JraW5nIGdyb3VwIG1h eSBkZWNpZGUgdG8gcmVmZXIgb3IgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz50aGVzZSBp bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkFuIEluZm9y bWF0aW9uYWwgUkZDLCBidXQgdGhpcyBpcyBub3QgYSBtYW5kYXRvcnkgZGVsaXZlcmFibGUuIFRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPndvcmtpbmcgZ3JvdXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz53aWxsIG5vdCBkdXBsaWNhdGUgd29yayBhbHJlYWR5 IGRvbmUgb3IgaW4gcHJvZ3Jlc3MgaW4gb3RoZXIgcGxhY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5XZSB3ZXJlIG9uIHRoZSBz YW1lIHdhdmVsZW5ndGguJm5ic3A7Jm5ic3A7SSdtIG5vdCBzdXJlIHdlIG5lZWQgdG8gcmVwZWF0 ZWQgdGhlIHdlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPndvbid0IGR1cGxpY2F0ZSB3b3JrIGJlY2F1 c2UgdGhlcmUncyBhbHJlYWR5IGEgYmx1cmIgYWJvdXQgcmV1c2UuJm5ic3A7Jm5ic3A7V2hhdCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5JIHByb3Bvc2VkIHRvIEJhcnJ5L0pvZWwvU3BlbmNlcjo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5PTEQ6PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBjcmVhdGUgYW4gb3ZlcnZpZXcgb2YgcmVsYXRlZCBzdGFuZGFyZHMgd29yayA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5JbnRlcm5ldC1EcmFmdCB3aGljaCB3aWxsIGRvY3VtZW50IGV4aXN0aW5n IHdvcmsgaW4gdGhlIElFVEYgb3IgaW4gb3RoZXIgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U0RPcyB3 aGljaCBjYW4gYmUgdXNlZCBhcy1pcyBvciBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciBkZXZlbG9w aW5nIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnNvbHV0aW9ucyB0byB0aGUgU0FDTSByZXF1aXJlbWVu dHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+TkVXOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoZSB3b3JraW5n IGdyb3VwIHdpbGwgY3JlYXRlIGFuIEludGVybmV0LURyYWZ0IGRvY3VtZW50aW5nIHRoZSBleGlz dGluZyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz53b3JrIGluIHRoZSBJRVRGIGFuZCBpbiBvdGhlciBv cmdhbml6YXRpb25zIHRoYXQgbWlnaHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5iZSB1c2VkIGFzLWlz IG9yIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGRldmVsb3Bpbmcgc29sdXRpb25zIHRvPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+dGhlIFNBQ00gcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JbiBhY2NvcmRhbmNlIHdpdGggZXhpc3RpbmcgSUVURiBw cm9jZXNzZXMsIHRoZSBncm91cCB3aWxsIGNvbW11bmljYXRlIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PndpdGggYW5kIGludml0ZSBwYXJ0aWNpcGF0aW9uIGZyb20gb3RoZXIgcmVsZXZhbnQgc3RhbmRh cmRzIGJvZGllcyBhbmQgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+cmVndWxhdG9yeSBvcmdhbml6YXRp b25zLCBhbmQgaWYgbmVjZXNzYXJ5IHJldXNlIGV4aXN0aW5nIGxpYWlzb24gPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+cmVsYXRpb25zaGlwcyBvciByZXF1ZXN0IHRoZSBlc3RhYmxpc2htZW50IG9mIG5l dyBsaWFpc29uIHJlbGF0aW9uc2hpcHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPkluIGFjY29yZGFuY2Ugd2l0aCBleGlzdGluZyBJRVRGIHByb2Nlc3NlcywgdGhl IHdvcmtpbmcgZ3JvdXAgd2lsbCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5jb21tdW5pY2F0ZSB3aXRo IGFuZCBpbnZpdGUgcGFydGljaXBhdGlvbiBmcm9tIG90aGVyIHJlbGV2YW50IGdyb3VwcyBhbmQg PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+cmVndWxhdG9yeSBvcmdhbml6YXRpb25zLCBhbmQgaWYgbmVj ZXNzYXJ5IHJldXNlIGV4aXN0aW5nIGxpYWlzb24gPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+cmVsYXRp b25zaGlwcyBvciByZXF1ZXN0IHRoZSBlc3RhYmxpc2htZW50IG9mIG5ldyBsaWFpc29uIHJlbGF0 aW9uc2hpcHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0JyBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSI+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PkRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPipGcm9t OjxhIGhyZWY9Im1haWx0bzoqc2FjbS1ib3VuY2VzQGlldGYub3JnIj4qc2FjbS1ib3VuY2VzQGll dGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5PZiAqTWljaGFlbCBIYW1tZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4qU2VudDoqIFR1ZXNkYXks IEp1bmUgMjUsIDIwMTMgNjo0MSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPipUbzoqIDxhIGhyZWY9 Im1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tIj5LZW50X0xhbmRmaWVsZEBNY0FmZWUu Y29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOkFkYW0uTW9udHZpbGxlQGNpc2VjdXJpdHkub3JnIj5B ZGFtLk1vbnR2aWxsZUBjaXNlY3VyaXR5Lm9yZzwvYT47PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGEg aHJlZj0ibWFpbHRvOmRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCI+ZGJoYXJyaW5ndG9uQGNvbWNh c3QubmV0PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnR1cm5lcnNAaWVjYS5jb20iPnR1cm5lcnNAaWVj YS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4qU3ViamVjdDoqIFJlOiBbc2FjbV0gc2FjbSBjaGFydGVy IHJldmlldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPisx Jm5ic3A7Jm5ic3A7VGhpcyBqdXN0IG1lYW5zIG1hbnkgZ3JvdXBzIGFyZSBpbnRlcmVzdGVkIGlu IHRoZSBzYW1lIHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPk1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4qRnJvbTo8YSBocmVmPSJtYWlsdG86KnNhY20tYm91bmNlc0BpZXRmLm9yZyI+KnNhY20tYm91 bmNlc0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5v cmciPm1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPls8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1i b3VuY2VzQGlldGYub3JnPC9hPl0gKk9uIEJlaGFsZiBPZiA8YSBocmVmPSJtYWlsdG86KktlbnRf TGFuZGZpZWxkQE1jQWZlZS5jb20iPipLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZsdDs8YSBocmVmPSJtYWlsdG86S2VudF9MYW5kZmllbGRATWNBZmVl LmNvbSI+bWFpbHRvOktlbnRfTGFuZGZpZWxkQE1jQWZlZS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPipTZW50OiogVHVlc2RheSwgSnVuZSAyNSwgMjAxMyA4OjI0IEFNPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+KlRvOiogPGEgaHJlZj0ibWFpbHRvOkFkYW0uTW9udHZpbGxlQGNpc2VjdXJp dHkub3JnIj5BZGFtLk1vbnR2aWxsZUBjaXNlY3VyaXR5Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbHQ7PGEgaHJlZj0ibWFpbHRvOkFkYW0uTW9udHZpbGxlQGNpc2VjdXJpdHkub3JnIj5t YWlsdG86QWRhbS5Nb250dmlsbGVAY2lzZWN1cml0eS5vcmc8L2E+Jmd0OzsgPGEgaHJlZj0ibWFp bHRvOmRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldCI+ZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZsdDs8YSBocmVmPSJtYWlsdG86ZGJoYXJyaW5ndG9uQGNv bWNhc3QubmV0Ij5tYWlsdG86ZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0PC9hPiZndDs7IDxhIGhy ZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIj50dXJuZXJzQGllY2EuY29tPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZsdDs8YSBocmVmPSJtYWlsdG86dHVybmVyc0BpZWNhLmNvbSI+bWFpbHRv OnR1cm5lcnNAaWVjYS5jb208L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmci PnNhY21AaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+bWFp bHRvOnNhY21AaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPipTdWJqZWN0Oiog UmU6IFtzYWNtXSBzYWNtIGNoYXJ0ZXIgcmV2aWV3PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+V2VsbCBzYWlkIEFkYW0uIEkgdG90YWxseSBhZ3JlZSB3aXRo IHlvdXIgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+KktlbnQgTGFuZGZpZWxkKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPipNY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55KjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPkRpcmVjdDogKzEuOTcyLjk2My43MDk2PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+TW9iaWxlOiAr MS44MTcuNjM3LjgwMjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4qV2ViOiAqd3d3Lm1jYWZlZS5jb20g Jmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cubWNhZmVlLmNvbS8iPmh0dHA6Ly93d3cubWNhZmVlLmNv bS88L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PipGcm9tOiAqQWRhbSBNb250dmlsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpBZGFtLk1vbnR2aWxs ZUBjaXNlY3VyaXR5Lm9yZyI+QWRhbS5Nb250dmlsbGVAY2lzZWN1cml0eS5vcmc8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jmx0OzxhIGhyZWY9Im1haWx0bzpBZGFtLk1vbnR2aWxsZUBjaXNlY3Vy aXR5Lm9yZyUzZSI+bWFpbHRvOkFkYW0uTW9udHZpbGxlQGNpc2VjdXJpdHkub3JnJmd0OzwvYT4m Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+KkRhdGU6ICpUdWVzZGF5LCBKdW5lIDI1LCAyMDEzIDU6 MTUgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4qVG86ICpEYXZpZCBIYXJyaW5ndG9uICZsdDs8YSBo cmVmPSJtYWlsdG86ZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0Ij5kYmhhcnJpbmd0b25AY29tY2Fz dC5uZXQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmx0OzxhIGhyZWY9Im1haWx0bzpkYmhhcnJp bmd0b25AY29tY2FzdC5uZXQlM2UiPm1haWx0bzpkYmhhcnJpbmd0b25AY29tY2FzdC5uZXQmZ3Q7 PC9hPiZndDssIFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWlsdG86dHVybmVyc0BpZWNhLmNv bSI+dHVybmVyc0BpZWNhLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbHQ7PGEgaHJlZj0i bWFpbHRvOnR1cm5lcnNAaWVjYS5jb20lM2UiPm1haWx0bzp0dXJuZXJzQGllY2EuY29tJmd0Ozwv YT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnJTNlIj5tYWlsdG86c2FjbUBp ZXRmLm9yZyZndDs8L2E+JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jmx0OzxhIGhyZWY9Im1h aWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNhY21AaWV0Zi5vcmclM2UiPm1haWx0bzpzYWNtQGlldGYub3JnJmd0OzwvYT4mZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+KlN1YmplY3Q6ICpSZTogW3NhY21dIHNhY20gY2hhcnRlciByZXZpZXc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSGkgRGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgcmVzcGVjdGZ1bGx5IGRp c2FncmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGlsZSB0aGlzIG1heSBiZSBhIGNvbW1lbnRhcnkgb24g dGhlIHBvdGVudGlhbCwgZXZlbnR1YWwgcmVhY2ggb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU0FDTSwgb3VyIGNoYXJ0ZXIncyBzY29wZSBpcyBmYXIgcmVk dWNlZCBmcm9tIGluY2x1ZGluZyBhbGwgb2YgdGhlc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgb3JnYW5pemF0aW9ucyBhdCB0aGUgb3V0c2V0LiZuYnNwOyZu YnNwO0luIG90aGVyIHdvcmRzLCBvdXIgc2NvcGUgaXMgbGltaXRlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBieSB0aGUgbGFuZ3VhZ2UgaW4gdGhlIGNoYXJ0 ZXIsIGFnYWluc3Qgd2hpY2ggdGhpcyBsaXN0IHJlYWxseSBoYXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8gYmVhcmluZyBvdGhlciB0aGFuIHRvIHNhdGlz ZnkgY3VyaW9zaXR5IGFuZCwgcGVyaGFwcywgbGVuZCBzb21lPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZpc2lvbiB0byB0aGUgZnV0dXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJbiBmYWN0LCBpdCBtaWdodCBiZSBtb3JlIHByb3Blcmx5IGNvbnN0cnVlZCB0aGF0IHRo aXMgbGlzdCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBv cmdhbml6YXRpb25zIGlzIGEgY29tbWVudGFyeSBvbiB0aGUgdWJpcXVpdG91cyBuYXR1cmUgb2Yg YXNzZXNzbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt IGl0IGlzIGEgY2FwYWJpbGl0eSB0aGF0ICZxdW90O3RvdWNoZXMmcXVvdDsgYSBsb3Qgb2YgZGlm ZmVyZW50IGFyZWFzLCB3aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpcyBwcmVjaXNlbHkgd2h5IGl0IHdhcnJhbnRzIGl0cyBvd24gd29ya2luZyBncm91 cCwgSU1PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBZGFtPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyI+c2Fj bS1ib3VuY2VzQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJtYWlsdG86c2FjbS1i b3VuY2VzQGlldGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnJTNlIj5tYWlsdG86c2FjbS1ib3VuY2VzQGlldGYu b3JnJmd0OzwvYT5dIG9uIGJlaGFsZiBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBEYXZpZCBIYXJyaW5ndG9uIFs8YSBocmVmPSJtYWlsdG86ZGJoYXJyaW5n dG9uQGNvbWNhc3QubmV0Ij5kYmhhcnJpbmd0b25AY29tY2FzdC5uZXQ8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGJo YXJyaW5ndG9uQGNvbWNhc3QubmV0JTNlIj5tYWlsdG86ZGJoYXJyaW5ndG9uQGNvbWNhc3QubmV0 Jmd0OzwvYT5dPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMjUsIDIwMTMgNjo0 MyBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUbzogJ1NlYW4gVHVybmVyJzsgPGEgaHJlZj0ibWFpbHRvOnNh Y21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBp ZXRmLm9yZyI+bWFpbHRvOnNhY21AaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdWJq ZWN0OiBSZTogW3NhY21dIHNhY20gY2hhcnRlciByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV293ITxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJIHRoaW5rIHRoaXMgaXMgYW4gZXhjZWxsZW50IGNvbW1lbnRhcnkgb24g dGhlIHNjb3BlIG9mIFNBQ00gYmVpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgd2F5IHRvbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBicm9hZCwgYW5kIHBvb3JseSBzY29w ZWQgZm9yIGVuZ2luZWVyaW5nIHB1cnBvc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXZpZCBIYXJyaW5n dG9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpkYmhhcnJpbmd0b25AY29tY2FzdC5u ZXQiPmRiaGFycmluZ3RvbkBjb21jYXN0Lm5ldDwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpkYmhh cnJpbmd0b25AY29tY2FzdC5uZXQiPm1haWx0bzpkYmhhcnJpbmd0b25AY29tY2FzdC5uZXQ8L2E+ Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyArMS02MDMtODI4LTE0MDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRnJvbTogPGEgaHJlZj0ibWFpbHRv OnNhY20tYm91bmNlc0BpZXRmLm9yZyI+c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNhY20tYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFs8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1i b3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbWFzY2Fu dSwgRGFuIChEYW4pPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMjUsIDIwMTMg OToxOCBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUbzogU2VhbiBUdXJuZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2M6 IE1vcmlhcnR5LCBLYXRobGVlbjsgU3RlcGhlbiBIYW5uYTsgQWRhbSBNb250dmlsbGU7IDxhIGhy ZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhY21A aWV0Zi5vcmciPm1haWx0bzpzYWNtQGlldGYub3JnPC9hPiZndDs7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Im1haWx0bzp0b255QHlhYW5hdGVjaC5jb20iPnRvbnlAeWFhbmF0ZWNoLmNvbTwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzp0b255QHlhYW5hdGVjaC5jb20iPm1haWx0bzp0b255QHlhYW5h dGVjaC5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdWJqZWN0OiBSZTogW3NhY21dIHNhY20g Y2hhcnRlciByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSGkgU2Vhbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBs aXN0IG9mIG9yZ2FuaXphdGlvbnMgdGhhdCBhcmUgaW52b2x2ZWQgaW4gdGhlIGFyZWEsIGFzIGlk ZW50aWZpZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4g dGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBkaXNjdXNzaW9uIGluY2x1ZGVzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt IFRDRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtIERNVEY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBGSVJTVDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtIFRoZSBPcGVuIEdyb3VwPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gSVNPL0lFQzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtIFczQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE9BU0lTPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gT01H PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gTklTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE1JVFJFPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0gM0dQUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJdCdzIHVwIHRvIHRoZSBJRVNHIHRvIGRlY2lkZSBp ZiB3ZSBzaG91bGQgbGlzdCB0aGVzZSAob3Igc29tZSBvZiB0aGVtKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBl eHBsaWNpdGx5LCBvciB3ZSBzaG91bGQgbGVhdmUgdG8gdGhlIFdHIGFmdGVyIGl0cyBmb3JtYXRp b24gaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwcm92 ZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5pdGlhdGUgY29tbXVuaWNhdGlvbiBhbmQgaW52aXRlIHBh cnRpY2lwYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGcm9tOiBTZWFu IFR1cm5lciBbPGEgaHJlZj0ibWFpbHRvOnR1cm5lcnNAaWVjYS5jb20iPm1haWx0bzp0dXJuZXJz QGllY2EuY29tPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2Vu dDogVHVlc2RheSwgSnVuZSAyNSwgMjAxMyAzOjQ3IFBNPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRvOiBSb21hc2NhbnUsIERhbiAoRGFuKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYzogPGEgaHJlZj0ibWFpbHRvOnRvbnlAeWFhbmF0ZWNo LmNvbSI+dG9ueUB5YWFuYXRlY2guY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnlAeWFh bmF0ZWNoLmNvbSI+bWFpbHRvOnRvbnlAeWFhbmF0ZWNoLmNvbTwvYT4mZ3Q7OyBBZGFtPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE1vbnR2aWxsZTsgU3RlcGhlbiBIYW5uYTsgTW9yaWFydHksPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEthdGhsZWVuOyA8YSBocmVmPSJtYWlsdG86c2FjbUBp ZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYu b3JnIj5tYWlsdG86c2FjbUBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IFJlOiBbc2FjbV0gc2FjbSBjaGFydGVyIHJldmlldzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdCB0aGlzIHBvaW50IDMgQURz IGhhdmUgYXNrZWQgYWJvdXQgd2hhdCBvdGhlciBTRE9zIGFyZSBpbnZvbHZlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSdtIG5vdCBzdXJlIGlmIHRoZXkgd2FudCBu YW1lcyBpbiB0aGUgY2hhcnRlciBvciBpZiB0aGV5J3JlIGp1c3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJlc3RlZCBpbiBrbm93aW5nLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT24gNi8yNS8xMyA0OjA3IEFNLCBSb21hc2NhbnUsIERhbiAoRGFuKSB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBUaGUgcHJvcG9z ZWQgdGV4dCBpbiB0aGUgY2hhcnRlciBhbHJlYWR5IHNheXM6PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsgSW4gYWNjb3JkYW5jZSB3aXRoIGV4aXN0aW5nIElFVEYgcHJvY2Vzc2Vz LCB0aGUgZ3JvdXAgd2lsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyBjb21tdW5pY2F0ZSB3aXRoIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IGludml0ZSBwYXJ0aWNpcGF0aW9uIGZyb20gb3RoZXIgcmVsZXZhbnQg c3RhbmRhcmRzIGJvZGllcyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyByZWd1bGF0b3J5IG9yZ2FuaXphdGlvbnMsIGFuZCBpZiBuZWNlc3NhcnkgcmV1c2Ug ZXhpc3RpbmcgbGlhaXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IHJlbGF0aW9uc2hpcHMgb3IgcmVxdWVzdCB0aGUgZXN0YWJsaXNobWVudCBvZiBuZXcgbGlh aXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWxhdGlvbnNoaXBz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJ3N0YW5kYXJkIGJvZGllcyBhbmQgcmVn dWxhdG9yeSBvcmdhbml6YXRpb25zJyBhcmUgbmV1dHJhbCB0ZXJtczxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbm91Z2ggSU1PLCBhcyBTZWFuIHNheXMgd2Ugc2hvdWxk IG5vdCBlbnRlciB0aGUgJ3doYXQgaXMgYW4gU0RPPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGRpc3B1dGUnLiBXZSBhcmUgZGVhbGluZyBub3Qgb25seSB3aXRoIHN0YW5k YXJkcyBvcmdhbml6YXRpb25zIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0aGlzIGlzIGFsc28gcmVmbGVjdGVkIGluIHRoZSBjdXJyZW50IHRleHQuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgRGFuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyBGcm9tOjxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmciPnNh Y20tYm91bmNlc0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBbPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNhY20tYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7IEJlaGFsZiBPZiBTZWFuIFR1cm5lcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBTZW50OiBUdWVzZGF5LCBKdW5lIDI1LCAyMDEzIDI6 MDYgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgVG86 PGEgaHJlZj0ibWFpbHRvOnRvbnlAeWFhbmF0ZWNoLmNvbSI+dG9ueUB5YWFuYXRlY2guY29tPC9h PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnlAeWFhbmF0ZWNoLmNvbSI+bWFpbHRvOnRvbnlAeWFh bmF0ZWNoLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7IENjOiBNb3JpYXJ0eSwgS2F0aGxlZW47IFN0ZXBoZW4gSGFubmE7IEFkYW0gTW9u dHZpbGxlOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxh IGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPm1haWx0bzpzYWNtQGlldGYub3JnPC9hPiZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgU3ViamVjdDogUmU6 IFtzYWNtXSBzYWNtIGNoYXJ0ZXIgcmV2aWV3PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7IE9uIDYvMjQvMTMgMTI6NDcgUE0sIFRvbnkgUnV0a293c2tpIHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgU0RPIGlzIGFu IHVuZGVzaXJhYmxlIGxlZ2FjeSB0ZXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgUGF0aGV0aWNhbGx5LCB0aGUgb2xkIFNETyBjbHViIHN0aWxs IGRvZXMgbm90IHJlZ2FyZCB0aGUgSUVURiBhcyBhPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyAmcXVvdDtTRE8hJnF1b3Q7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly93d3cu dHRhLm9yLmtyL0VuZ2xpc2gvbmV3L2V4dGVybmFsX3JlbGF0aW9ucy9nc2MxN19jb21tdW5pcSI+ aHR0cDovL3d3dy50dGEub3Iua3IvRW5nbGlzaC9uZXcvZXh0ZXJuYWxfcmVsYXRpb25zL2dzYzE3 X2NvbW11bmlxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsgdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7IC5qPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyBzcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFBl cmhhcHMgaXQgaXMgYmV0dGVyIHRvIHNpbXBseSB1c2UgJnF1b3Q7c3RhbmRhcmRzIGZvcmEuJnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEknbSBub3QgYWdhaW5z dCBqdXN0IHNheWluZyBvcmdhbml6YXRpb24gdG9vLiZuYnNwOyZuYnNwO0kgZG9uJ3Qgd2FudCB0 byBnZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgaW4g dG8gYXJndW1lbnRzIGFib3V0IHdoYXQncyBhbiBTRE8gYW5kIHdoYXQncyBub3QuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IHNwdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgWW91IHNob3VsZCBjb25zaWRlciBpbmNsdWRpbmc6IE5JU1Qs IE1JVFJFLCBhbmQgM0dQUCAtIGFsbCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgd2hpY2ggYXJlIHdlbGwgcmVjb2duaXplZCBhcyBrZXkgc3Rh bmRhcmRzIGJvZGllcyBjdXJyZW50bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7IGVuZ2FnZWQgaW4gU0FDTSByZWxhdGVkIHdvcmsgd2l0aCB3aG9t IHlvdSBzaG91bGQgYmUgaW50ZXJlc3RlZCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgLXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyBPbiA2LzI0LzIwMTMgMTE6NTIgQU0sIEFkYW0gTW9udHZpbGxlIHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoZXJlIGFyZSBhIHZhcmlldHkgb2Ygb3RoZXIgU0RPcyBpbiB3aGljaCB3ZSBjb3VsZCBiZSBp bnRlcmVzdGVkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsgbm93IG9yIGluIHRoZSBmdXR1cmUuJm5ic3A7Jm5ic3A7VGhlIHNob3J0LXN0b3J5 IGxpc3Q6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyAqIEZJUlNUICh2dWxuZXJhYmlsaXR5IHNjb3JpbmcpPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgKiBETVRGIChhbHJlYWR5IG1lbnRp b25lZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyAqIFRDRyAoYWxyZWFkeSBtZW50aW9uZWQpPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgKiBUaGUgT3BlbiBHcm91cCAoWERBUyBhbmQg b3RoZXJzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7ICogSVNPIChpLmUuIFRhZ1ZhdWx0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7ICogVzNDIChpLmUuIG9idmlvdXMgdGhpbmdzIGxp a2UgWE1MIERpZ1NpZywgYW5kIHBvdGVudGlhbGx5IGxlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBvYnZpb3VzIHRoaW5ncyBsaWtlIFJE RiwgT1dMLCBTV1JMLCBldGMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICogT0FTSVMgKGkuZS4gc2VjdXJpdHkgYXNzZXJ0aW9ucywga2V5 IG1hbmFnZW1lbnQsIGFsZXJ0aW5nKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7ICogT01HIChpLmUuIEJ1c2luZXNzIFByb2Nlc3MgTW9kZWwg Tm90YXRpb24gYW5kL29yIEV4ZWN1dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IExhbmd1YWdlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGV0Yy4pPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsgc2FjbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5tYWlsdG86c2FjbUBpZXRmLm9y ZzwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBzYWNtIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8 L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+bWFpbHRvOnNhY21AaWV0Zi5v cmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2FjbSBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNh Y21AaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+bWFpbHRv OnNhY21AaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2FjbSBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21A aWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+bWFpbHRvOnNh Y21AaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo aXMgbWVzc2FnZSBhbmQgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uLiZuYnNw OyZuYnNwO0lmIGl0IGFwcGVhcnMgdGhhdCB0aGlzIG1lc3NhZ2Ugd2FzIHNlbnQgdG8geW91IGJ5 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1pc3Rha2UsIGFu eSByZXRlbnRpb24sIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgbWVzc2FnZSBh bmQgYXR0YWNobWVudHMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsmbmJzcDtQbGVhc2Ug bm90aWZ5PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQg YW55PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0dGFjaG1l bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzYWNtIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4gJmx0Ozxh IGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5tYWlsdG86c2FjbUBpZXRmLm9yZzwvYT4mZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FjbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPnNhY20gbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGEg aHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z YWNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjwv ZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9k aXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930C0732458AMBCLUSTERxcha_-- From kathleen.moriarty@emc.com Wed Jun 26 06:12:13 2013 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 E29EF21F9F44 for ; Wed, 26 Jun 2013 06:12:13 -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 A056Vx9zMoes for ; Wed, 26 Jun 2013 06:12:09 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB9121F9F02 for ; Wed, 26 Jun 2013 06:12:08 -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 r5QDC0Or016950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 09:12:00 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 26 Jun 2013 09:11:43 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5QDBhFJ004775; Wed, 26 Jun 2013 09:11:43 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 26 Jun 2013 09:11:42 -0400 From: "Moriarty, Kathleen" To: "Waltermire, David A." , "Kent_Landfield@McAfee.com" , "turners@ieca.com" , "sacm@ietf.org" Date: Wed, 26 Jun 2013 09:10:51 -0400 Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNhuvQoRthgPdUqZE3J5Z9Ln/5lFMPAAgAACywCAABNbgIAAD2wAgABpioCAAJdzAIAATgCAgAAInQCAAAcIAIAAGcIAgAAkFID//+MmAIABGvGAgAA4vYCAACVpgP//nCbwgABtXID//5wewAAA1Ge4 Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:12:14 -0000 The list is getting back to the one Dan provided. I think DMTF will be nec= essary to reference the Common Information Model (CIM) as well. Best regards, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Waltermire= , David A. [david.waltermire@nist.gov] Sent: Wednesday, June 26, 2013 9:02 AM To: Kent_Landfield@McAfee.com; turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review I mentioned this work because it does align with some of the tentative requ= irements and use cases that have been floated. There is a potential for li= aison with these orgs. Even for the NIST and MITRE work, we have options to= reference it in place or bring the work in. You could say the same thing = for TCG and OpenGroup efforts. It is too early to decide one way or anothe= r right now as we still have work to do on the use cases, requirements, and= architecture documents. The determining factor will be if changes need to = be made to the existing work and if the orgs are willing to make a contribu= tion. If it is referenced, this will drive the liaison decision. If the wor= k needs to brought in, then all of what you said about IPR would apply. Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:45 AM To: Waltermire, David A.; turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review Hi Dave, I assumed that MILE and NEA were already identified from charter references= and was looking at only organizations external to the IETF. Individuals fr= om the organizations I listed either are or have had active discussions to = contribute to the proposed WG. I am not sure initially we are talking abou= t TCG related work. Yes, it could be possible but that is up to the TCG to = contribute their work into the group as a proposal. Same for O-ACEML. Those= proposals need to fit the proposed charter and be made to the working grou= p itself. If they are making proposals for work items to the SACM WG then = they would be following the IETF IPR rules for documents contributed. The k= ey here is that the work would be done in SACM and should not be duplicatin= g work elsewhere. I guess I need clarity from Sean. I was looking at what organizations woul= d be directly working with the SACM initially. Liaison or otherwise. I full= y expect we would invite others to participate in SACM. I personally plan = on trying to assure all are aware of the SACM efforts and goals. Developin= g a list of who to invite is different from the perspective I responded wit= h. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Wednesday, June 26, 2013 2:23 PM To: Kent Landfield >, Sean Turner >, "sacm@ietf.= org" > Subject: RE: [sacm] sacm charter review We may want to bring in updates of the existing NEA protocols and/or new wo= rk created within the TCG. We may also want to consider O-ACEML from the O= penGroup. These have been discussed as options on the list and during the B= oFs. Dave From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:11 AM To: turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review >From my perspective the initial organizations we will be dealing with are - ISO/IEC - NIST - MITRE Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 1:56 PM To: "sacm@ietf.org" > Subject: Re: [sacm] sacm charter review It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: Yes. The fact that other organizations are interested in the scope of SACM does not mean that they do the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to refer or document these in An Informational RFC, but this is not a mandatory deliverable. The working group will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. Regards, Dan *From:*sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, June 25, 2013 6:41 PM *To:* Kent_Landfield@McAfee.com; Adam.Mon= tville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com= ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com *Sent:* Tuesday, June 25, 2013 8:24 AM *To:* Adam.Montville@cisecurity.org ; dbharrington@comcast.net ; turners@ieca.com ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *Adam Montville > *Date: *Tuesday, June 25, 2013 5:15 PM *To: *David Harrington >, Sea= n Turner >, "sacm@ietf.org " > *Subject: *Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org ] on behalf of David Harrington [dbharrington@comcast.net ] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org ; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them= ) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com ; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaiso= n > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From:sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To:tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >>sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF = as a >>> "SDO!" >>>http://www.tta.or.kr/English/new/external_relations/gsc17_commu= niq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to = get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be intereste= d now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be intere= sted >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially l= ess >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ 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 Jun 26 06:19:29 2013 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 F26D721E810B for ; Wed, 26 Jun 2013 06:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 TA1wKR9aEIrk for ; Wed, 26 Jun 2013 06:19:10 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.216.18]) by ietfa.amsl.com (Postfix) with ESMTP id F32D221E811E for ; Wed, 26 Jun 2013 06:19:08 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id BD891992F3E57; Wed, 26 Jun 2013 08:19:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id B0D90992F3E18 for ; Wed, 26 Jun 2013 08:19:08 -0500 (CDT) Received: from [173.73.135.101] (port=62890 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Urpco-0001rv-9F; Wed, 26 Jun 2013 08:19:06 -0500 Message-ID: <51CAEA49.2020106@ieca.com> Date: Wed, 26 Jun 2013 09:19:05 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent_Landfield@McAfee.com References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:62890 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: david.waltermire@nist.gov, sacm@ietf.org Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:19:29 -0000 I'm shooting for some examples of folks we'll be dealing with to do the work as currently scoped. I'll see if I can't propose some words for the ADs. spt On 6/26/13 8:44 AM, Kent_Landfield@McAfee.com wrote: > Hi Dave, > > I assumed that MILE and NEA were already identified from charter > references and was looking at only organizations external to the IETF. > Individuals from the organizations I listed either are or have had > active discussions to contribute to the proposed WG. I am not sure > initially we are talking about TCG related work. Yes, it could be > possible but that is up to the TCG to contribute their work into the > group as a proposal. Same for O-ACEML. Those proposals need to fit the > proposed charter and be made to the working group itself. If they are > making proposals for work items to the SACM WG then they would be > following the IETF IPR rules for documents contributed. The key here is > that the work would be done in SACM and should not be duplicating work > elsewhere. > > I guess I need clarity from Sean. I was looking at what organizations > would be directly working with the SACM initially. Liaison or otherwise. > I fully expect we would invite others to participate in SACM. I > personally plan on trying to assure all are aware of the SACM efforts > and goals. Developing a list of who to invite is different from the > perspective I responded with. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: , David Waltermire > > Date: Wednesday, June 26, 2013 2:23 PM > To: Kent Landfield >, Sean Turner >, "sacm@ietf.org " > > > Subject: RE: [sacm] sacm charter review > > We may want to bring in updates of the existing NEA protocols and/or > new work created within the TCG. We may also want to consider > O-ACEML from the OpenGroup. These have been discussed as options on > the list and during the BoFs. > > Dave > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > *Sent:* Wednesday, June 26, 2013 8:11 AM > *To:* turners@ieca.com ; sacm@ietf.org > > *Subject:* Re: [sacm] sacm charter review > > From my perspective the initial organizations we will be dealing > with are > > - ISO/IEC > > - NIST > > - MITRE > > *Kent Landfield* > > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *Sean Turner > > *Date: *Wednesday, June 26, 2013 1:56 PM > *To: *"sacm@ietf.org " > > *Subject: *Re: [sacm] sacm charter review > > It looks like Joel wants to know now some of the organizations > (i.e., > > there's block on the charter). Can we whittle this list down to > just > > orgs we're going to be dealing with at the initial stages? For > asset > > identification it's possibly going to be ISO+NIST+?, for endpoint > > elements to assess it's ?, for comparison it's ?, for > interacting with > > repositories it's NEA. > > More inline. > > On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: > > Yes. The fact that other organizations are interested in the > scope of > > SACM does not mean that they do the same work, and certainly > the future > > WG must avoid duplication. Maybe we should make this > explicit. For example: > > OLD: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to make of > this document an > > Informational RFC, but this is not a mandatory deliverable. > > NEW: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to refer or > document > > these in > > An Informational RFC, but this is not a mandatory > deliverable. The > > working group > > will not duplicate work already done or in progress in other > places. > > We were on the same wavelength. I'm not sure we need to > repeated the we > > won't duplicate work because there's already a blurb about > reuse. What > > I proposed to Barry/Joel/Spencer: > > OLD: > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or > in other > > SDOs which can be used as-is or as a starting point for developing > > solutions to the SACM requirements. > > NEW: > > The working group will create an Internet-Draft documenting the > existing > > work in the IETF and in other organizations that might > > be used as-is or as a starting point for developing solutions to > > the SACM requirements. > > OLD: > > In accordance with existing IETF processes, the group will > communicate > > with and invite participation from other relevant standards > bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > NEW: > > In accordance with existing IETF processes, the working group will > > communicate with and invite participation from other relevant > groups and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > Regards, > > Dan > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf > > Of *Michael Hammer > > *Sent:* Tuesday, June 25, 2013 6:41 PM > > *To:* Kent_Landfield@McAfee.com > ; > Adam.Montville@cisecurity.org > ; > > dbharrington@comcast.net ; > turners@ieca.com ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > +1 This just means many groups are interested in the same > scope. > > Mike > > *From:*sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > > > > *Sent:* Tuesday, June 25, 2013 8:24 AM > > *To:* Adam.Montville@cisecurity.org > > > ; > dbharrington@comcast.net > > ; turners@ieca.com > > > ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > Well said Adam. I totally agree with your comments. > > *Kent Landfield* > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > *From: *Adam Montville > > > > > > *Date: *Tuesday, June 25, 2013 5:15 PM > > *To: *David Harrington > > > >, Sean Turner > > > >, > "sacm@ietf.org > " > > > > > > *Subject: *Re: [sacm] sacm charter review > > Hi David, > > I respectfully disagree. > > While this may be a commentary on the potential, > eventual reach of > > SACM, our charter's scope is far reduced from > including all of these > > organizations at the outset. In other words, our > scope is limited > > by the language in the charter, against which this > list really has > > no bearing other than to satisfy curiosity and, > perhaps, lend some > > vision to the future. > > In fact, it might be more properly construed that this > list of > > organizations is a commentary on the ubiquitous nature > of assessment > > - it is a capability that "touches" a lot of different > areas, which > > is precisely why it warrants its own working group, IMO. > > Regards, > > Adam > > ________________________________________ > > From: sacm-bounces@ietf.org > > > [sacm-bounces@ietf.org > > ] on behalf of > > David Harrington [dbharrington@comcast.net > > > > ] > > Sent: Tuesday, June 25, 2013 6:43 AM > > To: 'Sean Turner'; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > Wow! > > I think this is an excellent commentary on the scope > of SACM being > > way too > > broad, and poorly scoped for engineering purposes. > > David Harrington > > dbharrington@comcast.net > > > +1-603-828-1401 > > -----Original Message----- > > From: sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Romascanu, Dan (Dan) > > Sent: Tuesday, June 25, 2013 9:18 AM > > To: Sean Turner > > Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; > sacm@ietf.org > > ; > > tony@yaanatech.com > > > Subject: Re: [sacm] sacm charter review > > Hi Sean, > > A list of organizations that are involved in the area, > as identified > > in this > > discussion includes: > > - TCG > > - DMTF > > - FIRST > > - The Open Group > > - ISO/IEC > > - W3C > > - OASIS > > - OMG > > - NIST > > - MITRE > > - 3GPP > > It's up to the IESG to decide if we should list these > (or some of them) > > explicitly, or we should leave to the WG after its > formation is > > approved to > > initiate communication and invite participation. > > Regards, > > Dan > > -----Original Message----- > > From: Sean Turner [mailto:turners@ieca.com] > > Sent: Tuesday, June 25, 2013 3:47 PM > > To: Romascanu, Dan (Dan) > > Cc: tony@yaanatech.com > ; Adam > > Montville; Stephen Hanna; Moriarty, > > Kathleen; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > At this point 3 ADs have asked about what other > SDOs are involved. > > I'm not sure if they want names in the charter or > if they're just > > interested in knowing. > > spt > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > > The proposed text in the charter already says: > > > > > >> In accordance with existing IETF processes, the > group will > > >> communicate with and > > > invite participation from other relevant > standards bodies and > > > regulatory organizations, and if necessary reuse > existing liaison > > > relationships or request the establishment of > new liaison > > relationships. > > > > > > 'standard bodies and regulatory organizations' > are neutral terms > > enough IMO, as Sean says we should not enter the > 'what is an SDO > > dispute'. We are dealing not only with standards > organizations and > > this is also reflected in the current text. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From:sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] On > > >> Behalf Of Sean Turner > > >> Sent: Tuesday, June 25, 2013 2:06 AM > > >> To:tony@yaanatech.com > > > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam > Montville; > > >>sacm@ietf.org > > > >> Subject: Re: [sacm] sacm charter review > > >> > > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > >>> SDO is an undesirable legacy term. > > >>> Pathetically, the old SDO club still does not > regard the IETF as a > > >>> "SDO!" > > > >>>http://www.tta.or.kr/English/new/external_relations/gsc17_communiq > > >>> ue > > >>> .j > > >>> sp > > >>> > > >>> Perhaps it is better to simply use "standards > fora." > > >> > > >> I'm not against just saying organization > too. I don't want to get > > >> in to arguments about what's an SDO and what's not. > > >> > > >> spt > > >> > > >>> You should consider including: NIST, MITRE, > and 3GPP - all of > > >>> which are well recognized as key standards > bodies currently > > >>> engaged in SACM related work with whom you > should be interested now. > > >>> > > >>> -t > > >>> > > >>> On 6/24/2013 11:52 AM, Adam Montville wrote: > > >>>> There are a variety of other SDOs in which we > could be interested > > >>>> now or in the future. The short-story list: > > >>>> > > >>>> * FIRST (vulnerability scoring) > > >>>> * DMTF (already mentioned) > > >>>> * TCG (already mentioned) > > >>>> * The Open Group (XDAS and others) > > >>>> * ISO (i.e. TagVault) > > >>>> * W3C (i.e. obvious things like XML DigSig, > and potentially less > > >>>> obvious things like RDF, OWL, SWRL, etc.) > > >>>> * OASIS (i.e. security assertions, key > management, alerting) > > >>>> * OMG (i.e. Business Process Model Notation > and/or Execution > > >>>> Language, > > >>>> etc.) > > >>> > > >>> > > >> _______________________________________________ > > >> 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 > > ... > > 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. > > _______________________________________________ > > 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 Jun 26 06:30:35 2013 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 5900111E81B8 for ; Wed, 26 Jun 2013 06:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 ktKr-Yw4TCzl for ; Wed, 26 Jun 2013 06:30:30 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.243.26]) by ietfa.amsl.com (Postfix) with ESMTP id 64B4D11E80EA for ; Wed, 26 Jun 2013 06:30:30 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 814F28A8A224A; Wed, 26 Jun 2013 08:30:19 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 7058A8A8A221D for ; Wed, 26 Jun 2013 08:30:19 -0500 (CDT) Received: from [173.73.135.101] (port=62986 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Urpnn-0005x9-Nf; Wed, 26 Jun 2013 08:30:28 -0500 Message-ID: <51CAECF3.4060000@ieca.com> Date: Wed, 26 Jun 2013 09:30:27 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Waltermire, David A." References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:62986 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:30:35 -0000 Dave, I gotta admit that I loathe the idea of shipping liaison around to NIST ;) spt On 6/26/13 9:02 AM, Waltermire, David A. wrote: > I mentioned this work because it does align with some of the tentative > requirements and use cases that have been floated. There is a potential > for liaison with these orgs. Even for the NIST and MITRE work, we have > options to reference it in place or bring the work in. You could say > the same thing for TCG and OpenGroup efforts. It is too early to decide > one way or another right now as we still have work to do on the use > cases, requirements, and architecture documents. The determining factor > will be if changes need to be made to the existing work and if the orgs > are willing to make a contribution. If it is referenced, this will drive > the liaison decision. If the work needs to brought in, then all of what > you said about IPR would apply. > > Dave > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Kent_Landfield@McAfee.com > *Sent:* Wednesday, June 26, 2013 8:45 AM > *To:* Waltermire, David A.; turners@ieca.com; sacm@ietf.org > *Subject:* Re: [sacm] sacm charter review > > Hi Dave, > > I assumed that MILE and NEA were already identified from charter > references and was looking at only organizations external to the IETF. > Individuals from the organizations I listed either are or have had > active discussions to contribute to the proposed WG. I am not sure > initially we are talking about TCG related work. Yes, it could be > possible but that is up to the TCG to contribute their work into the > group as a proposal. Same for O-ACEML. Those proposals need to fit the > proposed charter and be made to the working group itself. If they are > making proposals for work items to the SACM WG then they would be > following the IETF IPR rules for documents contributed. The key here is > that the work would be done in SACM and should not be duplicating work > elsewhere. > > I guess I need clarity from Sean. I was looking at what organizations > would be directly working with the SACM initially. Liaison or otherwise. > I fully expect we would invite others to participate in SACM. I > personally plan on trying to assure all are aware of the SACM efforts > and goals. Developing a list of who to invite is different from the > perspective I responded with. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, David Waltermire > > *Date: *Wednesday, June 26, 2013 2:23 PM > *To: *Kent Landfield >, Sean Turner >, "sacm@ietf.org " > > > *Subject: *RE: [sacm] sacm charter review > > We may want to bring in updates of the existing NEA protocols and/or > new work created within the TCG. We may also want to consider > O-ACEML from the OpenGroup. These have been discussed as options on > the list and during the BoFs. > > Dave > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > *Sent:* Wednesday, June 26, 2013 8:11 AM > *To:* turners@ieca.com ; sacm@ietf.org > > *Subject:* Re: [sacm] sacm charter review > > From my perspective the initial organizations we will be dealing > with are > > - ISO/IEC > > - NIST > > - MITRE > > *Kent Landfield* > > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *Sean Turner > > *Date: *Wednesday, June 26, 2013 1:56 PM > *To: *"sacm@ietf.org " > > *Subject: *Re: [sacm] sacm charter review > > It looks like Joel wants to know now some of the organizations > (i.e., > > there's block on the charter). Can we whittle this list down to > just > > orgs we're going to be dealing with at the initial stages? For > asset > > identification it's possibly going to be ISO+NIST+?, for endpoint > > elements to assess it's ?, for comparison it's ?, for > interacting with > > repositories it's NEA. > > More inline. > > On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: > > Yes. The fact that other organizations are interested in the > scope of > > SACM does not mean that they do the same work, and certainly > the future > > WG must avoid duplication. Maybe we should make this > explicit. For example: > > OLD: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to make of > this document an > > Informational RFC, but this is not a mandatory deliverable. > > NEW: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to refer or > document > > these in > > An Informational RFC, but this is not a mandatory > deliverable. The > > working group > > will not duplicate work already done or in progress in other > places. > > We were on the same wavelength. I'm not sure we need to > repeated the we > > won't duplicate work because there's already a blurb about > reuse. What > > I proposed to Barry/Joel/Spencer: > > OLD: > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or > in other > > SDOs which can be used as-is or as a starting point for developing > > solutions to the SACM requirements. > > NEW: > > The working group will create an Internet-Draft documenting the > existing > > work in the IETF and in other organizations that might > > be used as-is or as a starting point for developing solutions to > > the SACM requirements. > > OLD: > > In accordance with existing IETF processes, the group will > communicate > > with and invite participation from other relevant standards > bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > NEW: > > In accordance with existing IETF processes, the working group will > > communicate with and invite participation from other relevant > groups and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > Regards, > > Dan > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf > > Of *Michael Hammer > > *Sent:* Tuesday, June 25, 2013 6:41 PM > > *To:* Kent_Landfield@McAfee.com > ; > Adam.Montville@cisecurity.org > ; > > dbharrington@comcast.net ; > turners@ieca.com ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > +1 This just means many groups are interested in the same > scope. > > Mike > > *From:*sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > > > > *Sent:* Tuesday, June 25, 2013 8:24 AM > > *To:* Adam.Montville@cisecurity.org > > > ; > dbharrington@comcast.net > > ; turners@ieca.com > > > ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > Well said Adam. I totally agree with your comments. > > *Kent Landfield* > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > *From: *Adam Montville > > > > > > *Date: *Tuesday, June 25, 2013 5:15 PM > > *To: *David Harrington > > > >, Sean Turner > > > >, > "sacm@ietf.org > " > > > > > > *Subject: *Re: [sacm] sacm charter review > > Hi David, > > I respectfully disagree. > > While this may be a commentary on the potential, > eventual reach of > > SACM, our charter's scope is far reduced from > including all of these > > organizations at the outset. In other words, our > scope is limited > > by the language in the charter, against which this > list really has > > no bearing other than to satisfy curiosity and, > perhaps, lend some > > vision to the future. > > In fact, it might be more properly construed that this > list of > > organizations is a commentary on the ubiquitous nature > of assessment > > - it is a capability that "touches" a lot of different > areas, which > > is precisely why it warrants its own working group, IMO. > > Regards, > > Adam > > ________________________________________ > > From: sacm-bounces@ietf.org > > > [sacm-bounces@ietf.org > > ] on behalf of > > David Harrington [dbharrington@comcast.net > > > > ] > > Sent: Tuesday, June 25, 2013 6:43 AM > > To: 'Sean Turner'; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > Wow! > > I think this is an excellent commentary on the scope > of SACM being > > way too > > broad, and poorly scoped for engineering purposes. > > David Harrington > > dbharrington@comcast.net > > > +1-603-828-1401 > > -----Original Message----- > > From: sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Romascanu, Dan (Dan) > > Sent: Tuesday, June 25, 2013 9:18 AM > > To: Sean Turner > > Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; > sacm@ietf.org > > ; > > tony@yaanatech.com > > > Subject: Re: [sacm] sacm charter review > > Hi Sean, > > A list of organizations that are involved in the area, > as identified > > in this > > discussion includes: > > - TCG > > - DMTF > > - FIRST > > - The Open Group > > - ISO/IEC > > - W3C > > - OASIS > > - OMG > > - NIST > > - MITRE > > - 3GPP > > It's up to the IESG to decide if we should list these > (or some of them) > > explicitly, or we should leave to the WG after its > formation is > > approved to > > initiate communication and invite participation. > > Regards, > > Dan > > -----Original Message----- > > From: Sean Turner [mailto:turners@ieca.com] > > Sent: Tuesday, June 25, 2013 3:47 PM > > To: Romascanu, Dan (Dan) > > Cc: tony@yaanatech.com > ; Adam > > Montville; Stephen Hanna; Moriarty, > > Kathleen; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > At this point 3 ADs have asked about what other > SDOs are involved. > > I'm not sure if they want names in the charter or > if they're just > > interested in knowing. > > spt > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > > The proposed text in the charter already says: > > > > > >> In accordance with existing IETF processes, the > group will > > >> communicate with and > > > invite participation from other relevant > standards bodies and > > > regulatory organizations, and if necessary reuse > existing liaison > > > relationships or request the establishment of > new liaison > > relationships. > > > > > > 'standard bodies and regulatory organizations' > are neutral terms > > enough IMO, as Sean says we should not enter the > 'what is an SDO > > dispute'. We are dealing not only with standards > organizations and > > this is also reflected in the current text. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From:sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] On > > >> Behalf Of Sean Turner > > >> Sent: Tuesday, June 25, 2013 2:06 AM > > >> To:tony@yaanatech.com > > > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam > Montville; > > >>sacm@ietf.org > > > >> Subject: Re: [sacm] sacm charter review > > >> > > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > >>> SDO is an undesirable legacy term. > > >>> Pathetically, the old SDO club still does not > regard the IETF as a > > >>> "SDO!" > > > >>>http://www.tta.or.kr/English/new/external_relations/gsc17_communiq > > >>> ue > > >>> .j > > >>> sp > > >>> > > >>> Perhaps it is better to simply use "standards > fora." > > >> > > >> I'm not against just saying organization > too. I don't want to get > > >> in to arguments about what's an SDO and what's not. > > >> > > >> spt > > >> > > >>> You should consider including: NIST, MITRE, > and 3GPP - all of > > >>> which are well recognized as key standards > bodies currently > > >>> engaged in SACM related work with whom you > should be interested now. > > >>> > > >>> -t > > >>> > > >>> On 6/24/2013 11:52 AM, Adam Montville wrote: > > >>>> There are a variety of other SDOs in which we > could be interested > > >>>> now or in the future. The short-story list: > > >>>> > > >>>> * FIRST (vulnerability scoring) > > >>>> * DMTF (already mentioned) > > >>>> * TCG (already mentioned) > > >>>> * The Open Group (XDAS and others) > > >>>> * ISO (i.e. TagVault) > > >>>> * W3C (i.e. obvious things like XML DigSig, > and potentially less > > >>>> obvious things like RDF, OWL, SWRL, etc.) > > >>>> * OASIS (i.e. security assertions, key > management, alerting) > > >>>> * OMG (i.e. Business Process Model Notation > and/or Execution > > >>>> Language, > > >>>> etc.) > > >>> > > >>> > > >> _______________________________________________ > > >> 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 > > ... > > 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. > > _______________________________________________ > > 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 shanna@juniper.net Wed Jun 26 06:54:29 2013 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 0BC5621E80E3 for ; Wed, 26 Jun 2013 06:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.466 X-Spam-Level: X-Spam-Status: No, score=-99.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132, 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 UIfCKyXQr41T for ; Wed, 26 Jun 2013 06:54:09 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0931221F9D23 for ; Wed, 26 Jun 2013 06:53:41 -0700 (PDT) Received: from mail1-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE015.bigfish.com (10.174.4.78) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 13:53:40 +0000 Received: from mail1-db8 (localhost [127.0.0.1]) by mail1-db8-R.bigfish.com (Postfix) with ESMTP id A056AB003B8 for ; Wed, 26 Jun 2013 13:53:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VPS-37(zzbb2dI98dI9371I9f17Rc85fh542I1432I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1033IL17326ah18c673h1c8fb4h2ba5I18602eh8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail1-db8: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=shanna@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail1-db8 (localhost.localdomain [127.0.0.1]) by mail1-db8 (MessageSwitch) id 1372254816480345_17827; Wed, 26 Jun 2013 13:53:36 +0000 (UTC) Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.252]) by mail1-db8.bigfish.com (Postfix) with ESMTP id 61D7C1640047 for ; Wed, 26 Jun 2013 13:53:36 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Jun 2013 13:53:34 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Jun 2013 06:53:30 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 26 Jun 2013 06:53:29 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 26 Jun 2013 06:57:45 -0700 Received: from mail116-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE021.bigfish.com (10.243.66.84) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 13:53:29 +0000 Received: from mail116-co1 (localhost [127.0.0.1]) by mail116-co1-R.bigfish.com (Postfix) with ESMTP id 65F3016023A for ; Wed, 26 Jun 2013 13:53:29 +0000 (UTC) Received: from mail116-co1 (localhost.localdomain [127.0.0.1]) by mail116-co1 (MessageSwitch) id 1372254805564965_29138; Wed, 26 Jun 2013 13:53:25 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.243]) by mail116-co1.bigfish.com (Postfix) with ESMTP id 7BBC954005B; Wed, 26 Jun 2013 13:53:25 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 13:53:24 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.63]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0324.000; Wed, 26 Jun 2013 13:53:15 +0000 From: Stephen Hanna To: "Waltermire, David A." , "Kent_Landfield@McAfee.com" , "turners@ieca.com" , "sacm@ietf.org" Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh37nKSnCbwB0KyXIYmhwU2yplE7eEAgAAB5fCAABRCgIAAD2sAgABpi4CAAJdzAIAATgCAgAAInACAAAcJAIAAGcIAgAACjQCAAAStAIABGvGAgAA4vYCAAAPkgIAAA36AgAAGB4CAAATdAIAABWtA Date: Wed, 26 Jun 2013 13:53:15 +0000 Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E1AA51D5ESN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NIST.GOV$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MCAFEE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:54:29 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E1AA51D5ESN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TCG has eight years of experience developing widely deployed endpoint asses= sment protocols and a proven track record of contributing our protocols to = IETF under the IETF's standard terms. For example, we contributed the TNC c= lient-server protocols to IETF as Internet-Drafts. They have been adopted b= y the NEA working group, revised, and published as Proposed Standard RFCs. = The TCG standards are very relevant to the SACM work, even beyond the NEA s= pecs. For example, IF-MAP is an excellent protocol for gathering endpoint a= ssessment results across a variety of endpoint assessment technologies. Als= o, TCG has been represented in the SACM work since the very start. I believe that TCG should stand on equal footing with NIST and MITRE in thi= s matter. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Wednesday, June 26, 2013 9:02 AM To: Kent_Landfield@McAfee.com; turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review I mentioned this work because it does align with some of the tentative requ= irements and use cases that have been floated. There is a potential for li= aison with these orgs. Even for the NIST and MITRE work, we have options to= reference it in place or bring the work in. You could say the same thing = for TCG and OpenGroup efforts. It is too early to decide one way or anothe= r right now as we still have work to do on the use cases, requirements, and= architecture documents. The determining factor will be if changes need to = be made to the existing work and if the orgs are willing to make a contribu= tion. If it is referenced, this will drive the liaison decision. If the wor= k needs to brought in, then all of what you said about IPR would apply. Dave From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:45 AM To: Waltermire, David A.; turners@ieca.com; sacm@i= etf.org Subject: Re: [sacm] sacm charter review Hi Dave, I assumed that MILE and NEA were already identified from charter references= and was looking at only organizations external to the IETF. Individuals fr= om the organizations I listed either are or have had active discussions to = contribute to the proposed WG. I am not sure initially we are talking abou= t TCG related work. Yes, it could be possible but that is up to the TCG to = contribute their work into the group as a proposal. Same for O-ACEML. Those= proposals need to fit the proposed charter and be made to the working grou= p itself. If they are making proposals for work items to the SACM WG then = they would be following the IETF IPR rules for documents contributed. The k= ey here is that the work would be done in SACM and should not be duplicatin= g work elsewhere. I guess I need clarity from Sean. I was looking at what organizations woul= d be directly working with the SACM initially. Liaison or otherwise. I full= y expect we would invite others to participate in SACM. I personally plan = on trying to assure all are aware of the SACM efforts and goals. Developin= g a list of who to invite is different from the perspective I responded wit= h. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , David Waltermire > Date: Wednesday, June 26, 2013 2:23 PM To: Kent Landfield >, Sean Turner >, "sacm@ietf.= org" > Subject: RE: [sacm] sacm charter review We may want to bring in updates of the existing NEA protocols and/or new wo= rk created within the TCG. We may also want to consider O-ACEML from the O= penGroup. These have been discussed as options on the list and during the B= oFs. Dave From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Wednesday, June 26, 2013 8:11 AM To: turners@ieca.com; sacm@ietf.org Subject: Re: [sacm] sacm charter review >From my perspective the initial organizations we will be dealing with are - ISO/IEC - NIST - MITRE Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 1:56 PM To: "sacm@ietf.org" > Subject: Re: [sacm] sacm charter review It looks like Joel wants to know now some of the organizations (i.e., there's block on the charter). Can we whittle this list down to just orgs we're going to be dealing with at the initial stages? For asset identification it's possibly going to be ISO+NIST+?, for endpoint elements to assess it's ?, for comparison it's ?, for interacting with repositories it's NEA. More inline. On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: Yes. The fact that other organizations are interested in the scope of SACM does not mean that they do the same work, and certainly the future WG must avoid duplication. Maybe we should make this explicit. For example: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. NEW: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to refer or document these in An Informational RFC, but this is not a mandatory deliverable. The working group will not duplicate work already done or in progress in other places. We were on the same wavelength. I'm not sure we need to repeated the we won't duplicate work because there's already a blurb about reuse. What I proposed to Barry/Joel/Spencer: OLD: The working group will create an overview of related standards work Internet-Draft which will document existing work in the IETF or in other SDOs which can be used as-is or as a starting point for developing solutions to the SACM requirements. NEW: The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. OLD: In accordance with existing IETF processes, the group will communicate with and invite participation from other relevant standards bodies and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. NEW: In accordance with existing IETF processes, the working group will communicate with and invite participation from other relevant groups and regulatory organizations, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships. Regards, Dan *From:*sacm-bounces@ietf.org [mailto:sacm-bo= unces@ietf.org] *On Behalf Of *Michael Hammer *Sent:* Tuesday, June 25, 2013 6:41 PM *To:* Kent_Landfield@McAfee.com; Adam.Mon= tville@cisecurity.org; dbharrington@comcast.net; turners@ieca.com= ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review +1 This just means many groups are interested in the same scope. Mike *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com *Sent:* Tuesday, June 25, 2013 8:24 AM *To:* Adam.Montville@cisecurity.org ; dbharrington@comcast.net ; turners@ieca.com ; sacm@ietf.org *Subject:* Re: [sacm] sacm charter review Well said Adam. I totally agree with your comments. *Kent Landfield* *McAfee | An Intel Company* Direct: +1.972.963.7096 Mobile: +1.817.637.8026 *Web: *www.mcafee.com *From: *Adam Montville > *Date: *Tuesday, June 25, 2013 5:15 PM *To: *David Harrington >, Sea= n Turner >, "sacm@ietf.org " > *Subject: *Re: [sacm] sacm charter review Hi David, I respectfully disagree. While this may be a commentary on the potential, eventual reach of SACM, our charter's scope is far reduced from including all of these organizations at the outset. In other words, our scope is limited by the language in the charter, against which this list really has no bearing other than to satisfy curiosity and, perhaps, lend some vision to the future. In fact, it might be more properly construed that this list of organizations is a commentary on the ubiquitous nature of assessment - it is a capability that "touches" a lot of different areas, which is precisely why it warrants its own working group, IMO. Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org ] on behalf of David Harrington [dbharrington@comcast.net ] Sent: Tuesday, June 25, 2013 6:43 AM To: 'Sean Turner'; sacm@ietf.org Subject: Re: [sacm] sacm charter review Wow! I think this is an excellent commentary on the scope of SACM being way too broad, and poorly scoped for engineering purposes. David Harrington dbharrington@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, June 25, 2013 9:18 AM To: Sean Turner Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org ; tony@yaanatech.com Subject: Re: [sacm] sacm charter review Hi Sean, A list of organizations that are involved in the area, as identified in this discussion includes: - TCG - DMTF - FIRST - The Open Group - ISO/IEC - W3C - OASIS - OMG - NIST - MITRE - 3GPP It's up to the IESG to decide if we should list these (or some of them= ) explicitly, or we should leave to the WG after its formation is approved to initiate communication and invite participation. Regards, Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 25, 2013 3:47 PM To: Romascanu, Dan (Dan) Cc: tony@yaanatech.com ; Adam Montville; Stephen Hanna; Moriarty, Kathleen; sacm@ietf.org Subject: Re: [sacm] sacm charter review At this point 3 ADs have asked about what other SDOs are involved. I'm not sure if they want names in the charter or if they're just interested in knowing. spt On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > The proposed text in the charter already says: > >> In accordance with existing IETF processes, the group will >> communicate with and > invite participation from other relevant standards bodies and > regulatory organizations, and if necessary reuse existing liaiso= n > relationships or request the establishment of new liaison relationships. > > 'standard bodies and regulatory organizations' are neutral terms enough IMO, as Sean says we should not enter the 'what is an SDO dispute'. We are dealing not only with standards organizations and this is also reflected in the current text. > > Regards, > > Dan > > > > > >> -----Original Message----- >> From:sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 25, 2013 2:06 AM >> To:tony@yaanatech.com >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; >>sacm@ietf.org >> Subject: Re: [sacm] sacm charter review >> >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: >>> SDO is an undesirable legacy term. >>> Pathetically, the old SDO club still does not regard the IETF = as a >>> "SDO!" >>>http://www.tta.or.kr/English/new/external_relations/gsc17_commu= niq >>> ue >>> .j >>> sp >>> >>> Perhaps it is better to simply use "standards fora." >> >> I'm not against just saying organization too. I don't want to = get >> in to arguments about what's an SDO and what's not. >> >> spt >> >>> You should consider including: NIST, MITRE, and 3GPP - all of >>> which are well recognized as key standards bodies currently >>> engaged in SACM related work with whom you should be intereste= d now. >>> >>> -t >>> >>> On 6/24/2013 11:52 AM, Adam Montville wrote: >>>> There are a variety of other SDOs in which we could be intere= sted >>>> now or in the future. The short-story list: >>>> >>>> * FIRST (vulnerability scoring) >>>> * DMTF (already mentioned) >>>> * TCG (already mentioned) >>>> * The Open Group (XDAS and others) >>>> * ISO (i.e. TagVault) >>>> * W3C (i.e. obvious things like XML DigSig, and potentially l= ess >>>> obvious things like RDF, OWL, SWRL, etc.) >>>> * OASIS (i.e. security assertions, key management, alerting) >>>> * OMG (i.e. Business Process Model Notation and/or Execution >>>> Language, >>>> etc.) >>> >>> >> _______________________________________________ >> 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 ... 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. _______________________________________________ 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_F1DFC16DCAA7D3468651A5A776D5796E1AA51D5ESN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TCG has eight years of ex= perience developing widely deployed endpoint assessment protocols and a pro= ven track record of contributing our protocols to IETF under the IETF’s standard terms. For example, we contributed the TNC clien= t-server protocols to IETF as Internet-Drafts. They have been adopted by th= e NEA working group, revised, and published as Proposed Standard RFCs. The = TCG standards are very relevant to the SACM work, even beyond the NEA specs. For example, IF-MAP is an excellent = protocol for gathering endpoint assessment results across a variety of endp= oint assessment technologies. Also, TCG has been represented in the SACM wo= rk since the very start.

 <= /p>

I believe that TCG should= stand on equal footing with NIST and MITRE in this matter.

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Wednesday, June 26, 2013 9:02 AM
To: Kent_Landfield@McAfee.com; turners@ieca.com; sacm@ietf.org
Subject: Re: [sacm] sacm charter review

 

I mentioned this work bec= ause it does align with some of the tentative requirements and use cases th= at have been floated.  There is a potential for liaison with these orgs. Even for the NIST and MITRE work, we have options to refe= rence it in place or bring the work in.  You could say the same thing = for TCG and OpenGroup efforts.  It is too early to decide one way or a= nother right now as we still have work to do on the use cases, requirements, and architecture documents. The determi= ning factor will be if changes need to be made to the existing work and if = the orgs are willing to make a contribution. If it is referenced, this will= drive the liaison decision. If the work needs to brought in, then all of what you said about IPR would ap= ply.

 <= /p>

Dave

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Wednesday, June 26, 2013 8:45 AM
To: Waltermire, David A.; turner= s@ieca.com; sacm@ietf.org
Subject: Re: [sacm] sacm charter review

 

Hi Dave,

 =

I assumed that MILE and = NEA were already identified from charter references and was looking at only= organizations external to the IETF. Individuals from the organizations I l= isted either are or have had active discussions to contribute to the proposed WG.  I am not sure initiall= y we are talking about TCG related work. Yes, it could be possible but that= is up to the TCG to contribute their work into the group as a proposal. Sa= me for O-ACEML. Those proposals need to fit the proposed charter and be made to the working group itself.  = ;If they are making proposals for work items to the SACM WG then they would= be following the IETF IPR rules for documents contributed. The key here is= that the work would be done in SACM and should not be duplicating work elsewhere.

 =

I guess I need clarity f= rom Sean.  I was looking at what organizations would be directly worki= ng with the SACM initially. Liaison or otherwise. I fully expect we would i= nvite others to participate in SACM.  I personally plan on trying to assure all are aware of the SACM efforts and goals. &nbs= p;Developing a list of who to invite is different from the perspective I re= sponded with.

 =

Kent Landfield

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

 =

From: <Waltermire>, David Waltermire &l= t;david.waltermire@nist.gov>
Date: Wednesday, June 26, 2013 2:23 PM
To: Kent Landfield <= Kent_Landfield@McAfee.com>, Sean Turner <turners@ieca.com>, "sacm@ietf.org" <sacm@ietf.or= g>
Subject: RE: [sacm] sacm charter review

 =

We may want to bring in u= pdates of the existing NEA protocols and/or new work created within the TCG= .  We may also want to consider O-ACEML from the OpenGroup. These have been discussed as options on the list and during the BoFs.

 

Dave

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Wednesday, June 26, 2013 8:11 AM
To: turners@ieca.com; sacm@ietf.org
Subject: Re: [sacm] sacm charter review

 =

From my perspective the = initial organizations we will be dealing with are

 =

    = - ISO/IEC

    = - NIST

    = - MITRE

 =

Kent Landfield


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

 =

From: Sean Turner <turners@ieca.com>
Date: Wednesday, June 26, 2013 1:56 PM
To: "sacm@ietf.org" &= lt;sacm@ietf.org>
Subject: Re: [sacm] sacm charter review

 =

It looks like Joel wants= to know now some of the organizations (i.e.,

there's block on the cha= rter).  Can we whittle this list down to just

orgs we're going to be d= ealing with at the initial stages?  For asset

identification it's poss= ibly going to be ISO+NIST+?, for endpoint

elements to assess it's = ?, for comparison it's ?, for interacting with

repositories it's NEA.

 =

More inline.<= /span>

 =

On 6/26/13 4:33 AM, Roma= scanu, Dan (Dan) wrote:

Yes. The fact that other= organizations are interested in the scope of

SACM does not mean that = they do the same work, and certainly the future

WG must avoid duplicatio= n. Maybe we should make this explicit. For example:

 =

OLD:

 =

The working group will c= reate an overview of related standards work

 =

Internet-Draft which wil= l document existing work in the IETF or in other

SDOs

 =

which can be used as-is = or as a starting point for developing solutions

to the=

 =

SACM requirements. The w= orking group may decide to make of this document an

 =

Informational RFC, but t= his is not a mandatory deliverable.

 =

NEW:

 =

The working group will c= reate an overview of related standards work

 =

Internet-Draft which wil= l document existing work in the IETF or in other

SDOs

 =

which can be used as-is = or as a starting point for developing solutions

to the=

 =

SACM requirements. The w= orking group may decide to refer or document

these in

 =

An Informational RFC, bu= t this is not a mandatory deliverable. The

working group=

 =

will not duplicate work = already done or in progress in other places.

 =

We were on the same wave= length.  I'm not sure we need to repeated the we

won't duplicate work bec= ause there's already a blurb about reuse.  What

I proposed to Barry/Joel= /Spencer:

 =

OLD:

 =

The working group will c= reate an overview of related standards work

Internet-Draft which wil= l document existing work in the IETF or in other

SDOs which can be used a= s-is or as a starting point for developing

solutions to the SACM re= quirements.

 =

NEW:

 =

The working group will c= reate an Internet-Draft documenting the existing

work in the IETF and in = other organizations that might

be used as-is or as a st= arting point for developing solutions to

the SACM requirements.

 =

OLD:

 =

In accordance with exist= ing IETF processes, the group will communicate

with and invite particip= ation from other relevant standards bodies and

regulatory organizations= , and if necessary reuse existing liaison

relationships or request= the establishment of new liaison relationships.

 =

NEW:

 =

In accordance with exist= ing IETF processes, the working group will

communicate with and inv= ite participation from other relevant groups and

regulatory organizations= , and if necessary reuse existing liaison

relationships or request= the establishment of new liaison relationships.

 =

 =

Regards,

 =

Dan

 =

Of *Michael Hammer<= /o:p>

*Sent:* Tuesday, June 25= , 2013 6:41 PM

*Subject:* Re: [sacm] sa= cm charter review

 =

+1  This j= ust means many groups are interested in the same scope.

 =

Mike

 =

*Sent:* Tuesday, June 25= , 2013 8:24 AM

*Subject:* Re: [sacm] sa= cm charter review

 =

Well said Adam. I totall= y agree with your comments.

 =

*Kent Landfield*

 =

*McAfee | An Intel Compa= ny*

Direct: +1.972.963.7= 096

Mobile: +1.817.637.8= 026

*Web: *www.mcafee.com &l= t;http://www.mcafee.com/>

 =

*From: *Adam Montville &= lt;Adam.Montville@cisecuri= ty.org

*Date: *Tuesday, June 25= , 2013 5:15 PM

*Subject: *Re: [sacm] sa= cm charter review

 =

    = Hi David,

 =

    = I respectfully disagree.

 =

    = While this may be a commentary on the potential, eventual reach of

    = SACM, our charter's scope is far reduced from including all of these<= /o:p>

    = organizations at the outset.  In other words, our scope is limit= ed

    = by the language in the charter, against which this list really has

    = no bearing other than to satisfy curiosity and, perhaps, lend some

    = vision to the future.

 =

    = In fact, it might be more properly construed that this list of<= /span>

    = organizations is a commentary on the ubiquitous nature of assessment<= /o:p>

    = - it is a capability that "touches" a lot of different areas, wh= ich

    = is precisely why it warrants its own working group, IMO.=

 =

    = Regards,

 =

    = Adam

 =

    = ________________________________________

 =

    = [sacm-bounces@ietf.org <mailto:sacm-bounces@ietf.org><= /a>] on behalf of

    = David Harrington [dbharrington= @comcast.net

 =

    = Sent: Tuesday, June 25, 2013 6:43 AM

 =

    = To: 'Sean Turner'; sacm@ietf.org <mailto:sacm@ietf.org= >

 =

    = Subject: Re: [sacm] sacm charter review

 =

    = Wow!

 =

    = I think this is an excellent commentary on the scope of SACM being

    = way too

 =

    = broad, and poorly scoped for engineering purposes.

 =

    = David Harrington

 =

 =

    = +1-603-828-1401

 =

    = -----Original Message-----

 =

    = [mailto:sacm-bounces@ietf.org= ] On Behalf Of

 =

    = Romascanu, Dan (Dan)

 =

    = Sent: Tuesday, June 25, 2013 9:18 AM

 =

    = To: Sean Turner

 =

    = Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; sacm@ietf.org

    = <mailto:sacm@ietf.org>;

 =

 =

    = Subject: Re: [sacm] sacm charter review

 =

    = Hi Sean,

 =

    = A list of organizations that are involved in the area, as identified<= /o:p>

    = in this

 =

    = discussion includes:

 =

    = - TCG

 =

    = - DMTF

 =

    = - FIRST

 =

    = - The Open Group

 =

    = - ISO/IEC

 =

    = - W3C

 =

    = - OASIS

 =

    = - OMG

 =

    = - NIST

 =

    = - MITRE

 =

    = - 3GPP

 =

    = It's up to the IESG to decide if we should list these (or some of them)

 =

    = explicitly, or we should leave to the WG after its formation is=

    = approved to

 =

    = initiate communication and invite participation.

 =

    = Regards,

 =

    = Dan

 =

    =      -----Original Message-----

 =

    =      From: Sean Turner [mailto:turners@ieca.com]

 =

    =      Sent: Tuesday, June 25, 2013 3:47 PM

 =

    =      To: Romascanu, Dan (Dan)

 =

    =      Cc: tony@yaanatech.com <mailto:ton= y@yaanatech.com>; Adam

    =      Montville; Stephen Hanna; Moriarty,

 =

    =      Kathleen; sacm@ietf.org <mailto:sacm@ietf.org= >

 =

    =      Subject: Re: [sacm] sacm charter review=

 =

    =      At this point 3 ADs have asked about what other SD= Os are involved.

 =

    =      I'm not sure if they want names in the charter or = if they're just

 =

    =      interested in knowing.

 =

    =      spt

 =

    =      On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote:

 =

    =      > The proposed text in the charter already says= :

 =

    =      >

 =

    =      >> In accordance with existing IETF processe= s, the group will

 =

    =      >> communicate with and

 =

    =      > invite participation from other relevant stan= dards bodies and

 =

    =      > regulatory organizations, and if necessary re= use existing liaison

 =

    =      > relationships or request the establishment of= new liaison

 =

    =      relationships.

 =

    =      >

 =

    =      > 'standard bodies and regulatory organizations= ' are neutral terms

 =

    =      enough IMO, as Sean says we should not enter the '= what is an SDO

 =

    =      dispute'. We are dealing not only with standards o= rganizations and

 =

    =      this is also reflected in the current text.

 =

    =      >

 =

    =      > Regards,

 =

    =      >

 =

    =      > Dan

 =

    =      >

 =

    =      >

 =

    =      >

 =

    =      >

 =

    =      >

 =

    =      >> -----Original Message-----

 =

    =      [mailto:s= acm-bounces@ietf.org] On

 =

    =      >> Behalf Of Sean Turner

 =

    =      >> Sent: Tuesday, June 25, 2013 2:06 AM=

 =

 =

    =      >> Cc: Moriarty, Kathleen; Stephen Hanna; Ad= am Montville;

 =

    =      >>sacm@ietf= .org <mailto:sacm@ietf.org><= o:p>

 =

    =      >> Subject: Re: [sacm] sacm charter review

 =

    =      >>

 =

    =      >> On 6/24/13 12:47 PM, Tony Rutkowski wrote= :

 =

    =      >>> SDO is an undesirable legacy term.

 =

    =      >>> Pathetically, the old SDO club still = does not regard the IETF as a

 =

    =      >>> "SDO!"

 =

 =

    =      >>> ue

 =

    =      >>> .j

 =

    =      >>> sp

 =

    =      >>>

 =

    =      >>> Perhaps it is better to simply use &q= uot;standards fora."

 =

    =      >>

 =

    =      >> I'm not against just saying organization = too.  I don't want to get

 =

    =      >> in to arguments about what's an SDO and w= hat's not.

 =

    =      >>

 =

    =      >> spt

 =

    =      >>

 =

    =      >>> You should consider including: NIST, = MITRE, and 3GPP - all of

 =

    =      >>> which are well recognized as key stan= dards bodies currently

 =

    =      >>> engaged in SACM related work with who= m you should be interested now.

 =

    =      >>>

 =

    =      >>> -t

 =

    =      >>>

 =

    =      >>> On 6/24/2013 11:52 AM, Adam Montville= wrote:

 =

    =      >>>> There are a variety of other SDOs= in which we could be interested

 =

    =      >>>> now or in the future.  = The short-story list:

 =

    =      >>>>

 =

    =      >>>> * FIRST (vulnerability scoring)

 =

    =      >>>> * DMTF (already mentioned)

 =

    =      >>>> * TCG (already mentioned)

 =

    =      >>>> * The Open Group (XDAS and others= )

 =

    =      >>>> * ISO (i.e. TagVault)<= /span>

 =

    =      >>>> * W3C (i.e. obvious things like X= ML DigSig, and potentially less

 =

    =      >>>> obvious things like RDF, OWL, SWR= L, etc.)

 =

    =      >>>> * OASIS (i.e. security assertions= , key management, alerting)

 =

    =      >>>> * OMG (i.e. Business Process Mode= l Notation and/or Execution

 =

    =      >>>> Language,

 =

    =      >>>> etc.)

 =

    =      >>>

 =

    =      >>>

 =

    =      >> _________________________________________= ______

 =

    =      >> sacm mailing list

 =

    =      >>sacm@ietf= .org <mailto:sacm@ietf.org><= o:p>

 =

 =

    =      > _____________________________________________= __

 =

    =      > sacm mailing list

 =

    =      >sacm@ietf.org= <mailto:sacm@ietf.org>=

 =

 =

    =      >

 =

    = _______________________________________________

 =

    = sacm mailing list

 =

 =

 =

    = _______________________________________________

 =

    = sacm mailing list

 =

 =

 =

    = ...

 =

    = 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 not= ify

    = the sender immediately and permanently delete the message and any

    = attachments.

 =

    = _______________________________________________

 =

    = sacm mailing list

 =

 =

 =

________________________= _______________________

sacm mailing list

 =

--_000_F1DFC16DCAA7D3468651A5A776D5796E1AA51D5ESN2PRD0510MB372_-- From turners@ieca.com Wed Jun 26 07:23:38 2013 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 A569C1F0D3B for ; Wed, 26 Jun 2013 07:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 r6YCgcyTdeSA for ; Wed, 26 Jun 2013 07:23:33 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.41.245.8]) by ietfa.amsl.com (Postfix) with ESMTP id 009761F0D39 for ; Wed, 26 Jun 2013 07:23:32 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id E8ED07324CE76; Wed, 26 Jun 2013 09:23:05 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id B089B7324CDA7 for ; Wed, 26 Jun 2013 09:23:05 -0500 (CDT) Received: from [173.73.135.101] (port=63146 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Urqcn-0002sj-QY; Wed, 26 Jun 2013 09:23:10 -0500 Message-ID: <51CAF94D.2040105@ieca.com> Date: Wed, 26 Jun 2013 10:23:09 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Hanna References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:63146 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Waltermire, David A." , "sacm@ietf.org" , "Kent_Landfield@McAfee.com" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 14:23:38 -0000 Everybody is going to be on equal footing when we start. We're going to do use cases, requirements, and architecture and then figure out what makes sense to use, modify, or develop. spt On 6/26/13 9:53 AM, Stephen Hanna wrote: > TCG has eight years of experience developing widely deployed endpoint > assessment protocols and a proven track record of contributing our > protocols to IETF under the IETF’s standard terms. For example, we > contributed the TNC client-server protocols to IETF as Internet-Drafts. > They have been adopted by the NEA working group, revised, and published > as Proposed Standard RFCs. The TCG standards are very relevant to the > SACM work, even beyond the NEA specs. For example, IF-MAP is an > excellent protocol for gathering endpoint assessment results across a > variety of endpoint assessment technologies. Also, TCG has been > represented in the SACM work since the very start. > > I believe that TCG should stand on equal footing with NIST and MITRE in > this matter. > > Thanks, > > Steve > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Waltermire, David A. > *Sent:* Wednesday, June 26, 2013 9:02 AM > *To:* Kent_Landfield@McAfee.com; turners@ieca.com; sacm@ietf.org > *Subject:* Re: [sacm] sacm charter review > > I mentioned this work because it does align with some of the tentative > requirements and use cases that have been floated. There is a potential > for liaison with these orgs. Even for the NIST and MITRE work, we have > options to reference it in place or bring the work in. You could say > the same thing for TCG and OpenGroup efforts. It is too early to decide > one way or another right now as we still have work to do on the use > cases, requirements, and architecture documents. The determining factor > will be if changes need to be made to the existing work and if the orgs > are willing to make a contribution. If it is referenced, this will drive > the liaison decision. If the work needs to brought in, then all of what > you said about IPR would apply. > > Dave > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com > > *Sent:* Wednesday, June 26, 2013 8:45 AM > *To:* Waltermire, David A.; turners@ieca.com ; > sacm@ietf.org > *Subject:* Re: [sacm] sacm charter review > > Hi Dave, > > I assumed that MILE and NEA were already identified from charter > references and was looking at only organizations external to the IETF. > Individuals from the organizations I listed either are or have had > active discussions to contribute to the proposed WG. I am not sure > initially we are talking about TCG related work. Yes, it could be > possible but that is up to the TCG to contribute their work into the > group as a proposal. Same for O-ACEML. Those proposals need to fit the > proposed charter and be made to the working group itself. If they are > making proposals for work items to the SACM WG then they would be > following the IETF IPR rules for documents contributed. The key here is > that the work would be done in SACM and should not be duplicating work > elsewhere. > > I guess I need clarity from Sean. I was looking at what organizations > would be directly working with the SACM initially. Liaison or otherwise. > I fully expect we would invite others to participate in SACM. I > personally plan on trying to assure all are aware of the SACM efforts > and goals. Developing a list of who to invite is different from the > perspective I responded with. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, David Waltermire > > *Date: *Wednesday, June 26, 2013 2:23 PM > *To: *Kent Landfield >, Sean Turner >, "sacm@ietf.org " > > > *Subject: *RE: [sacm] sacm charter review > > We may want to bring in updates of the existing NEA protocols and/or > new work created within the TCG. We may also want to consider > O-ACEML from the OpenGroup. These have been discussed as options on > the list and during the BoFs. > > Dave > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > *Sent:* Wednesday, June 26, 2013 8:11 AM > *To:* turners@ieca.com ; sacm@ietf.org > > *Subject:* Re: [sacm] sacm charter review > > From my perspective the initial organizations we will be dealing > with are > > - ISO/IEC > > - NIST > > - MITRE > > *Kent Landfield* > > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *Sean Turner > > *Date: *Wednesday, June 26, 2013 1:56 PM > *To: *"sacm@ietf.org " > > *Subject: *Re: [sacm] sacm charter review > > It looks like Joel wants to know now some of the organizations > (i.e., > > there's block on the charter). Can we whittle this list down to > just > > orgs we're going to be dealing with at the initial stages? For > asset > > identification it's possibly going to be ISO+NIST+?, for endpoint > > elements to assess it's ?, for comparison it's ?, for > interacting with > > repositories it's NEA. > > More inline. > > On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: > > Yes. The fact that other organizations are interested in the > scope of > > SACM does not mean that they do the same work, and certainly > the future > > WG must avoid duplication. Maybe we should make this > explicit. For example: > > OLD: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to make of > this document an > > Informational RFC, but this is not a mandatory deliverable. > > NEW: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to refer or > document > > these in > > An Informational RFC, but this is not a mandatory > deliverable. The > > working group > > will not duplicate work already done or in progress in other > places. > > We were on the same wavelength. I'm not sure we need to > repeated the we > > won't duplicate work because there's already a blurb about > reuse. What > > I proposed to Barry/Joel/Spencer: > > OLD: > > The working group will create an overview of related standards work > > Internet-Draft which will document existing work in the IETF or > in other > > SDOs which can be used as-is or as a starting point for developing > > solutions to the SACM requirements. > > NEW: > > The working group will create an Internet-Draft documenting the > existing > > work in the IETF and in other organizations that might > > be used as-is or as a starting point for developing solutions to > > the SACM requirements. > > OLD: > > In accordance with existing IETF processes, the group will > communicate > > with and invite participation from other relevant standards > bodies and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > NEW: > > In accordance with existing IETF processes, the working group will > > communicate with and invite participation from other relevant > groups and > > regulatory organizations, and if necessary reuse existing liaison > > relationships or request the establishment of new liaison > relationships. > > Regards, > > Dan > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf > > Of *Michael Hammer > > *Sent:* Tuesday, June 25, 2013 6:41 PM > > *To:* Kent_Landfield@McAfee.com > ; > Adam.Montville@cisecurity.org > ; > > dbharrington@comcast.net ; > turners@ieca.com ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > +1 This just means many groups are interested in the same > scope. > > Mike > > *From:*sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > > > > *Sent:* Tuesday, June 25, 2013 8:24 AM > > *To:* Adam.Montville@cisecurity.org > > > ; > dbharrington@comcast.net > > ; turners@ieca.com > > > ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > Well said Adam. I totally agree with your comments. > > *Kent Landfield* > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > *From: *Adam Montville > > > > > > *Date: *Tuesday, June 25, 2013 5:15 PM > > *To: *David Harrington > > > >, Sean Turner > > > >, > "sacm@ietf.org > " > > > > > > *Subject: *Re: [sacm] sacm charter review > > Hi David, > > I respectfully disagree. > > While this may be a commentary on the potential, > eventual reach of > > SACM, our charter's scope is far reduced from > including all of these > > organizations at the outset. In other words, our > scope is limited > > by the language in the charter, against which this > list really has > > no bearing other than to satisfy curiosity and, > perhaps, lend some > > vision to the future. > > In fact, it might be more properly construed that this > list of > > organizations is a commentary on the ubiquitous nature > of assessment > > - it is a capability that "touches" a lot of different > areas, which > > is precisely why it warrants its own working group, IMO. > > Regards, > > Adam > > ________________________________________ > > From: sacm-bounces@ietf.org > > > [sacm-bounces@ietf.org > > ] on behalf of > > David Harrington [dbharrington@comcast.net > > > > ] > > Sent: Tuesday, June 25, 2013 6:43 AM > > To: 'Sean Turner'; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > Wow! > > I think this is an excellent commentary on the scope > of SACM being > > way too > > broad, and poorly scoped for engineering purposes. > > David Harrington > > dbharrington@comcast.net > > > +1-603-828-1401 > > -----Original Message----- > > From: sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Romascanu, Dan (Dan) > > Sent: Tuesday, June 25, 2013 9:18 AM > > To: Sean Turner > > Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville; > sacm@ietf.org > > ; > > tony@yaanatech.com > > > Subject: Re: [sacm] sacm charter review > > Hi Sean, > > A list of organizations that are involved in the area, > as identified > > in this > > discussion includes: > > - TCG > > - DMTF > > - FIRST > > - The Open Group > > - ISO/IEC > > - W3C > > - OASIS > > - OMG > > - NIST > > - MITRE > > - 3GPP > > It's up to the IESG to decide if we should list these > (or some of them) > > explicitly, or we should leave to the WG after its > formation is > > approved to > > initiate communication and invite participation. > > Regards, > > Dan > > -----Original Message----- > > From: Sean Turner [mailto:turners@ieca.com] > > Sent: Tuesday, June 25, 2013 3:47 PM > > To: Romascanu, Dan (Dan) > > Cc: tony@yaanatech.com > ; Adam > > Montville; Stephen Hanna; Moriarty, > > Kathleen; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > At this point 3 ADs have asked about what other > SDOs are involved. > > I'm not sure if they want names in the charter or > if they're just > > interested in knowing. > > spt > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > > The proposed text in the charter already says: > > > > > >> In accordance with existing IETF processes, the > group will > > >> communicate with and > > > invite participation from other relevant > standards bodies and > > > regulatory organizations, and if necessary reuse > existing liaison > > > relationships or request the establishment of > new liaison > > relationships. > > > > > > 'standard bodies and regulatory organizations' > are neutral terms > > enough IMO, as Sean says we should not enter the > 'what is an SDO > > dispute'. We are dealing not only with standards > organizations and > > this is also reflected in the current text. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From:sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] On > > >> Behalf Of Sean Turner > > >> Sent: Tuesday, June 25, 2013 2:06 AM > > >> To:tony@yaanatech.com > > > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam > Montville; > > >>sacm@ietf.org > > > >> Subject: Re: [sacm] sacm charter review > > >> > > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > >>> SDO is an undesirable legacy term. > > >>> Pathetically, the old SDO club still does not > regard the IETF as a > > >>> "SDO!" > > > >>>http://www.tta.or.kr/English/new/external_relations/gsc17_communiq > > >>> ue > > >>> .j > > >>> sp > > >>> > > >>> Perhaps it is better to simply use "standards > fora." > > >> > > >> I'm not against just saying organization > too. I don't want to get > > >> in to arguments about what's an SDO and what's not. > > >> > > >> spt > > >> > > >>> You should consider including: NIST, MITRE, > and 3GPP - all of > > >>> which are well recognized as key standards > bodies currently > > >>> engaged in SACM related work with whom you > should be interested now. > > >>> > > >>> -t > > >>> > > >>> On 6/24/2013 11:52 AM, Adam Montville wrote: > > >>>> There are a variety of other SDOs in which we > could be interested > > >>>> now or in the future. The short-story list: > > >>>> > > >>>> * FIRST (vulnerability scoring) > > >>>> * DMTF (already mentioned) > > >>>> * TCG (already mentioned) > > >>>> * The Open Group (XDAS and others) > > >>>> * ISO (i.e. TagVault) > > >>>> * W3C (i.e. obvious things like XML DigSig, > and potentially less > > >>>> obvious things like RDF, OWL, SWRL, etc.) > > >>>> * OASIS (i.e. security assertions, key > management, alerting) > > >>>> * OMG (i.e. Business Process Model Notation > and/or Execution > > >>>> Language, > > >>>> etc.) > > >>> > > >>> > > >> _______________________________________________ > > >> 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 > > ... > > 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. > > _______________________________________________ > > 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 Jun 26 07:49:16 2013 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 B1BA711E811B for ; Wed, 26 Jun 2013 07:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 GpEBzNusM96m for ; Wed, 26 Jun 2013 07:49:10 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.65.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8E82321E8090 for ; Wed, 26 Jun 2013 07:49:05 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 1508E47548C01; Wed, 26 Jun 2013 09:49:03 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 098E947548BDA for ; Wed, 26 Jun 2013 09:49:03 -0500 (CDT) Received: from [173.73.135.101] (port=63392 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Urr1p-0005Sv-Sm for sacm@ietf.org; Wed, 26 Jun 2013 09:49:01 -0500 Message-ID: <51CAFF5D.1020008@ieca.com> Date: Wed, 26 Jun 2013 10:49:01 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:63392 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 15 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] more sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 14:49:16 -0000 Not sure if everybody wants to see all of this back and forth, but I thought it would be useful for the list to know what my fellow ADs are thinking. Pete had a question about why we have three informational drafts when it would probably make sense to do all three in one draft and that the architecture draft should be standards track. As I told him, I see no sword to fall on here so I'd like to adopt this change: OLD: - An Informational document on Use Cases - An Informational document on Requirements - An Informational document on SACM Architecture NEW: - A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. This may be a single standards-track document, or may be split up as the WG sees fit. spt From Kent_Landfield@mcafee.com Wed Jun 26 07:57:31 2013 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 832AD21E80C0 for ; Wed, 26 Jun 2013 07:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9reHWxpGh3la for ; Wed, 26 Jun 2013 07:57:24 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCAF21F9958 for ; Wed, 26 Jun 2013 07:57:15 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 6c74_245a_af8bb0aa_4219_4e50_849b_061c79b880f6; Wed, 26 Jun 2013 09:57:04 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER1N2.corp.nai.org ([169.254.3.103]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 10:55:54 -0400 From: To: , Thread-Topic: [sacm] more sacm charter review Thread-Index: AQHOcnxXdylatv5Q/Um2X3/g8MMkaplIehyA Date: Wed, 26 Jun 2013 14:55:53 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2B6E22@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <51CAFF5D.1020008@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2B6E22MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] more sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 14:57:31 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2B6E22MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This makes sense to me. I too see no real reason they could not be done in = a single document. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Sean Turner > Date: Wednesday, June 26, 2013 4:49 PM To: "sacm@ietf.org" > Subject: [sacm] more sacm charter review Not sure if everybody wants to see all of this back and forth, but I thought it would be useful for the list to know what my fellow ADs are thinking. Pete had a question about why we have three informational drafts when it would probably make sense to do all three in one draft and that the architecture draft should be standards track. As I told him, I see no sword to fall on here so I'd like to adopt this change: OLD: - An Informational document on Use Cases - An Informational document on Requirements - An Informational document on SACM Architecture NEW: - A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. This may be a single standards-track document, or may be split up as the WG sees fit= . spt _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF2B6E22MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: <69EE7492EDD1FE4BA2289280BDB91086@McAfee.com> Content-Transfer-Encoding: quoted-printable

From: Sean Turner <turners@ieca.com>
Date: Wednesday, June 26, 2013 4:49= PM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: [sacm] more sacm charter r= eview

Not sure if everybody wants to see all of this back and forth, but I <= /div>
thought it would be useful for the list to know what my fellow ADs are=
thinking.

Pete had a question about why we have three informational drafts when = it
would probably make sense to do all three in one draft and that the
architecture draft should be standards track.  As I told him= , I see no
sword to fall on here so I'd like to adopt this change:

OLD:

- An Informational document on Use Cases
- An Informational document on Requirements
- An Informational document on SACM Architecture

NEW:

- A document or documents describing the SACM Architecture. This will =
include protocol requirements and their associated use cases as well a= s
a description of how SACM protocols fit together into a system. This m= ay
be a single standards-track document, or may be split up as the WG see= s fit.

spt
_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2B6E22MIVEXAMER1N1corpn_-- From david.waltermire@nist.gov Wed Jun 26 08:01:20 2013 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 E9EBF21F9A03 for ; Wed, 26 Jun 2013 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 MPU04ClnYevp for ; Wed, 26 Jun 2013 08:01:13 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id CF89E21F9948 for ; Wed, 26 Jun 2013 08:01:12 -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.3.123.3; Wed, 26 Jun 2013 11:00:54 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 26 Jun 2013 11:01:10 -0400 From: "Waltermire, David A." To: Sean Turner , "sacm@ietf.org" Date: Wed, 26 Jun 2013 11:01:09 -0400 Thread-Topic: [sacm] more sacm charter review Thread-Index: Ac5yfFc1uq2GArNkRtet4ErGha1+ogAAWa9Q Message-ID: References: <51CAFF5D.1020008@ieca.com> In-Reply-To: <51CAFF5D.1020008@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] more sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:01:21 -0000 +1. The content is more important than how it is parsed out. I don't feel strongly either way as long as we can clearly articulate what we need to. Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Wednesday, June 26, 2013 10:49 AM > To: sacm@ietf.org > Subject: [sacm] more sacm charter review > > Not sure if everybody wants to see all of this back and forth, but I thought it > would be useful for the list to know what my fellow ADs are thinking. > > Pete had a question about why we have three informational drafts when it > would probably make sense to do all three in one draft and that the > architecture draft should be standards track. As I told him, I see no sword to > fall on here so I'd like to adopt this change: > > OLD: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > > NEW: > > - A document or documents describing the SACM Architecture. This will > include protocol requirements and their associated use cases as well as a > description of how SACM protocols fit together into a system. This may be a > single standards-track document, or may be split up as the WG sees fit. > > spt > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Wed Jun 26 08:03:22 2013 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 4D2B411E81C5 for ; Wed, 26 Jun 2013 08:03:22 -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 WuuDKJW4ILWm for ; Wed, 26 Jun 2013 08:03:17 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id 80D6421F9A03 for ; Wed, 26 Jun 2013 08:03:17 -0700 (PDT) X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-12.tower-171.messagelabs.com!1372258995!3506196!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 16530 invoked from network); 26 Jun 2013 15:03:16 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-12.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2013 15:03:16 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 11:03:00 -0400 From: Adam Montville To: "Waltermire, David A." , Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] more sacm charter review Thread-Index: AQHOcnxO5CNbF0rpD0W4inNt+sEBeZlIWhCA//+9cSU= Date: Wed, 26 Jun 2013 15:03:01 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67022E9@CISEXCHANGE1.msisac.org.local> References: <51CAFF5D.1020008@ieca.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] more sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:03:22 -0000 +1=20 ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Waltermir= e, David A. [david.waltermire@nist.gov] Sent: Wednesday, June 26, 2013 8:01 AM To: Sean Turner; sacm@ietf.org Subject: Re: [sacm] more sacm charter review +1. The content is more important than how it is parsed out. I don't fee= l strongly either way as long as we can clearly articulate what we need to= . Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Wednesday, June 26, 2013 10:49 AM > To: sacm@ietf.org > Subject: [sacm] more sacm charter review > > Not sure if everybody wants to see all of this back and forth, but I tho= ught it > would be useful for the list to know what my fellow ADs are thinking. > > Pete had a question about why we have three informational drafts when it= > would probably make sense to do all three in one draft and that the > architecture draft should be standards track. As I told him, I=20see no= sword to > fall on here so I'd like to adopt this change: > > OLD: > > - An Informational document on Use Cases > - An Informational document on Requirements > - An Informational document on SACM Architecture > > NEW: > > - A document or documents describing the SACM Architecture. This will > include protocol requirements and their associated use cases as well as = a > description of how SACM protocols fit together into a system. This may b= e a > single standards-track document, or may be split up as the WG sees fit. > > spt > _______________________________________________ > 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 ... 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 dromasca@avaya.com Wed Jun 26 08:05:14 2013 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 411D021E8131 for ; Wed, 26 Jun 2013 08:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8tj5P77Yrop for ; Wed, 26 Jun 2013 08:05:08 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B68B221E8126 for ; Wed, 26 Jun 2013 08:05:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALUCy1HGmAcF/2dsb2JhbABagmghMUm+e4EAFnSCIwEBAQEDAQEBDyg0FwQCAQgNBAEDAQELFAkHJwsUAwYIAgQBEggah2wBC55Rm28TBI8aOAaCfGEDngmLAYMRgig X-IronPort-AV: E=Sophos;i="4.87,944,1363147200"; d="scan'208";a="17832523" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 Jun 2013 11:05:07 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jun 2013 11:02:44 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 11:05:05 -0400 From: "Romascanu, Dan (Dan)" To: Adam Montville , "Waltermire, David A." , Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] more sacm charter review Thread-Index: AQHOcnxj4iGD/csKskeIw/n3aRWAK5lH9XuAgABlGoD//70yUA== Date: Wed, 26 Jun 2013 15:05:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1B277D@AZ-FFEXMB04.global.avaya.com> References: <51CAFF5D.1020008@ieca.com>, <05BCCEB107AF88469B9F99783D47C1D67022E9@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D67022E9@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] more sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:05:14 -0000 +1=20 The content is what matters, more flexibility in structuring the documents = is better.=20 Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Wednesday, June 26, 2013 6:03 PM > To: Waltermire, David A.; Sean Turner; sacm@ietf.org > Subject: Re: [sacm] more sacm charter review >=20 > +1 > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of > Waltermire, David A. [david.waltermire@nist.gov] > Sent: Wednesday, June 26, 2013 8:01 AM > To: Sean Turner; sacm@ietf.org > Subject: Re: [sacm] more sacm charter review >=20 > +1. The content is more important than how it is parsed out. I don't > feel strongly either way as long as we can clearly articulate what we > need to. >=20 > Dave >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Sean Turner > > Sent: Wednesday, June 26, 2013 10:49 AM > > To: sacm@ietf.org > > Subject: [sacm] more sacm charter review > > > > Not sure if everybody wants to see all of this back and forth, but I > > thought it would be useful for the list to know what my fellow ADs are > thinking. > > > > Pete had a question about why we have three informational drafts when > > it would probably make sense to do all three in one draft and that the > > architecture draft should be standards track. As I told him, I see no > > sword to fall on here so I'd like to adopt this change: > > > > OLD: > > > > - An Informational document on Use Cases > > - An Informational document on Requirements > > - An Informational document on SACM Architecture > > > > NEW: > > > > - A document or documents describing the SACM Architecture. This will > > include protocol requirements and their associated use cases as well > > as a description of how SACM protocols fit together into a system. > > This may be a single standards-track document, or may be split up as > the WG sees fit. > > > > spt > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... >=20 > 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. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Wed Jun 26 08:14:30 2013 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 22F6B21E8085 for ; Wed, 26 Jun 2013 08:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVLdS6oYeY+W for ; Wed, 26 Jun 2013 08:14:25 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5511E811A for ; Wed, 26 Jun 2013 08:14:25 -0700 (PDT) X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-7.tower-171.messagelabs.com!1372259663!19611558!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 27844 invoked from network); 26 Jun 2013 15:14:24 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-7.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2013 15:14:24 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 11:14:08 -0400 From: Adam Montville To: Sean Turner , Stephen Hanna Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh2rk93O9jxYkmrJ3EeM8R9BZlFMPAAgAACywD//87U8IAAU/IAgABpi4CAAJdzAIAATgCAgAAInQCAAAcIAP//1J+wgABHsQCAAASsAIABGvGAgAA4vYCAAAPkgIAAA36AgAAGB4CAAATeAIAADkqAgAAIW4D//8kFGA== Date: Wed, 26 Jun 2013 15:14:09 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D670230B@CISEXCHANGE1.msisac.org.local> References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> , <51CAF94D.2040105@ieca.com> In-Reply-To: <51CAF94D.2040105@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Kent_Landfield@McAfee.com" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:14:30 -0000 Has the original ask from Sean been addressed (whittle down the list)? =20= Here's the way I see it...which could be off the wall. The sole focus of the WG, if established, would be to focus on the narrowe= d cases we've previously discussed, which is essentially how do we cart ar= ound data formats that already exist and how do we improve those data form= ats. The data formats come from few places, really: NIST, MITRE, FIRST. Novel = work in the area of protocols for carting data formats around will come fr= om the established WG and other IETF work (i.e. MILE, NEA). To me, this is the primary area of focus - we need to solve these "base ca= ses" before we can reasonably consider doing anything more advanced. So, to address what might be the blocking concern, can we agree on an init= ial, non-IETF list of: NIST, MITRE, and FIRST? This with the understandin= g that most, if not all, of that work can be referenced and/or brought int= o the established WG "free and clear" of IPR issues. For example, I imagi= ne Asset Identification can be brought in without liaison relationships be= ing required. I know that this can be an uncomfortable discussion, but it's one that see= ms required to get the WG established. The fact that we're blocked right = now doesn't concern me as much given the nature of the blocking comment, w= hich indicates that a real-time discussion is needed during the 6/27 call.= Looking at this effort from the outside, I would probably want that as w= ell. Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Sean Turn= er [turners@ieca.com] Sent: Wednesday, June 26, 2013 7:23 AM To: Stephen Hanna Cc: Waltermire, David A.; sacm@ietf.org; Kent_Landfield@McAfee.com Subject: Re: [sacm] sacm charter review Everybody is going to be on equal footing when we start. We're going to do use cases, requirements, and architecture and then figure out what makes sense to use, modify, or develop. spt On 6/26/13 9:53 AM, Stephen Hanna wrote: > TCG has eight years of experience developing widely deployed endpoint > assessment protocols and a proven track record of contributing our > protocols to IETF under the IETF=92s standard terms. For example, we > contributed the TNC client-server protocols to IETF as Internet-Drafts. > They have been adopted by the NEA working group, revised, and published > as Proposed Standard RFCs. The TCG standards are very relevant to the > SACM work, even beyond the NEA specs. For example, IF-MAP is an > excellent protocol for gathering endpoint assessment results across a > variety of endpoint assessment technologies. Also, TCG has been > represented in the SACM work since the very start. > > I believe that TCG should stand on equal footing with NIST and MITRE in > this matter. > > Thanks, > > Steve > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Waltermire, David A. > *Sent:* Wednesday, June 26, 2013 9:02 AM > *To:* Kent_Landfield@McAfee.com; turners@ieca.com; sacm@ietf.org > *Subject:* Re: [sacm] sacm charter review > > I mentioned this work because it does align with some of the tentative > requirements and use cases that have been floated. There is a potential= > for liaison with these orgs. Even for the NIST and MITRE work, we have > options to reference it in place or bring the work in. You could say > the same thing for TCG and OpenGroup efforts. It is too early to decide= > one way or another right now as we still have work to do on the use > cases, requirements, and architecture documents. The determining factor > will be if changes need to be made to the existing work and if the orgs > are willing to make a contribution. If it is referenced, this will drive= > the liaison decision. If the work needs to brought in, then all of what > you said about IPR would apply. > > Dave > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of *Kent_Landfield@McAfee.com > > *Sent:* Wednesday, June 26, 2013 8:45 AM > *To:* Waltermire, David A.; turners@ieca.com ; > sacm@ietf.org > *Subject:* Re: [sacm] sacm charter review > > Hi Dave, > > I assumed that MILE and NEA were already identified from charter > references and was looking at only organizations external to the IETF. > Individuals from the organizations I listed either are or have had > active discussions to contribute to the proposed WG. I am not sure > initially we are talking about TCG related work. Yes, it could be > possible but that is up to the TCG to contribute their work into the > group as a proposal. Same for O-ACEML. Those proposals need to fit the > proposed charter and be made to the working group itself. If they are > making proposals for work items to the SACM WG then they would be > following the IETF IPR rules for documents contributed. The key here is > that the work would be done in SACM and should not be duplicating work > elsewhere. > > I guess I need clarity from Sean. I was looking at what organizations > would be=20directly working with the SACM initially. Liaison or otherwis= e. > I fully expect we would invite others to participate in SACM. I > personally plan on trying to assure all are aware of the SACM efforts > and goals. Developing a list of who to invite is different from the > perspective I responded with. > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, David Waltermire > > *Date: *Wednesday, June 26, 2013 2:23 PM > *To: *Kent Landfield >, Sean Turner >, "sacm@ietf.org " > > > *Subject: *RE: [sacm] sacm charter review > > We may want to bring in updates of the existing NEA protocols and/or= > new work created within the TCG. We may also want to consider > O-ACEML from the OpenGroup. These have been discussed as options on > the list and during the BoFs. > > Dave > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > *Sent:* Wednesday, June 26, 2013 8:11 AM > *To:* turners@ieca.com ; sacm@ietf.org > > *Subject:* Re: [sacm] sacm charter review > > From my perspective the initial organizations we will be dealing > with are > > - ISO/IEC > > - NIST > > - MITRE > > *Kent Landfield* > > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *Sean Turner > > *Date: *Wednesday, June 26, 2013 1:56 PM > *To: *"sacm@ietf.org " > > *Subject: *Re: [sacm] sacm charter review > > It looks like Joel wants to know now some of the organizations > (i.e., > > there's block on the charter). Can we whittle this list down to= > just > > orgs we're going to be dealing with at the initial stages? For > asset > > identification it's possibly going to be ISO+NIST+?, for endpoin= t > > elements to assess it's ?, for comparison it's ?, for > interacting with > > repositories it's NEA. > > More inline. > > On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: > > Yes. The fact that other organizations are interested in the= > scope of > > SACM does not mean that they do the same work, and certainly= > the future > > WG must avoid duplication. Maybe we should make this > explicit. For example: > > OLD: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF= > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to make of > this document an > > Informational RFC, but this is not a mandatory deliverable. > > NEW: > > The working group will create an overview of related > standards work > > Internet-Draft which will document existing work in the IETF= > or in other > > SDOs > > which can be used as-is or as a starting point for > developing solutions > > to the > > SACM requirements. The working group may decide to refer or > document > > these in > > An Informational RFC, but this is not a mandatory > deliverable. The > > working group > > will not duplicate work already done or in progress in other= > places. > > We were on the same wavelength. I'm not sure we need to > repeated the we > > won't duplicate work because there's already a blurb about > reuse. What > > I proposed to Barry/Joel/Spencer: > > OLD: > > The working group will create an overview of related standards w= ork > > Internet-Draft which will document existing work in the IETF or > in other > > SDOs which can be used as-is or as a starting point for developi= ng > > solutions to the SACM requirements. > > NEW: > > The working group will create an Internet-Draft documenting the > existing > > work in the IETF and in other organizations that might > > be used as-is or as a starting point for developing solutions to= > > the SACM requirements. > > OLD: > > In accordance with existing IETF processes, the group will > communicate > > with and invite participation from other relevant standards > bodies and > > regulatory organizations, and if necessary reuse existing liaiso= n > > relationships or request the establishment of new liaison > relationships. > > NEW: > > In accordance with existing IETF processes, the working group wi= ll > > communicate with and invite participation from other relevant > groups and > > regulatory organizations, and if necessary reuse existing liaiso= n > > relationships or request the establishment of new liaison > relationships. > > Regards, > > Dan > > *From:*sacm-bounces@ietf.org = > [mailto:sacm-bounces@ietf.org] *On Behalf > > Of *Michael Hammer > > *Sent:* Tuesday, June 25, 2013 6:41 PM > > =20 *To:* Kent_Landfield@McAfee.com > ; > Adam.Montville@cisecurity.org > ; > > dbharrington@comcast.net ; > turners@ieca.com ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > +1 This just means many groups are interested in the same > scope. > > Mike > > *From:*sacm-bounces@ietf.org = > > > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > > > > *Sent:* Tuesday, June 25, 2013 8:24 AM > > *To:* Adam.Montville@cisecurity.org > > > =20 ; > dbharrington@comcast.net > > ; turners@ieca.com > > > ; sacm@ietf.org > > > *Subject:* Re: [sacm] sacm charter review > > Well said Adam. I totally agree with your comments. > > *Kent Landfield* > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > *From: *Adam Montville > > > > > > *Date: *Tuesday, June 25, 2013 5:15 PM > > *To: *David Harrington > > > >, Sean Turner > > > >, > "sacm@ietf.org = > " > > = > > > > *Subject: *Re: [sacm] sacm charter review > > Hi David, > > I respectfully disagree. > > While this may be a commentary on the potential, > eventual reach of > > SACM, our charter's scope is far reduced from > including all of these > > organizations at the outset. In other words, our > scope is limited > > by the language in the charter, against which this > list really has > > no bearing other than to satisfy curiosity and, > perhaps, lend some > > vision to the future. > > In fact, it might be more properly construed that this= > list of > > organizations is a commentary on the ubiquitous nature= > of assessment > > - it is a capability that "touches" a lot of different= > areas, which > > is precisely why it warrants its own working group, IM= O. > > Regards, > > Adam > > ________________________________________ > > From: sacm-bounces@ietf.org > > > [sacm-bounces@ietf.org > > ] on behalf of > > David Harrington [dbharrington@comcast.net > > > > ] > > Sent: Tuesday, June 25, 2013 6:43 AM > > To: 'Sean Turner'; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > Wow! > > I think this is an excellent commentary on the scope > of SACM being > > way too > > broad, and poorly scoped for engineering purposes. > > David Harrington > > dbharrington@comcast.net > > > +1-603-828-1401 > > -----Original Message----- > > From: sacm-bounces@ietf.org > =20 > > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Romascanu, Dan (Dan) > > Sent: Tuesday, June 25, 2013 9:18 AM > > To: Sean Turner > > Cc: Moriarty, Kathleen; Stephen Hanna; Adam Montville;= > sacm@ietf.org > > ; > > tony@yaanatech.com > > > Subject: Re: [sacm] sacm charter review > > Hi Sean, > > A list of organizations that are involved in the area,= > as identified > > in this > > discussion includes: > > - TCG > > - DMTF > > - FIRST > > - The Open Group > > - ISO/IEC > > - W3C > > =20 - OASIS > > - OMG > > - NIST > > - MITRE > > - 3GPP > > It's up to the IESG to decide if we should list these > (or some of them) > > explicitly, or we should leave to the WG after its > formation is > > approved to > > initiate communication and invite participation. > > Regards, > > Dan > > -----Original Message----- > > From: Sean Turner [mailto:turners@ieca.com] > > Sent: Tuesday, June 25, 2013 3:47 PM > > To: Romascanu, Dan (Dan) > > Cc: tony@yaanatech.com = > ; Adam > > Montville; Stephen Hanna; Moriarty, > > Kathleen; sacm@ietf.org > > > Subject: Re: [sacm] sacm charter review > > At this point 3 ADs have asked about what other > SDOs are involved. > > I'm not sure if they want names in the charter or > if they're just > > interested in knowing. > > spt > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > > The proposed text in the charter already says: > > > > > >> In accordance with existing IETF processes, the= > group will > > >> communicate with and > > > invite participation from other relevant > standards bodies and > > > regulatory organizations, and if necessary reuse= > existing liaison > > > relationships or request the establishment of > new liaison > > =20 relationships. > > > > > > 'standard bodies and regulatory organizations' > are neutral terms > > enough IMO, as Sean says we should not enter the > 'what is an SDO > > dispute'. We are dealing not only with standards > organizations and > > this is also reflected in the current text. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From:sacm-bounces@ietf.org > > > [mailto:sacm-bounces@ietf.org] On > > >> Behalf Of Sean Turner > > =20 >> Sent: Tuesday, June 25, 2013 2:06 AM > > >> To:tony@yaanatech.com > > > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam > Montville; > > >>sacm@ietf.org > > > >> Subject: Re: [sacm] sacm charter review > > >> > > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > >>> SDO is an undesirable legacy term. > > >>> Pathetically, the old SDO club still does not > regard the IETF as a > > >>> "SDO!" > > > >>>http://www.tta.or.kr/English/new/external_relations/gsc1= 7_communiq > > >>> ue > > >>> .j > > >>> sp > > >>> > > >>> Perhaps it is better=20to simply use "standard= s > fora." > > >> > > >> I'm not against just saying organization > too. I don't want to get > > >> in to arguments about what's an SDO and what's = not. > > >> > > >> spt > > >> > > >>> You should consider including: NIST, MITRE, > and 3GPP - all of > > >>> which are well recognized as key standards > bodies currently > > >>> engaged in SACM related work with whom you > should be interested now. > > >>> > > >>> -t > > >>> > > >>> On 6/24/2013 11:52 AM, Adam Montville wrote: > > >>>> There are a variety of other SDOs in which we= > could be interested > > >>>> now or in the future. The short-story list: > > >>>> > > >>>> * FIRST (vulnerability scoring) > > >>>> * DMTF (already mentioned) > > >>>> * TCG (already mentioned) > > >>>> * The Open Group (XDAS and others) > > >>>> * ISO (i.e. TagVault) > > >>>> * W3C (i.e. obvious things like XML DigSig, > and potentially less > > >>>> obvious things like RDF, OWL, SWRL, etc.) > > >>>> * OASIS (i.e. security assertions, key > management, alerting) > > >>>> * OMG (i.e. Business Process Model Notation > and/or Execution > > >>>> Language, > > >>>> etc.) > > >>> > > >>> > > >> _______________________________________________= > > >> sacm mailing list > > =20>>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 > > ... > > This message and=20attachments may contain confidentia= l > > 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. > > _______________________________________________ > > 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 ... 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 kathleen.moriarty@emc.com Wed Jun 26 08:18:06 2013 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 65E4221E80BF for ; Wed, 26 Jun 2013 08:18:06 -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 U0HqXMCRNnCR for ; Wed, 26 Jun 2013 08:18:02 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0A69B21F9B3E for ; Wed, 26 Jun 2013 08:18:00 -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 r5QFHpNI013489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 11:17:52 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 26 Jun 2013 11:17:41 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5QFHfjP019634; Wed, 26 Jun 2013 11:17:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Wed, 26 Jun 2013 11:17:40 -0400 From: "Moriarty, Kathleen" To: "Waltermire, David A." Date: Wed, 26 Jun 2013 11:17:38 -0400 Thread-Topic: [sacm] more sacm charter review Thread-Index: Ac5ygEwXUzjbS4pzQWuvMlUk+FVLfA== Message-ID: References: <51CAFF5D.1020008@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: Sean Turner , "sacm@ietf.org" Subject: Re: [sacm] more sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:18:06 -0000 +1 Sent from my iPhone On Jun 26, 2013, at 11:01 AM, "Waltermire, David A." wrote: > +1. The content is more important than how it is parsed out. I don't fe= el strongly either way as long as we can clearly articulate what we need to= . >=20 > Dave >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Wednesday, June 26, 2013 10:49 AM >> To: sacm@ietf.org >> Subject: [sacm] more sacm charter review >>=20 >> Not sure if everybody wants to see all of this back and forth, but I tho= ught it >> would be useful for the list to know what my fellow ADs are thinking. >>=20 >> Pete had a question about why we have three informational drafts when it >> would probably make sense to do all three in one draft and that the >> architecture draft should be standards track. As I told him, I see no s= word to >> fall on here so I'd like to adopt this change: >>=20 >> OLD: >>=20 >> - An Informational document on Use Cases >> - An Informational document on Requirements >> - An Informational document on SACM Architecture >>=20 >> NEW: >>=20 >> - A document or documents describing the SACM Architecture. This will >> include protocol requirements and their associated use cases as well as = a >> description of how SACM protocols fit together into a system. This may b= e a >> single standards-track document, or may be split up as the WG sees fit. >>=20 >> spt >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From shanna@juniper.net Wed Jun 26 23:07:24 2013 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 C705C21F9C23 for ; Wed, 26 Jun 2013 23:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, 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 oc7b3k8FzuHW for ; Wed, 26 Jun 2013 23:07:19 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id EAF4B21F9C18 for ; Wed, 26 Jun 2013 23:07:18 -0700 (PDT) Received: from mail192-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.23; Thu, 27 Jun 2013 06:07:18 +0000 Received: from mail192-co9 (localhost [127.0.0.1]) by mail192-co9-R.bigfish.com (Postfix) with ESMTP id 7194F4C00E0 for ; Thu, 27 Jun 2013 06:07:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I542I1432I4015Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah2ba5I8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail192-co9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=shanna@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail192-co9 (localhost.localdomain [127.0.0.1]) by mail192-co9 (MessageSwitch) id 1372313235688664_4495; Thu, 27 Jun 2013 06:07:15 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.235]) by mail192-co9.bigfish.com (Postfix) with ESMTP id A5ACB320061 for ; Thu, 27 Jun 2013 06:07:15 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 27 Jun 2013 06:07:15 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Jun 2013 23:07:14 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 26 Jun 2013 23:07:14 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 26 Jun 2013 23:19:05 -0700 Received: from mail71-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE020.bigfish.com (10.243.66.83) with Microsoft SMTP Server id 14.1.225.23; Thu, 27 Jun 2013 06:07:12 +0000 Received: from mail71-co1 (localhost [127.0.0.1]) by mail71-co1-R.bigfish.com (Postfix) with ESMTP id 8682BB4016C for ; Thu, 27 Jun 2013 06:07:12 +0000 (UTC) Received: from mail71-co1 (localhost.localdomain [127.0.0.1]) by mail71-co1 (MessageSwitch) id 1372313230346365_9408; Thu, 27 Jun 2013 06:07:10 +0000 (UTC) Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.237]) by mail71-co1.bigfish.com (Postfix) with ESMTP id 51759B80055; Thu, 27 Jun 2013 06:07:10 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 27 Jun 2013 06:07:09 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.63]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0324.000; Thu, 27 Jun 2013 06:07:09 +0000 From: Stephen Hanna To: Adam Montville , Sean Turner Thread-Topic: [sacm] sacm charter review Thread-Index: AQHOcNh37nKSnCbwB0KyXIYmhwU2yplE7eEAgAAB5fCAABRCgIAAD2sAgABpi4CAAJdzAIAATgCAgAAInACAAAcJAIAAGcIAgAACjQCAAAStAIABGvGAgAA4vYCAAAPkgIAAA36AgAAGB4CAAATdAIAABWtAgAARO4CAAA4/gIAA950A Date: Thu, 27 Jun 2013 06:07:08 +0000 Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF2B6C55@MIVEXAMER1N1.corp.nai.org> , <51CAF94D.2040105@ieca.com> <05BCCEB107AF88469B9F99783D47C1D670230B@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D670230B@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.54.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISECURITY.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NIST.GOV$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MCAFEE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "Kent_Landfield@McAfee.com" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] sacm charter review X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 06:07:24 -0000 Coming up with a short list of people from whom we expect to receive proposals smacks of favoritism and is contrary to the IETF's tradition of selecting the best technology for the job. Fortunately, Sean has assured us that this approach will not be used. We'll decide on our use cases, requirements, and architecture. Only then will we move on to identifying the best solutions. Thanks, Steve > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Wednesday, June 26, 2013 11:14 AM > To: Sean Turner; Stephen Hanna > Cc: Waltermire, David A.; sacm@ietf.org; Kent_Landfield@McAfee.com > Subject: RE: [sacm] sacm charter review >=20 > Has the original ask from Sean been addressed (whittle down the list)? >=20 > Here's the way I see it...which could be off the wall. >=20 > The sole focus of the WG, if established, would be to focus on the > narrowed cases we've previously discussed, which is essentially how do > we cart around data formats that already exist and how do we improve > those data formats. >=20 > The data formats come from few places, really: NIST, MITRE, FIRST. > Novel work in the area of protocols for carting data formats around > will come from the established WG and other IETF work (i.e. MILE, NEA). >=20 > To me, this is the primary area of focus - we need to solve these "base > cases" before we can reasonably consider doing anything more advanced. >=20 > So, to address what might be the blocking concern, can we agree on an > initial, non-IETF list of: NIST, MITRE, and FIRST? This with the > understanding that most, if not all, of that work can be referenced > and/or brought into the established WG "free and clear" of IPR issues. > For example, I imagine Asset Identification can be brought in without > liaison relationships being required. >=20 > I know that this can be an uncomfortable discussion, but it's one that > seems required to get the WG established. The fact that we're blocked > right now doesn't concern me as much given the nature of the blocking > comment, which indicates that a real-time discussion is needed during > the 6/27 call. Looking at this effort from the outside, I would > probably want that as well. >=20 > Adam >=20 >=20 > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Sean > Turner [turners@ieca.com] > Sent: Wednesday, June 26, 2013 7:23 AM > To: Stephen Hanna > Cc: Waltermire, David A.; sacm@ietf.org; Kent_Landfield@McAfee.com > Subject: Re: [sacm] sacm charter review >=20 > Everybody is going to be on equal footing when we start. We're going > to > do use cases, requirements, and architecture and then figure out what > makes sense to use, modify, or develop. >=20 > spt >=20 > On 6/26/13 9:53 AM, Stephen Hanna wrote: > > TCG has eight years of experience developing widely deployed endpoint > > assessment protocols and a proven track record of contributing our > > protocols to IETF under the IETF's standard terms. For example, we > > contributed the TNC client-server protocols to IETF as Internet- > Drafts. > > They have been adopted by the NEA working group, revised, and > published > > as Proposed Standard RFCs. The TCG standards are very relevant to the > > SACM work, even beyond the NEA specs. For example, IF-MAP is an > > excellent protocol for gathering endpoint assessment results across a > > variety of endpoint assessment technologies. Also, TCG has been > > represented in the SACM work since the very start. > > > > I believe that TCG should stand on equal footing with NIST and MITRE > in > > this matter. > > > > Thanks, > > > > Steve > > > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On > Behalf > > Of *Waltermire, David A. > > *Sent:* Wednesday, June 26, 2013 9:02 AM > > *To:* Kent_Landfield@McAfee.com; turners@ieca.com; sacm@ietf.org > > *Subject:* Re: [sacm] sacm charter review > > > > I mentioned this work because it does align with some of the > tentative > > requirements and use cases that have been floated. There is a > potential > > for liaison with these orgs. Even for the NIST and MITRE work, we > have > > options to reference it in place or bring the work in. You could say > > the same thing for TCG and OpenGroup efforts. It is too early to > decide > > one way or another right now as we still have work to do on the use > > cases, requirements, and architecture documents. The determining > factor > > will be if changes need to be made to the existing work and if the > orgs > > are willing to make a contribution. If it is referenced, this will > drive > > the liaison decision. If the work needs to brought in, then all of > what > > you said about IPR would apply. > > > > Dave > > > > *From:*sacm-bounces@ietf.org > > [mailto:sacm-bounces@ietf.org] *On Behalf Of > *Kent_Landfield@McAfee.com > > > > *Sent:* Wednesday, June 26, 2013 8:45 AM > > *To:* Waltermire, David A.; turners@ieca.com > ; > > sacm@ietf.org > > *Subject:* Re: [sacm] sacm charter review > > > > Hi Dave, > > > > I assumed that MILE and NEA were already identified from charter > > references and was looking at only organizations external to the > IETF. > > Individuals from the organizations I listed either are or have had > > active discussions to contribute to the proposed WG. I am not sure > > initially we are talking about TCG related work. Yes, it could be > > possible but that is up to the TCG to contribute their work into the > > group as a proposal. Same for O-ACEML. Those proposals need to fit > the > > proposed charter and be made to the working group itself. If they > are > > making proposals for work items to the SACM WG then they would be > > following the IETF IPR rules for documents contributed. The key here > is > > that the work would be done in SACM and should not be duplicating > work > > elsewhere. > > > > I guess I need clarity from Sean. I was looking at what > organizations > > would be directly working with the SACM initially. Liaison or > otherwise. > > I fully expect we would invite others to participate in SACM. I > > personally plan on trying to assure all are aware of the SACM efforts > > and goals. Developing a list of who to invite is different from the > > perspective I responded with. > > > > *Kent Landfield* > > > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > > > *From: *, David Waltermire > > > > *Date: *Wednesday, June 26, 2013 2:23 PM > > *To: *Kent Landfield > >, Sean Turner > >, "sacm@ietf.org " > > > > > *Subject: *RE: [sacm] sacm charter review > > > > We may want to bring in updates of the existing NEA protocols > and/or > > new work created within the TCG. We may also want to consider > > O-ACEML from the OpenGroup. These have been discussed as options > on > > the list and during the BoFs. > > > > Dave > > > > *From:*sacm-bounces@ietf.org > > [mailto:sacm-bounces@ietf.org] *On Behalf Of > > *Kent_Landfield@McAfee.com > > *Sent:* Wednesday, June 26, 2013 8:11 AM > > *To:* turners@ieca.com ; sacm@ietf.org > > > > *Subject:* Re: [sacm] sacm charter review > > > > From my perspective the initial organizations we will be dealing > > with are > > > > - ISO/IEC > > > > - NIST > > > > - MITRE > > > > *Kent Landfield* > > > > > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > > > *From: *Sean Turner > > > *Date: *Wednesday, June 26, 2013 1:56 PM > > *To: *"sacm@ietf.org " > > > > *Subject: *Re: [sacm] sacm charter review > > > > It looks like Joel wants to know now some of the > organizations > > (i.e., > > > > there's block on the charter). Can we whittle this list down > to > > just > > > > orgs we're going to be dealing with at the initial stages? > For > > asset > > > > identification it's possibly going to be ISO+NIST+?, for > endpoint > > > > elements to assess it's ?, for comparison it's ?, for > > interacting with > > > > repositories it's NEA. > > > > More inline. > > > > On 6/26/13 4:33 AM, Romascanu, Dan (Dan) wrote: > > > > Yes. The fact that other organizations are interested in > the > > scope of > > > > SACM does not mean that they do the same work, and > certainly > > the future > > > > WG must avoid duplication. Maybe we should make this > > explicit. For example: > > > > OLD: > > > > The working group will create an overview of related > > standards work > > > > Internet-Draft which will document existing work in the > IETF > > or in other > > > > SDOs > > > > which can be used as-is or as a starting point for > > developing solutions > > > > to the > > > > SACM requirements. The working group may decide to make > of > > this document an > > > > Informational RFC, but this is not a mandatory > deliverable. > > > > NEW: > > > > The working group will create an overview of related > > standards work > > > > Internet-Draft which will document existing work in the > IETF > > or in other > > > > SDOs > > > > which can be used as-is or as a starting point for > > developing solutions > > > > to the > > > > SACM requirements. The working group may decide to refer > or > > document > > > > these in > > > > An Informational RFC, but this is not a mandatory > > deliverable. The > > > > working group > > > > will not duplicate work already done or in progress in > other > > places. > > > > We were on the same wavelength. I'm not sure we need to > > repeated the we > > > > won't duplicate work because there's already a blurb about > > reuse. What > > > > I proposed to Barry/Joel/Spencer: > > > > OLD: > > > > The working group will create an overview of related > standards work > > > > Internet-Draft which will document existing work in the IETF > or > > in other > > > > SDOs which can be used as-is or as a starting point for > developing > > > > solutions to the SACM requirements. > > > > NEW: > > > > The working group will create an Internet-Draft documenting > the > > existing > > > > work in the IETF and in other organizations that might > > > > be used as-is or as a starting point for developing solutions > to > > > > the SACM requirements. > > > > OLD: > > > > In accordance with existing IETF processes, the group will > > communicate > > > > with and invite participation from other relevant standards > > bodies and > > > > regulatory organizations, and if necessary reuse existing > liaison > > > > relationships or request the establishment of new liaison > > relationships. > > > > NEW: > > > > In accordance with existing IETF processes, the working group > will > > > > communicate with and invite participation from other relevant > > groups and > > > > regulatory organizations, and if necessary reuse existing > liaison > > > > relationships or request the establishment of new liaison > > relationships. > > > > Regards, > > > > Dan > > > > *From:*sacm-bounces@ietf.org bounces@ietf.org> > > [mailto:sacm-bounces@ietf.org] *On Behalf > > > > Of *Michael Hammer > > > > *Sent:* Tuesday, June 25, 2013 6:41 PM > > > > *To:* Kent_Landfield@McAfee.com > > ; > > Adam.Montville@cisecurity.org > > ; > > > > dbharrington@comcast.net > ; > > turners@ieca.com ; sacm@ietf.org > > > > > > *Subject:* Re: [sacm] sacm charter review > > > > +1 This just means many groups are interested in the > same > > scope. > > > > Mike > > > > *From:*sacm-bounces@ietf.org bounces@ietf.org> > > > > > > [mailto:sacm-bounces@ietf.org] *On Behalf Of > > *Kent_Landfield@McAfee.com > > > > > > > > > *Sent:* Tuesday, June 25, 2013 8:24 AM > > > > *To:* Adam.Montville@cisecurity.org > > > > > > ; > > dbharrington@comcast.net > > > > > ; turners@ieca.com > > > > > > ; sacm@ietf.org > > > > > > *Subject:* Re: [sacm] sacm charter review > > > > Well said Adam. I totally agree with your comments. > > > > *Kent Landfield* > > > > *McAfee | An Intel Company* > > > > Direct: +1.972.963.7096 > > > > Mobile: +1.817.637.8026 > > > > *Web: *www.mcafee.com > > > > *From: *Adam Montville > > > > > > > > > > > > *Date: *Tuesday, June 25, 2013 5:15 PM > > > > *To: *David Harrington > > > > > > > >, Sean Turner > > > > > > >, > > "sacm@ietf.org > > > " > > > > > > > > > > > > *Subject: *Re: [sacm] sacm charter review > > > > Hi David, > > > > I respectfully disagree. > > > > While this may be a commentary on the potential, > > eventual reach of > > > > SACM, our charter's scope is far reduced from > > including all of these > > > > organizations at the outset. In other words, our > > scope is limited > > > > by the language in the charter, against which this > > list really has > > > > no bearing other than to satisfy curiosity and, > > perhaps, lend some > > > > vision to the future. > > > > In fact, it might be more properly construed that > this > > list of > > > > organizations is a commentary on the ubiquitous > nature > > of assessment > > > > - it is a capability that "touches" a lot of > different > > areas, which > > > > is precisely why it warrants its own working group, > IMO. > > > > Regards, > > > > Adam > > > > ________________________________________ > > > > From: sacm-bounces@ietf.org > > bounces@ietf.org> > > > > [sacm-bounces@ietf.org bounces@ietf.org> > > > > ] on behalf of > > > > David Harrington [dbharrington@comcast.net > > > > > > > > ] > > > > Sent: Tuesday, June 25, 2013 6:43 AM > > > > To: 'Sean Turner'; sacm@ietf.org > > > > > > Subject: Re: [sacm] sacm charter review > > > > Wow! > > > > I think this is an excellent commentary on the > scope > > of SACM being > > > > way too > > > > broad, and poorly scoped for engineering purposes. > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > > +1-603-828-1401 > > > > -----Original Message----- > > > > From: sacm-bounces@ietf.org > > bounces@ietf.org> > > > > [mailto:sacm-bounces@ietf.org] On Behalf Of > > > > Romascanu, Dan (Dan) > > > > Sent: Tuesday, June 25, 2013 9:18 AM > > > > To: Sean Turner > > > > Cc: Moriarty, Kathleen; Stephen Hanna; Adam > Montville; > > sacm@ietf.org > > > > ; > > > > tony@yaanatech.com > > > > > > Subject: Re: [sacm] sacm charter review > > > > Hi Sean, > > > > A list of organizations that are involved in the > area, > > as identified > > > > in this > > > > discussion includes: > > > > - TCG > > > > - DMTF > > > > - FIRST > > > > - The Open Group > > > > - ISO/IEC > > > > - W3C > > > > - OASIS > > > > - OMG > > > > - NIST > > > > - MITRE > > > > - 3GPP > > > > It's up to the IESG to decide if we should list > these > > (or some of them) > > > > explicitly, or we should leave to the WG after its > > formation is > > > > approved to > > > > initiate communication and invite participation. > > > > Regards, > > > > Dan > > > > -----Original Message----- > > > > From: Sean Turner [mailto:turners@ieca.com] > > > > Sent: Tuesday, June 25, 2013 3:47 PM > > > > To: Romascanu, Dan (Dan) > > > > Cc: tony@yaanatech.com > > > ; Adam > > > > Montville; Stephen Hanna; Moriarty, > > > > Kathleen; sacm@ietf.org > > > > > > Subject: Re: [sacm] sacm charter review > > > > At this point 3 ADs have asked about what other > > SDOs are involved. > > > > I'm not sure if they want names in the charter > or > > if they're just > > > > interested in knowing. > > > > spt > > > > On 6/25/13 4:07 AM, Romascanu, Dan (Dan) wrote: > > > > > The proposed text in the charter already > says: > > > > > > > > > >> In accordance with existing IETF processes, > the > > group will > > > > >> communicate with and > > > > > invite participation from other relevant > > standards bodies and > > > > > regulatory organizations, and if necessary > reuse > > existing liaison > > > > > relationships or request the establishment of > > new liaison > > > > relationships. > > > > > > > > > > 'standard bodies and regulatory > organizations' > > are neutral terms > > > > enough IMO, as Sean says we should not enter > the > > 'what is an SDO > > > > dispute'. We are dealing not only with > standards > > organizations and > > > > this is also reflected in the current text. > > > > > > > > > > Regards, > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From:sacm-bounces@ietf.org > > bounces@ietf.org> > > > > [mailto:sacm-bounces@ietf.org] On > > > > >> Behalf Of Sean Turner > > > > >> Sent: Tuesday, June 25, 2013 2:06 AM > > > > >> To:tony@yaanatech.com > > > > > > >> Cc: Moriarty, Kathleen; Stephen Hanna; Adam > > Montville; > > > > >>sacm@ietf.org > > > > > > >> Subject: Re: [sacm] sacm charter review > > > > >> > > > > >> On 6/24/13 12:47 PM, Tony Rutkowski wrote: > > > > >>> SDO is an undesirable legacy term. > > > > >>> Pathetically, the old SDO club still does > not > > regard the IETF as a > > > > >>> "SDO!" > > > > > > > >>>http://www.tta.or.kr/English/new/external_relations/gsc17_communiq > > > > >>> ue > > > > >>> .j > > > > >>> sp > > > > >>> > > > > >>> Perhaps it is better to simply use > "standards > > fora." > > > > >> > > > > >> I'm not against just saying organization > > too. I don't want to get > > > > >> in to arguments about what's an SDO and > what's not. > > > > >> > > > > >> spt > > > > >> > > > > >>> You should consider including: NIST, MITRE, > > and 3GPP - all of > > > > >>> which are well recognized as key standards > > bodies currently > > > > >>> engaged in SACM related work with whom you > > should be interested now. > > > > >>> > > > > >>> -t > > > > >>> > > > > >>> On 6/24/2013 11:52 AM, Adam Montville > wrote: > > > > >>>> There are a variety of other SDOs in which > we > > could be interested > > > > >>>> now or in the future. The short-story > list: > > > > >>>> > > > > >>>> * FIRST (vulnerability scoring) > > > > >>>> * DMTF (already mentioned) > > > > >>>> * TCG (already mentioned) > > > > >>>> * The Open Group (XDAS and others) > > > > >>>> * ISO (i.e. TagVault) > > > > >>>> * W3C (i.e. obvious things like XML > DigSig, > > and potentially less > > > > >>>> obvious things like RDF, OWL, SWRL, etc.) > > > > >>>> * OASIS (i.e. security assertions, key > > management, alerting) > > > > >>>> * OMG (i.e. Business Process Model > Notation > > and/or Execution > > > > >>>> Language, > > > > >>>> etc.) > > > > >>> > > > > >>> > > > > >> > _______________________________________________ > > > > >> 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 > > > > ... > > > > 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. > > > > _______________________________________________ > > > > 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 >=20 > ... >=20 > 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. >=20 From turners@ieca.com Thu Jun 27 06:34:23 2013 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 74F0521F9E15 for ; Thu, 27 Jun 2013 06:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=0.032, 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 pr05UQsKdHIM for ; Thu, 27 Jun 2013 06:34:17 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.236.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7C21F9E14 for ; Thu, 27 Jun 2013 06:34:17 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 0257949F7FF51; Thu, 27 Jun 2013 08:34:16 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id DD94949F7FEE4 for ; Thu, 27 Jun 2013 08:34:15 -0500 (CDT) Received: from [173.73.135.86] (port=49839 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsCL0-0005wG-Nn for sacm@ietf.org; Thu, 27 Jun 2013 08:34:14 -0500 Message-ID: <51CC3F56.9030202@ieca.com> Date: Thu, 27 Jun 2013 09:34:14 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sacm@ietf.org References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> In-Reply-To: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:49839 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:34:23 -0000 Another block. Since the call is in about 2 hours I don't really expect to resolve these now, but be thinking about how we might address Benoit's points. These kind of comments should come as no surprise being that he's the management AD and management is the proposed wg's name. spt -------- Original Message -------- Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Date: Thu, 27 Jun 2013 06:18:24 -0700 From: Benoit Claise To: The IESG Benoit Claise has entered the following ballot position for charter-ietf-sacm-00-06: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- "The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models." Fine. Now, I really would like to see an information model document (see RFC 3444) as a deliverable. And then the mapping to protocol/data model. I had to read the charter multiple times to get an idea of the "security information" might mean... Software version, patches, vulnerabilities. Maybe it's defined by "The initial focus of this work is to address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209).". And I'm still not quite sure. Hence the importance of the information model as a milestone. "An example of such an endpoint posture assessment could include, but is not limited to, the following general steps: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results" Then I see in the next sentence of the charter: "policy management" The WG scope is (too) huge: inventory management + monitoring + fault management + policy management? Please don't re-invent monitoring and fault management. Is policy management in scope or not? I guess no. And inventory: I understand that it means device inventory, but I see later also "vulnerability identifiers". Clearly mentions what's in scope and what is not. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above)." I don't know what a repository protocol is. From kathleen.moriarty@emc.com Thu Jun 27 07:04:31 2013 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 BDEE221F9E10 for ; Thu, 27 Jun 2013 07:04:23 -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 x47zA53hV72w for ; Thu, 27 Jun 2013 07:04:19 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5645321F9E0E for ; Thu, 27 Jun 2013 07:04:05 -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 r5RE41KL001562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 10:04:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 27 Jun 2013 10:03:44 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5RE3hXD017188; Thu, 27 Jun 2013 10:03:43 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Thu, 27 Jun 2013 10:03:43 -0400 From: "Moriarty, Kathleen" To: Sean Turner Date: Thu, 27 Jun 2013 10:03:37 -0400 Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: Ac5zPyHpqURF3dKhRUmJhG6xKBhRyA== Message-ID: <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com> In-Reply-To: <51CC3F56.9030202@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:04:31 -0000 Hi Sean, The second one could be changed to repository access protocol and you can l= ist a RESTful interface as an example. For the first, reuse will make the scope possible. There is no intention o= f reinventing the wheel, but rather to provide uniform ways to perform thes= e functions where we may need to create mappings or relationships between e= xisting methods. In some cases, we may need to select from proposed method= s, improve or combine them. Thanks, Kathleen=20 Sent from my iPhone On Jun 27, 2013, at 9:34 AM, "Sean Turner" wrote: > Another block. >=20 > Since the call is in about 2 hours I don't really expect to resolve=20 > these now, but be thinking about how we might address Benoit's points.=20 > These kind of comments should come as no surprise being that he's the=20 > management AD and management is the proposed wg's name. >=20 > spt >=20 >=20 > -------- Original Message -------- > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK=20 > and COMMENT) > Date: Thu, 27 Jun 2013 06:18:24 -0700 > From: Benoit Claise > To: The IESG >=20 > Benoit Claise has entered the following ballot position for > charter-ietf-sacm-00-06: Block >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > "The working group will, whenever reasonable and possible, reuse > existing > protocols, mechanisms, information and data models." >=20 > Fine. Now, I really would like to see an information model document (see > RFC 3444) as a deliverable. > And then the mapping to protocol/data model. >=20 > I had to read the charter multiple times to get an idea of the "security > information" might mean... Software version, patches, vulnerabilities. > Maybe it's defined by "The initial focus of this work is to address > enterprise use cases pertaining to the > assessment of endpoint posture (using the definitions of Endpoint and > Posture from RFC 5209).". > And I'm still not quite sure. Hence the importance of the information > model as a milestone. >=20 > "An example of such an endpoint posture assessment could include, but is > not > limited to, the following general steps: > 1. Identify endpoints > 2. Determine specific endpoint elements to assess > 3. Collect actual value of elements > 4. Compare actual element values to expected element values > 5. Report results" > Then I see in the next sentence of the charter: "policy management" >=20 > The WG scope is (too) huge: inventory management + monitoring + fault > management + policy management? > Please don't re-invent monitoring and fault management. > Is policy management in scope or not? I guess no. > And inventory: I understand that it means device inventory, but I see > later also "vulnerability identifiers". > Clearly mentions what's in scope and what is not. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > "Repository protocols are needed to store, update, and retrieve > configuration > checks and other types of content required for posture assessment (see > step 2 > above)." > I don't know what a repository protocol is. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Adam.Montville@cisecurity.org Thu Jun 27 07:16:12 2013 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 8404E21F9DC9 for ; Thu, 27 Jun 2013 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RpS0tohatVC for ; Thu, 27 Jun 2013 07:16:07 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) by ietfa.amsl.com (Postfix) with ESMTP id 953EE21F9DBD for ; Thu, 27 Jun 2013 07:16:07 -0700 (PDT) Received: from [216.82.241.211:10769] by server-9.bemta-8.messagelabs.com id 2B/20-11030-6294CC15; Thu, 27 Jun 2013 14:16:06 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-12.tower-85.messagelabs.com!1372342565!30494980!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 13683 invoked from network); 27 Jun 2013 14:16:05 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-12.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jun 2013 14:16:05 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 10:15:49 -0400 From: Adam Montville To: "Moriarty, Kathleen" , Sean Turner Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: AQHOczsErZWjSqPg8kCIWHZSn9hoA5lJ2tSA//+/5Ls= Date: Thu, 27 Jun 2013 14:15:49 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com>, <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> In-Reply-To: <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:16:12 -0000 Agree. This domain is problematic in describing scope for the reasons I have prev= iously mentioned - assessing posture (a security use case) is something th= at undoubtedly touches a lot of other related areas and efforts. As Kathl= een points out, reuse is a key to managing scope. Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Moriarty,= Kathleen [kathleen.moriarty@emc.com] Sent: Thursday, June 27, 2013 7:04 AM To: Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06:= (with BLOCK and COMMENT) Hi Sean, The second one could be changed to repository access protocol and you can = list a RESTful interface as an example. For the first, reuse will make the scope possible. There is no intention = of reinventing the wheel, but rather to provide uniform ways to perform th= ese functions where we may need to create mappings or relationships betwee= n existing methods. In some cases, we may need to select from=20proposed = methods, improve or combine them. Thanks, Kathleen Sent from my iPhone On Jun 27, 2013, at 9:34 AM, "Sean Turner" wrote: > Another block. > > Since the call is in about 2 hours I don't really expect to resolve > these now, but be thinking about how we might address Benoit's points. > These kind of comments should come as no surprise being that he's the > management AD and management is the proposed wg's name. > > spt > > > -------- Original Message -------- > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > and COMMENT) > Date: Thu, 27 Jun 2013 06:18:24 -0700 > From: Benoit Claise > To: The IESG > > Benoit Claise has entered the following ballot position for > charter-ietf-sacm-00-06: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "The working group will, whenever reasonable and possible, reuse > existing > protocols, mechanisms, information and data models." > > Fine. Now, I really would like to see an information model document (see= > RFC 3444) as a deliverable. > And then the mapping to protocol/data model. > > I had to read the charter multiple times to get an idea of the "security= > information" might mean... Software version, patches, vulnerabilities. > Maybe it's defined by "The initial focus of this work is to address > enterprise use cases pertaining to the > assessment of endpoint posture (using the definitions of Endpoint and > Posture from RFC 5209).". > And I'm still not quite sure. Hence the importance of the information > model as a milestone. > > "An example of such an endpoint posture assessment could include, but is= > not > limited to, the following general steps: > 1. Identify endpoints > 2. Determine=20specific endpoint elements to assess > 3. Collect actual value of elements > 4. Compare actual element values to expected element values > 5. Report results" > Then I see in the next sentence of the charter: "policy management" > > The WG scope is (too) huge: inventory management + monitoring + fault > management + policy management? > Please don't re-invent monitoring and fault management. > Is policy management in scope or not? I guess no. > And inventory: I understand that it means device inventory, but I see > later also "vulnerability identifiers". > Clearly mentions what's in scope and what is not. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "Repository protocols are needed to store, update, and retrieve > configuration > checks and other types of content required for posture assessment (see > step 2 > above)." > I don't know what a repository protocol is. > _______________________________________________ > 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 ... 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 turners@ieca.com Thu Jun 27 07:30:52 2013 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 0101121F9DEB for ; Thu, 27 Jun 2013 07:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.031, 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 WVIzylSRxGXV for ; Thu, 27 Jun 2013 07:30:43 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.7.8]) by ietfa.amsl.com (Postfix) with ESMTP id EA45B21F9DDD for ; Thu, 27 Jun 2013 07:30:42 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 6D12BBD79B1EC; Thu, 27 Jun 2013 09:30:42 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 5BB45BD79B1A9 for ; Thu, 27 Jun 2013 09:30:42 -0500 (CDT) Received: from [173.73.135.86] (port=49872 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsDDd-00014k-5W for sacm@ietf.org; Thu, 27 Jun 2013 09:30:41 -0500 Message-ID: <51CC4C90.6040107@ieca.com> Date: Thu, 27 Jun 2013 10:30:40 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sacm@ietf.org References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com> In-Reply-To: <51CC3F56.9030202@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:49872 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:30:52 -0000 A couple of people have asked what block means. It's like a discuss on a draft that's up for IESG evaluation. If it's not addressed (and it's reasonable and other support it) then the draft does not progress. So for sacm that means so far we have two we have to address. I'll try my best on the call, but we may need to make some changes to make the other ADs comfortable with the charter. spt On 6/27/13 9:34 AM, Sean Turner wrote: > Another block. > > Since the call is in about 2 hours I don't really expect to resolve > these now, but be thinking about how we might address Benoit's points. > These kind of comments should come as no surprise being that he's the > management AD and management is the proposed wg's name. > > spt > > > -------- Original Message -------- > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > and COMMENT) > Date: Thu, 27 Jun 2013 06:18:24 -0700 > From: Benoit Claise > To: The IESG > > Benoit Claise has entered the following ballot position for > charter-ietf-sacm-00-06: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "The working group will, whenever reasonable and possible, reuse > existing > protocols, mechanisms, information and data models." > > Fine. Now, I really would like to see an information model document (see > RFC 3444) as a deliverable. > And then the mapping to protocol/data model. > > I had to read the charter multiple times to get an idea of the "security > information" might mean... Software version, patches, vulnerabilities. > Maybe it's defined by "The initial focus of this work is to address > enterprise use cases pertaining to the > assessment of endpoint posture (using the definitions of Endpoint and > Posture from RFC 5209).". > And I'm still not quite sure. Hence the importance of the information > model as a milestone. > > "An example of such an endpoint posture assessment could include, but is > not > limited to, the following general steps: > 1. Identify endpoints > 2. Determine specific endpoint elements to assess > 3. Collect actual value of elements > 4. Compare actual element values to expected element values > 5. Report results" > Then I see in the next sentence of the charter: "policy management" > > The WG scope is (too) huge: inventory management + monitoring + fault > management + policy management? > Please don't re-invent monitoring and fault management. > Is policy management in scope or not? I guess no. > And inventory: I understand that it means device inventory, but I see > later also "vulnerability identifiers". > Clearly mentions what's in scope and what is not. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "Repository protocols are needed to store, update, and retrieve > configuration > checks and other types of content required for posture assessment (see > step 2 > above)." > I don't know what a repository protocol is. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From turners@ieca.com Thu Jun 27 07:35:22 2013 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 2A27B21F9E0D for ; Thu, 27 Jun 2013 07:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=0.030, 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 CY9+KVOwr4WJ for ; Thu, 27 Jun 2013 07:35:17 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.93.164.2]) by ietfa.amsl.com (Postfix) with ESMTP id 19D8021F9E00 for ; Thu, 27 Jun 2013 07:35:17 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id DF7C19A0EDD44; Thu, 27 Jun 2013 09:35:01 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id D24FB9A0EDCF5 for ; Thu, 27 Jun 2013 09:35:01 -0500 (CDT) Received: from [173.73.135.86] (port=49877 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsDI0-0002oO-87; Thu, 27 Jun 2013 09:35:12 -0500 Message-ID: <51CC4D9F.7090201@ieca.com> Date: Thu, 27 Jun 2013 10:35:11 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com> <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> In-Reply-To: <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:49877 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:35:22 -0000 On 6/27/13 10:03 AM, Moriarty, Kathleen wrote: > Hi Sean, > > The second one could be changed to repository access protocol and you can list a RESTful interface as an example. I'm also thinking that we could indent everything from: An example ... to ... Boolean logic. and move the 2. after the paragraph that ends Boolean logic to keep them points about 1 and 2 together. Then it'd flow from #2 to what the repository was. Then again, it might just be a terminology thing: you say tomato I say tomato ;) > For the first, reuse will make the scope possible. There is no intention of reinventing the wheel, but rather to provide uniform ways to perform these functions where we may need to create mappings or relationships between existing methods. In some cases, we may need to select from proposed methods, improve or combine them. That's what I told him via jabber, but we'll still do it on the call. This is mostly about making sure that everybody agrees (the wg and the iesg) about the contract we're getting in to. If we overstep or miss the mark we'll hear about it. > Thanks, > Kathleen > > Sent from my iPhone > > On Jun 27, 2013, at 9:34 AM, "Sean Turner" wrote: > >> Another block. >> >> Since the call is in about 2 hours I don't really expect to resolve >> these now, but be thinking about how we might address Benoit's points. >> These kind of comments should come as no surprise being that he's the >> management AD and management is the proposed wg's name. >> >> spt >> >> >> -------- Original Message -------- >> Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK >> and COMMENT) >> Date: Thu, 27 Jun 2013 06:18:24 -0700 >> From: Benoit Claise >> To: The IESG >> >> Benoit Claise has entered the following ballot position for >> charter-ietf-sacm-00-06: Block >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> "The working group will, whenever reasonable and possible, reuse >> existing >> protocols, mechanisms, information and data models." >> >> Fine. Now, I really would like to see an information model document (see >> RFC 3444) as a deliverable. >> And then the mapping to protocol/data model. >> >> I had to read the charter multiple times to get an idea of the "security >> information" might mean... Software version, patches, vulnerabilities. >> Maybe it's defined by "The initial focus of this work is to address >> enterprise use cases pertaining to the >> assessment of endpoint posture (using the definitions of Endpoint and >> Posture from RFC 5209).". >> And I'm still not quite sure. Hence the importance of the information >> model as a milestone. >> >> "An example of such an endpoint posture assessment could include, but is >> not >> limited to, the following general steps: >> 1. Identify endpoints >> 2. Determine specific endpoint elements to assess >> 3. Collect actual value of elements >> 4. Compare actual element values to expected element values >> 5. Report results" >> Then I see in the next sentence of the charter: "policy management" >> >> The WG scope is (too) huge: inventory management + monitoring + fault >> management + policy management? >> Please don't re-invent monitoring and fault management. >> Is policy management in scope or not? I guess no. >> And inventory: I understand that it means device inventory, but I see >> later also "vulnerability identifiers". >> Clearly mentions what's in scope and what is not. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> "Repository protocols are needed to store, update, and retrieve >> configuration >> checks and other types of content required for posture assessment (see >> step 2 >> above)." >> I don't know what a repository protocol is. >> _______________________________________________ >> 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 dromasca@avaya.com Thu Jun 27 07:40:33 2013 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 18E4421F9E62 for ; Thu, 27 Jun 2013 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3aznnmDkBde for ; Thu, 27 Jun 2013 07:40:27 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3715921F9D80 for ; Thu, 27 Jun 2013 07:40:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FACNOzFHGmAcF/2dsb2JhbABRCoJoITFJvwl/FnSCIwEBAQEDAQEBDyg0BAcMBAIBCA0EAQIBAQEBChQJBycLFAMGCAIEAQ0FCBqHbAELnxGbUhMEjhMGBIEHMQcGgnxjA54JiwGBWIE5gWgJFyA X-IronPort-AV: E=Sophos;i="4.87,952,1363147200"; d="scan'208,223";a="18002271" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Jun 2013 10:40:22 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jun 2013 10:37:55 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 10:40:20 -0400 From: "Romascanu, Dan (Dan)" To: Adam Montville , "Moriarty, Kathleen" , Sean Turner Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: AQHOczsVIyzy33Rs5kyF4TP6qh4485lJ2tSAgAADaYD//71bIA== Date: Thu, 27 Jun 2013 14:40:20 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com>, <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:40:33 -0000 >From the operational perspective what I believe Benoit would like to see ad= ded is a deliverable that looks like:=20 - A standards-track document specifying the informational model for endpoin= ts data posture and its mapping into the protocol and data format for collecting actual endpoint posture We can argue that the information model can be part of the SACM architectur= e document.=20 Do we need a data model deliverable now? Maybe this can be the object of a = later charter. This phase being focused on defining the architecture (inclu= ding information model), protocols and data formats (data modeling language= ) - a later phase or another WG can deal with the data models specific to t= he various functions.=20 I would also observe that we did not define Milestones in the proposed char= ter. I am surprised that no AD raised a BLOCK about it.=20 Should it be something like:=20 - Initial submission of SACM Architecture Internet-Draft - October 2013 - Initial submission of protocol and data format for retrieving configurati= on and policy information for driving data collection and analysis Internet= -Draft - January 2014 - Initial submission of protocol and data format for collecting endpoint po= sture Internet-Draft - January 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as = Informational RFC - May 2014 - Submit protocol and data format for retrieving configuration and policy i= nformation for driving data collection and analysis Internet-Draft to the I= ESG for consideration as Proposed Standard - September 2014 - Submit protocol and data format for collecting endpoint posture Internet-= Draft to the IESG for consideration as Proposed Standard - September 2014 Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, June 27, 2013 5:16 PM > To: Moriarty, Kathleen; Sean Turner > Cc: sacm@ietf.org > Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- > 06: (with BLOCK and COMMENT) >=20 > Agree. >=20 > This domain is problematic in describing scope for the reasons I have > previously mentioned - assessing posture (a security use case) is > something that undoubtedly touches a lot of other related areas and > efforts. As Kathleen points out, reuse is a key to managing scope. >=20 > Adam >=20 > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of > Moriarty, Kathleen [kathleen.moriarty@emc.com] > Sent: Thursday, June 27, 2013 7:04 AM > To: Sean Turner > Cc: sacm@ietf.org > Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- > 06: (with BLOCK and COMMENT) >=20 > Hi Sean, >=20 > The second one could be changed to repository access protocol and you > can list a RESTful interface as an example. >=20 > For the first, reuse will make the scope possible. There is no > intention of reinventing the wheel, but rather to provide uniform ways > to perform these functions where we may need to create mappings or > relationships between existing methods. In some cases, we may need to > select from proposed methods, improve or combine them. >=20 > Thanks, > Kathleen >=20 > Sent from my iPhone >=20 > On Jun 27, 2013, at 9:34 AM, "Sean Turner" wrote: >=20 > > Another block. > > > > Since the call is in about 2 hours I don't really expect to resolve > > these now, but be thinking about how we might address Benoit's points. > > These kind of comments should come as no surprise being that he's the > > management AD and management is the proposed wg's name. > > > > spt > > > > > > -------- Original Message -------- > > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > > and COMMENT) > > Date: Thu, 27 Jun 2013 06:18:24 -0700 > > From: Benoit Claise > > To: The IESG > > > > Benoit Claise has entered the following ballot position for > > charter-ietf-sacm-00-06: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > "The working group will, whenever reasonable and possible, reuse > > existing protocols, mechanisms, information and data models." > > > > Fine. Now, I really would like to see an information model document > > (see RFC 3444) as a deliverable. > > And then the mapping to protocol/data model. > > > > I had to read the charter multiple times to get an idea of the > > "security information" might mean... Software version, patches, > vulnerabilities. > > Maybe it's defined by "The initial focus of this work is to address > > enterprise use cases pertaining to the assessment of endpoint posture > > (using the definitions of Endpoint and Posture from RFC 5209).". > > And I'm still not quite sure. Hence the importance of the information > > model as a milestone. > > > > "An example of such an endpoint posture assessment could include, but > > is not limited to, the following general steps: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess 3. Collect actual > > value of elements 4. Compare actual element values to expected element > > values 5. Report results" > > Then I see in the next sentence of the charter: "policy management" > > > > The WG scope is (too) huge: inventory management + monitoring + fault > > management + policy management? > > Please don't re-invent monitoring and fault management. > > Is policy management in scope or not? I guess no. > > And inventory: I understand that it means device inventory, but I see > > later also "vulnerability identifiers". > > Clearly mentions what's in scope and what is not. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > "Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above)." > > I don't know what a repository protocol is. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... >=20 > 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. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Kent_Landfield@mcafee.com Thu Jun 27 07:49:33 2013 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 D07B021F9B5E for ; Thu, 27 Jun 2013 07:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHpxBwP3rzYh for ; Thu, 27 Jun 2013 07:49:29 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 5251D21F9AA1 for ; Thu, 27 Jun 2013 07:49:29 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 7971_4182_b0aa17fc_016c_49f1_9c5e_8b459eead3e8; Thu, 27 Jun 2013 09:49:23 -0500 Received: from MIVEXEMEA1N1.corp.nai.org (10.48.48.31) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 27 Jun 2013 10:48:40 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXEMEA1N1.corp.nai.org ([169.254.3.136]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 10:48:40 -0400 From: To: , , , Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: AQHOczsLngNAAmf0akCNG90kGA/9hJlJ2tSAgAADaYCAAAbZAIAAI9kA Date: Thu, 27 Jun 2013 14:48:40 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2B8FAF@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2B8FAFMIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:49:33 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2B8FAFMIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would think that should be a part of the architecture document and if it = needed expanding then we could break it out later. The Milestones are listed in the draft charter at http://datatracker.ietf.o= rg/wg/sacm/charter/ Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Thursday, June 27, 2013 4:40 PM To: Adam Montville >, Kathleen Moriarty >, Sean Turner = > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: = (with BLOCK and COMMENT) >From the operational perspective what I believe Benoit would like to see ad= ded is a deliverable that looks like: - A standards-track document specifying the informational model for endpoin= ts data posture and its mapping into the protocol and data format for collecting actual endpoint posture We can argue that the information model can be part of the SACM architectur= e document. Do we need a data model deliverable now? Maybe this can be the object of a = later charter. This phase being focused on defining the architecture (inclu= ding information model), protocols and data formats (data modeling language= ) - a later phase or another WG can deal with the data models specific to t= he various functions. I would also observe that we did not define Milestones in the proposed char= ter. I am surprised that no AD raised a BLOCK about it. Should it be something like: - Initial submission of SACM Architecture Internet-Draft - October 2013 - Initial submission of protocol and data format for retrieving configurati= on and policy information for driving data collection and analysis Internet= -Draft - January 2014 - Initial submission of protocol and data format for collecting endpoint po= sture Internet-Draft - January 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as = Informational RFC - May 2014 - Submit protocol and data format for retrieving configuration and policy i= nformation for driving data collection and analysis Internet-Draft to the I= ESG for consideration as Proposed Standard - September 2014 - Submit protocol and data format for collecting endpoint posture Internet-= Draft to the IESG for consideration as Proposed Standard - September 2014 Dan -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Thursday, June 27, 2013 5:16 PM To: Moriarty, Kathleen; Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Agree. This domain is problematic in describing scope for the reasons I have previously mentioned - assessing posture (a security use case) is something that undoubtedly touches a lot of other related areas and efforts. As Kathleen points out, reuse is a key to managing scope. Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] on behalf of Moriarty, Kathleen [kathleen.moriarty@emc.com] Sent: Thursday, June 27, 2013 7:04 AM To: Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Hi Sean, The second one could be changed to repository access protocol and you can list a RESTful interface as an example. For the first, reuse will make the scope possible. There is no intention of reinventing the wheel, but rather to provide uniform ways to perform these functions where we may need to create mappings or relationships between existing methods. In some cases, we may need to select from proposed methods, improve or combine them. Thanks, Kathleen Sent from my iPhone On Jun 27, 2013, at 9:34 AM, "Sean Turner" > wrote: > Another block. > > Since the call is in about 2 hours I don't really expect to resolve > these now, but be thinking about how we might address Benoit's points. > These kind of comments should come as no surprise being that he's the > management AD and management is the proposed wg's name. > > spt > > > -------- Original Message -------- > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > and COMMENT) > Date: Thu, 27 Jun 2013 06:18:24 -0700 > From: Benoit Claise > > To: The IESG > > > Benoit Claise has entered the following ballot position for > charter-ietf-sacm-00-06: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models." > > Fine. Now, I really would like to see an information model document > (see RFC 3444) as a deliverable. > And then the mapping to protocol/data model. > > I had to read the charter multiple times to get an idea of the > "security information" might mean... Software version, patches, vulnerabilities. > Maybe it's defined by "The initial focus of this work is to address > enterprise use cases pertaining to the assessment of endpoint posture > (using the definitions of Endpoint and Posture from RFC 5209).". > And I'm still not quite sure. Hence the importance of the information > model as a milestone. > > "An example of such an endpoint posture assessment could include, but > is not limited to, the following general steps: > 1. Identify endpoints > 2. Determine specific endpoint elements to assess 3. Collect actual > value of elements 4. Compare actual element values to expected element > values 5. Report results" > Then I see in the next sentence of the charter: "policy management" > > The WG scope is (too) huge: inventory management + monitoring + fault > management + policy management? > Please don't re-invent monitoring and fault management. > Is policy management in scope or not? I guess no. > And inventory: I understand that it means device inventory, but I see > later also "vulnerability identifiers". > Clearly mentions what's in scope and what is not. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above)." > I don't know what a repository protocol is. > _______________________________________________ > 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 ... 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. _______________________________________________ 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_3CBA099FBA0AB843895D72474092B8CF2B8FAFMIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I would think that should be a part of the architecture document and i= f it needed expanding then we could break it out later.

The Milestones are listed in the draft charter at http://datatracker.ietf.org/wg/sac= m/charter/

Kent Landfield

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

From: <Romascanu>, "Dan = (Dan)" <dromasca@avaya.com>
Date: Thursday, June 27, 2013 4:40 = PM
To: Adam Montville <Adam.Montville@cisecurity.org>,= Kathleen Moriarty <kathlee= n.moriarty@emc.com>, Sean Turner <turners@ieca.com>
Cc: "sacm@ietf.org" <sacm@i= etf.org>
Subject: Re: [sacm] Fwd: Benoit Cla= ise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)

From the operational perspective what I believe Benoit would like to s= ee added is a deliverable that looks like:

- A standards-track document specifying the informational model for en= dpoints data posture and its mapping into the protocol and data format for<= /div>
collecting actual endpoint posture

We can argue that the information model can be part of the SACM archit= ecture document.

Do we need a data model deliverable now? Maybe this can be the object = of a later charter. This phase being focused on defining the architecture (= including information model), protocols and data formats (data modeling lan= guage) - a later phase or another WG can deal with the data models specific to the various functions.

I would also observe that we did not define Milestones in the proposed= charter. I am surprised that no AD raised a BLOCK about it.

Should it be something like:

- Initial submission of SACM Architecture Internet-Draft - October 201= 3
- Initial submission of protocol and data format for retrieving config= uration and policy information for driving data collection and analysis Int= ernet-Draft - January 2014
- Initial submission of protocol and data format for collecting endpoi= nt posture Internet-Draft - January 2014
- Submit SACM Architecture Internet-Draft to the IESG for consideratio= n as Informational RFC - May 2014
- Submit protocol and data format for retrieving configuration and pol= icy information for driving data collection and analysis Internet-Draft to = the IESG for consideration as Proposed Standard - September 2014
- Submit protocol and data format for collecting endpoint posture Inte= rnet-Draft to the IESG for consideration as Proposed Standard - September 2= 014

Dan

-----Original Message-----
Adam Montville
Sent: Thursday, June 27, 2013 5:16 PM
To: Moriarty, Kathleen; Sean Turner
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00= -
06: (with BLOCK and COMMENT)
Agree.
This domain is problematic in describing scope for the reasons I have<= /div>
previously mentioned - assessing posture (a security use case) is
something that undoubtedly touches a lot of other related areas and
efforts.  As Kathleen points out, reuse is a key to managing= scope.
Adam
________________________________________
Moriarty, Kathleen [kathl= een.moriarty@emc.com]
Sent: Thursday, June 27, 2013 7:04 AM
To: Sean Turner
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00= -
06: (with BLOCK and COMMENT)
Hi Sean,
The second one could be changed to repository access protocol and you<= /div>
can list a RESTful interface as an example.
For the first, reuse will make the scope possible.  There is= no
intention of reinventing the wheel, but rather to provide uniform ways=
to perform these functions where we may need to create mappings or
relationships between existing methods.  In some cases, we m= ay need to
select from proposed methods, improve or combine them.
Thanks,
Kathleen
Sent from my iPhone
On Jun 27, 2013, at 9:34 AM, "Sean Turner" <turners@ieca.com> wrote:
> Another block.
>
> Since the call is in about 2 hours I don't really expect to resol= ve
> these now, but be thinking about how we might address Benoit's po= ints.
> These kind of comments should come as no surprise being that he's= the
> management AD and management is the proposed wg's name.
>
> spt
>
>
> -------- Original Message --------
> Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with = BLOCK
> and COMMENT)
> Date: Thu, 27 Jun 2013 06:18:24 -0700
> From: Benoit Claise <bcla= ise@cisco.com>
> To: The IESG <iesg@ietf.org>
>
> Benoit Claise has entered the following ballot position for
> charter-ietf-sacm-00-06: Block
>
> When responding, please keep the subject line intact and reply to= all
> email addresses included in the To and CC lines. (Feel free to cu= t
> this introductory paragraph, however.)
>
>
> -----------------------------------------------------------------= -----
> BLOCK:
> -----------------------------------------------------------------= -----
>
> "The working group will, whenever reasonable and possible, r= euse
> existing protocols, mechanisms, information and data models."= ;
>
> Fine. Now, I really would like to see an information model docume= nt
> (see RFC 3444) as a deliverable.
> And then the mapping to protocol/data model.
>
> I had to read the charter multiple times to get an idea of the
> "security information" might mean... Software version, = patches,
vulnerabilities.
> Maybe it's defined by "The initial focus of this work is to = address
> enterprise use cases pertaining to the assessment of endpoint pos= ture
> (using the definitions of Endpoint and Posture from RFC 5209).&qu= ot;.
> And I'm still not quite sure. Hence the importance of the informa= tion
> model as a milestone.
>
> "An example of such an endpoint posture assessment could inc= lude, but
> is not limited to, the following general steps:
> 1. Identify endpoints
> 2. Determine specific endpoint elements to assess 3. Collect actu= al
> value of elements 4. Compare actual element values to expected el= ement
> values 5. Report results"
> Then I see in the next sentence of the charter: "policy mana= gement"
>
> The WG scope is (too) huge: inventory management + monitoring= + fault
> management + policy management?
> Please don't re-invent monitoring and fault management.
> Is policy management in scope or not? I guess no.
> And inventory: I understand that it means device inventory, but I= see
> later also "vulnerability identifiers".
> Clearly mentions what's in scope and what is not.
>
>
> -----------------------------------------------------------------= -----
> COMMENT:
> -----------------------------------------------------------------= -----
>
> "Repository protocols are needed to store, update, and retri= eve
> configuration checks and other types of content required for post= ure
> assessment (see step 2 above)."
> I don't know what a repository protocol is.
> _______________________________________________
> sacm mailing list
>
_______________________________________________
sacm mailing list
...
This message and attachments may contain confidential information.&nbs= p; 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 immediatel= y and
permanently delete the message and any attachments.
_______________________________________________
sacm mailing list
_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2B8FAFMIVEXAMER1N1corpn_-- From nithya@cygnacom.com Thu Jun 27 07:58:33 2013 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 B515D21F9DDE for ; Thu, 27 Jun 2013 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIzQY+LLrAfG for ; Thu, 27 Jun 2013 07:58:28 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4004421F9DBE for ; Thu, 27 Jun 2013 07:58:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,952,1363147200"; d="scan'208,217";a="9401677" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 27 Jun 2013 10:58:11 -0400 Received: from SCYGEXCH10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Thu, 27 Jun 2013 10:58:11 -0400 From: Nithya Rachamadugu To: "sacm@ietf.org" Thread-Topic: unsubscribe Thread-Index: Ac5zRr085DwNxB9cT7ae1Q9mFd9VsQ== Date: Thu, 27 Jun 2013 14:58:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.100.25] Content-Type: multipart/alternative; boundary="_000_C2336BF44392F146B4E76F0EC1417EF8030827scygexch10cygnaco_" MIME-Version: 1.0 Subject: [sacm] unsubscribe X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:58:34 -0000 --_000_C2336BF44392F146B4E76F0EC1417EF8030827scygexch10cygnaco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Nithya Rachamadugu Director, Security Evaluation Laboratory (SEL) & Cryptographic Equipment As= sessment Laboratory (CEAL) CygnaCom Solutions, Inc. 7925 Jones Branch Dr, Suite 5400 McLean, VA 22102-3378 Nithya@cygnacom.com Land: (703) 270-3551 cell: (703) 216-3978 Fax: (703) 848-0985 ** PROPRIETARY & CONFIDENTIAL ** This email and any attachments are confid= ential and/or proprietary and intended solely for the named recipients. If = you received this e-mail in error, please notify me by replying and delete = the message without copying or disclosing it. Thank you --_000_C2336BF44392F146B4E76F0EC1417EF8030827scygexch10cygnaco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks

 

Nithya Rachamadugu

Director, Security Evaluation = Laboratory (SEL) & Cryptographic Equipment Assessment Laboratory (CEAL)=

CygnaCom Solutions, Inc.

7925 Jones Branch Dr, Suite 54= 00

McLean, VA 22102-3378 

Nithya@cygnacom.com

Land: (703) 270-3551 cell:   (703) 216-3978 Fax: (703) 848-0985

 ** PROPRIETARY & CONFIDENTIAL ** Th= is email and any attachments are confidential and/or proprietary and intended solely for the named recipients. If you received this e-mail in e= rror, please notify me by replying and delete the message without copying o= r disclosing it. Thank you

 

--_000_C2336BF44392F146B4E76F0EC1417EF8030827scygexch10cygnaco_-- From Adam.Montville@cisecurity.org Thu Jun 27 08:33:45 2013 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 C6CD021F9D91 for ; Thu, 27 Jun 2013 08:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYQbvfBzHixO for ; Thu, 27 Jun 2013 08:33:29 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 21EC711E80EA for ; Thu, 27 Jun 2013 08:20:38 -0700 (PDT) Received: from [216.82.253.227:31866] by server-7.bemta-7.messagelabs.com id 8D/91-09450-2485CC15; Thu, 27 Jun 2013 15:20:34 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-15.tower-170.messagelabs.com!1372346432!18416889!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 29529 invoked from network); 27 Jun 2013 15:20:33 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-15.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jun 2013 15:20:33 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 11:20:15 -0400 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "dromasca@avaya.com" , "kathleen.moriarty@emc.com" , "turners@ieca.com" Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: AQHOczsErZWjSqPg8kCIWHZSn9hoA5lJ2tSA//+/5LuAAEpfAIAAAlQA///FAF8= Date: Thu, 27 Jun 2013 15:20:16 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> References: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com>, <3CBA099FBA0AB843895D72474092B8CF2B8FAF@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2B8FAF@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D6702628CISEXCHANGE1msisa_" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:33:45 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D6702628CISEXCHANGE1msisa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This seems to be the real issue. We could wait and break it out later (I = assume "it" is the data model information), but then it looks like we don'= t really know what we're going to deliver because we don't have it explici= tly listed. I am amenable to adding the deliverable as Dan has proposed. Such a deliv= erable could end up being a full-on technical specification or an applicab= ility statement referencing existing work. Adam ________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Kent_Land= field@McAfee.com [Kent_Landfield@McAfee.com] Sent: Thursday, June 27, 2013 7:49 AM To: dromasca@avaya.com; Adam Montville; kathleen.moriarty@emc.com; turners= @ieca.com Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06:= (with BLOCK and COMMENT) I would think that should be a part of the architecture document and if it= needed expanding then we could break it out later. The Milestones are listed in the draft charter at http://datatracker.ietf.= org/wg/sacm/charter/ Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Thursday, June 27, 2013 4:40 PM To: Adam Montville >, Kathleen Moriarty >, Sean Turner > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06:= (with BLOCK and COMMENT) >From the operational perspective what I believe Benoit would like to see a= dded is a deliverable that looks like: - A standards-track document specifying the informational model for endpoi= nts data posture and its mapping into the protocol and data format for collecting actual endpoint posture We can argue that the information model can be part of the SACM architectu= re document. Do we need a data model deliverable now? Maybe this can be the object of a= later charter. This phase being focused on defining the architecture (inc= luding information model), protocols and data formats (data modeling langu= age) - a later phase or another WG can deal with the data models specific = to the various functions. I would also observe that we did not define Milestones in the proposed cha= rter. I am surprised that no AD raised a BLOCK about it. Should it be something like: - Initial submission of SACM Architecture Internet-Draft - October 2013 - Initial submission of protocol and data format for retrieving configurat= ion and policy information for driving data collection and analysis Intern= et-Draft - January 2014 - Initial submission of protocol and data format for collecting endpoint p= osture Internet-Draft - January 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as= Informational RFC - May 2014 - Submit protocol and data format for retrieving configuration and policy = information for driving data collection and analysis Internet-Draft to the= IESG for consideration as Proposed Standard - September 2014 - Submit protocol and data format for collecting endpoint posture Internet= -Draft to the IESG for consideration as Proposed Standard - September 2014= Dan -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Adam Montville Sent: Thursday, June 27, 2013 5:16 PM To: Moriarty, Kathleen; Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Agree. This domain is problematic in describing scope for the reasons I have previously mentioned - assessing posture (a security use case) is something that undoubtedly touches a lot of other related areas and efforts. As Kathleen points out, reuse is a key to managing scope. Adam ________________________________________ From:=20sacm-bounces@ietf.org [sacm-bounces@= ietf.org] on behalf of Moriarty, Kathleen [kathleen.moriarty@emc.com] Sent: Thursday, June 27, 2013 7:04 AM To: Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Hi Sean, The second one could be changed to repository access protocol and you can list a RESTful interface as an example. For the first, reuse will make the scope possible. There is no intention of reinventing the wheel, but rather to provide uniform ways to perform these functions where we may need to create mappings or relationships between existing methods. In some cases, we may need to select from proposed methods, improve or combine them. Thanks, Kathleen Sent from my iPhone On Jun 27, 2013, at 9:34 AM, "Sean Turner" > wrote: > Another block. > > Since the call is in about 2 hours I don't really expect to resolve > these now, but be thinking about how we might address Benoit's points. > These kind of comments should come as no surprise being that he's the > management AD and management is the proposed wg's name. > > spt > > > -------- Original Message -------- > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > and COMMENT) > Date: Thu, 27 Jun 2013 06:18:24 -0700 > From: Benoit Claise > > To: The IESG > > > Benoit Claise has entered the following ballot position for > charter-ietf-sacm-00-06: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models." > > Fine. Now, I really would like to see an information model document > (see RFC 3444) as a deliverable. > And then the mapping to protocol/data model. > > I had to read the charter multiple times to get an idea of the > "security information" might mean... Software version, patches, vulnerabilities. > Maybe it's defined by "The initial focus of this work is to address > enterprise use cases pertaining to the assessment of endpoint posture > (using the definitions of Endpoint and Posture from RFC 5209).". > And I'm still not quite sure. Hence the importance of the information > model as a milestone. > > "An example of such an endpoint posture assessment could include, but > is not limited to, the following general steps: > 1. Identify endpoints > 2. Determine specific endpoint elements to assess 3. Collect actual > value of elements 4. Compare actual element values to expected element > values 5. Report results" > Then I see in the next sentence of the charter: "policy management" > > The WG scope is (too) huge: inventory management + monitoring + fault > management + policy management? > Please don't re-invent monitoring and fault management. > Is policy management in scope or not? I guess no. > And inventory: I understand that it means device inventory, but I see > later also "vulnerability identifiers". > Clearly mentions what's in scope and what is not. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above)." > I don't know what a repository protocol is. > _______________________________________________ > 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 ... 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. _______________________________________________ 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 ... 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=20permanently de= lete the message and any attachments. --_000_05BCCEB107AF88469B9F99783D47C1D6702628CISEXCHANGE1msisa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This seems to be the real issue.  We could wait and break it = out later (I assume "it" is the data model information), but the= n it looks like we don't really know what we're going to deliver because we don't have it explicitly listed.

I am amenable to adding the deliverable as Dan has proposed.  Su= ch a deliverable could end up being a=20full-on technical specification or= an applicability statement referencing existing work. 

Adam


From: sacm-bounces@ietf.org [sacm-bounc= es@ietf.org] on behalf of Kent_Landfield@McAfee.com [Kent_Landfield@McAfee= .com]
Sent: Thursday, June 27, 2013 7:49 AM
To: dromasca@avaya.com; Adam Montville; kathleen.moriarty@emc.com; = turners@ieca.com
Cc: sacm@ietf.org
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm= -00-06: (with BLOCK and COMMENT)

I would think that should be a part of the architecture document and = if it needed expanding then we could break it out later.

The Milestones are listed in the draft charter at http://datatra= cker.ietf.org/wg/sacm/charter/

Kent Landfield

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

From: <Romascanu>, "Dan= (Dan)" <d= romasca@avaya.com>
Date: Thursday, June 27, 2013 4:40= PM
To: Adam Montville <Adam.Montville@cis= ecurity.org>, Kathleen Moriarty <kathleen.moriarty@emc.com>, Sean Turner <tur= ners@ieca.com>
Cc: "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Fwd: Benoit Cl= aise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)

From the operational perspective what I believe Benoit would like to = see added is a deliverable that looks like:

- A standards-track document specifying the informational model for e= ndpoints data posture and its mapping into the protocol and data format fo= r
collecting actual endpoint posture

We can argue that the information model can be part of the SACM archi= tecture document.

Do we need a data model deliverable now? Maybe this can be the object= of a later charter. This phase being focused on defining the architecture= (including information model), protocols and data formats (data modeling = language) - a later phase or another WG can deal with the data models specific to the various functions.

I would also observe that we did not define Milestones in the propose= d charter. I am surprised that no AD raised a BLOCK about it.

Should it be something like:

- Initial submission of SACM Architecture Internet-Draft - October 20= 13
- Initial submission of protocol and data format for retrieving confi= guration and policy information for driving data collection and analysis I= nternet-Draft - January 2014
- Initial submission of protocol and data format for collecting endpo= int posture Internet-Draft - January 2014
- Submit SACM Architecture Internet-Draft to the IESG for considerati= on as Informational RFC - May 2014
- Submit protocol and data format for retrieving configuration and po= licy information for driving data collection and analysis Internet-Draft t= o the IESG for consideration as Proposed Standard - September 2014
- Submit protocol and data format for collecting endpoint posture Int= ernet-Draft to the IESG for consideration as Proposed Standard - September= 2014

Dan

-----Original Message-----
Adam Montville
Sent: Thursday, June 27, 2013 5:16 PM
To: Moriarty, Kathleen; Sean Turner
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-0= 0-
06: (with BLOCK and COMMENT)
Agree.
This domain is problematic in describing scope for the reasons I have=
previously mentioned - assessing posture (a security use case) is
something that undoubtedly touches a lot of other related areas and
efforts.  As Kathleen points out, reuse is a key to managin= g scope.
Adam
________________________________________
Moriarty, Kathleen [kathleen.moriarty@emc.com]
Sent: Thursday, June 27, 2013 7:04 AM
To: Sean Turner
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-0= 0-
06: (with BLOCK and COMMENT)
Hi Sean,
The second one could be changed to repository access protocol and you=
can list a RESTful interface as an example.
For the first, reuse will make the scope possible.  There i= s no
intention of reinventing the wheel, but rather to provide uniform way= s
to perform these functions where we may need to create mappings or
relationships between existing methods.  In some cases, we = may need to
select from proposed methods, improve or combine them.
Thanks,
Kathleen
Sent from my iPhone
On Jun 27, 2013, at 9:34 AM, "Sean Turner" <turners@ieca.com> wrote:<= /div>
> Another block.
>
> Since the call is in about 2 hours I don't really expect to reso= lve
> these now, but be thinking about how we might address Benoit's p= oints.
> These kind of comments should come as no surprise being that he'= s the
> management AD and management is the proposed wg's name.
>
> spt
>
>
> -------- Original Message --------
> Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with= BLOCK
> and COMMENT)
> Date: Thu, 27 Jun 2013 06:18:24 -0700
> From: Benoit Claise <bclaise@cisco.com>
> To: The IESG <iesg@ietf.org>
>
> Benoit Claise has entered the following ballot position for
> charter-ietf-sacm-00-06: Block
>
> When responding, please keep the subject line intact and reply t= o all
> email addresses included in the To and CC lines. (Feel free to c= ut
> this introductory paragraph, however.)
>
>
> ----------------------------------------------------------------= ------
> BLOCK:
> ----------------------------------------------------------------= ------
>
> "The working group will, whenever reasonable and possible, = reuse
> existing protocols, mechanisms, information and data models.&quo= t;
>
> Fine. Now, I really would like to see an information model docum= ent
> (see RFC 3444) as a deliverable.
> And then the mapping to protocol/data model.
>
> I had to read the charter multiple times to get an idea of the
> "security information" might mean... Software version,= patches,
vulnerabilities.
> Maybe it's defined by "The initial focus of this work is to= address
> enterprise use cases pertaining to the assessment of endpoint po= sture
> (using the definitions of Endpoint and Posture from RFC 5209).&q= uot;.
> And I'm still not quite sure. Hence the importance of the inform= ation
> model as a milestone.
>
> "An example of such an endpoint posture assessment could in= clude, but
> is not limited to, the following general steps:
> 1. Identify endpoints
> 2. Determine specific endpoint elements to assess 3. Collect act= ual
> value of elements 4. Compare actual element values to expected e= lement
> values 5. Report results"
> Then I see in the next sentence of the charter: "policy man= agement"
>
> The WG scope is (too) huge: inventory management + monitorin= g + fault
> management + policy management?
> Please don't re-invent monitoring and fault management.
> Is policy management in scope or not? I guess no.
> And inventory: I understand that it means device inventory, but = I see
> later also "vulnerability identifiers".
> Clearly mentions what's in scope and what is not.
>
>
> ----------------------------------------------------------------= ------
> COMMENT:
> ----------------------------------------------------------------= ------
>
> "Repository protocols are needed to store, update, and retr= ieve
> configuration checks and other types of content required for pos= ture
> assessment (see step 2 above)."
> I don't know what a repository protocol is.
> _______________________________________________
> sacm mailing list
>
_______________________________________________
sacm mailing list
sacm@ietf.org<= /div>
...
This message and attachments may contain confidential information.&nb= sp; If
it appears that this message was sent to you by mistake, any retentio= n,
dissemination, distribution or copying of this message and attachment= s
is strictly prohibited.  Please notify the sender immediate= ly and
permanently delete the message and any attachments.
_______________________________________________
sacm mailing list
_______________________________________________
sacm mailing list

...

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.
--_000_05BCCEB107AF88469B9F99783D47C1D6702628CISEXCHANGE1msisa_-- From dromasca@avaya.com Thu Jun 27 08:55:33 2013 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 1E86121F9E16 for ; Thu, 27 Jun 2013 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 P25+Dof-E9mO for ; Thu, 27 Jun 2013 08:55:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id B667D21F9DF4 for ; Thu, 27 Jun 2013 08:55:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAQAOdfzFHGmAcF/2dsb2JhbABRBwOCRSMhMUmrCDyBVYk2iDyBABZ0giMBAQEBAgEBAQEPGxwlBAcFBwQCAQgHBgQBAgEBAQEKFgEGBycLFAMGCAIEAQ0FCBqHZgYBC58km1IXjhMGBIEHBgcSAQEGBQEBAwYBAgQDCIJxYwOYboUbiwGBWIE5gWgJFyA X-IronPort-AV: E=Sophos;i="4.87,953,1363147200"; d="scan'208,217";a="14708362" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jun 2013 11:55:15 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jun 2013 11:52:47 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 11:55:13 -0400 From: "Romascanu, Dan (Dan)" To: Adam Montville , "Kent_Landfield@McAfee.com" , "kathleen.moriarty@emc.com" , "turners@ieca.com" Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: AQHOczsVIyzy33Rs5kyF4TP6qh4485lJ2tSAgAADaYD//71bIIAAS9IAgAAI1QD//8YuIA== Date: Thu, 27 Jun 2013 15:55:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1B3D93@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com>, <3CBA099FBA0AB843895D72474092B8CF2B8FAF@MIVEXAMER1N1.corp.nai.org> <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1B3D93AZFFEXMB04globala_" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:55:33 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1B3D93AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, I was looking at another page which did not have the milestones list= ed. Just to make sure that we have the same understanding about the differentia= tion made between information model and data model - Benoit is using the te= rminology defined by http://www.rfc-editor.org/rfc/rfc3444.txt Regards, Dan From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Thursday, June 27, 2013 6:20 PM To: Kent_Landfield@McAfee.com; Romascanu, Dan (Dan); kathleen.moriarty@emc.= com; turners@ieca.com Cc: sacm@ietf.org Subject: RE: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: = (with BLOCK and COMMENT) This seems to be the real issue. We could wait and break it out later (I a= ssume "it" is the data model information), but then it looks like we don't = really know what we're going to deliver because we don't have it explicitly= listed. I am amenable to adding the deliverable as Dan has proposed. Such a delive= rable could end up being a full-on technical specification or an applicabil= ity statement referencing existing work. Adam ________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] on behalf of Kent_Landfield@McAfee.com [Kent_Landfield@McAfee.com] Sent: Thursday, June 27, 2013 7:49 AM To: dromasca@avaya.com; Adam Montville; kathleen= .moriarty@emc.com; turners@ieca.com Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: = (with BLOCK and COMMENT) I would think that should be a part of the architecture document and if it = needed expanding then we could break it out later. The Milestones are listed in the draft charter at http://datatracker.ietf.o= rg/wg/sacm/charter/ Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Thursday, June 27, 2013 4:40 PM To: Adam Montville >, Kathleen Moriarty >, Sean Turner = > Cc: "sacm@ietf.org" > Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: = (with BLOCK and COMMENT) >From the operational perspective what I believe Benoit would like to see ad= ded is a deliverable that looks like: - A standards-track document specifying the informational model for endpoin= ts data posture and its mapping into the protocol and data format for collecting actual endpoint posture We can argue that the information model can be part of the SACM architectur= e document. Do we need a data model deliverable now? Maybe this can be the object of a = later charter. This phase being focused on defining the architecture (inclu= ding information model), protocols and data formats (data modeling language= ) - a later phase or another WG can deal with the data models specific to t= he various functions. I would also observe that we did not define Milestones in the proposed char= ter. I am surprised that no AD raised a BLOCK about it. Should it be something like: - Initial submission of SACM Architecture Internet-Draft - October 2013 - Initial submission of protocol and data format for retrieving configurati= on and policy information for driving data collection and analysis Internet= -Draft - January 2014 - Initial submission of protocol and data format for collecting endpoint po= sture Internet-Draft - January 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as = Informational RFC - May 2014 - Submit protocol and data format for retrieving configuration and policy i= nformation for driving data collection and analysis Internet-Draft to the I= ESG for consideration as Proposed Standard - September 2014 - Submit protocol and data format for collecting endpoint posture Internet-= Draft to the IESG for consideration as Proposed Standard - September 2014 Dan -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Thursday, June 27, 2013 5:16 PM To: Moriarty, Kathleen; Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Agree. This domain is problematic in describing scope for the reasons I have previously mentioned - assessing posture (a security use case) is something that undoubtedly touches a lot of other related areas and efforts. As Kathleen points out, reuse is a key to managing scope. Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] on behalf of Moriarty, Kathleen [kathleen.moriarty@emc.com] Sent: Thursday, June 27, 2013 7:04 AM To: Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Hi Sean, The second one could be changed to repository access protocol and you can list a RESTful interface as an example. For the first, reuse will make the scope possible. There is no intention of reinventing the wheel, but rather to provide uniform ways to perform these functions where we may need to create mappings or relationships between existing methods. In some cases, we may need to select from proposed methods, improve or combine them. Thanks, Kathleen Sent from my iPhone On Jun 27, 2013, at 9:34 AM, "Sean Turner" > wrote: > Another block. > > Since the call is in about 2 hours I don't really expect to resolve > these now, but be thinking about how we might address Benoit's points. > These kind of comments should come as no surprise being that he's the > management AD and management is the proposed wg's name. > > spt > > > -------- Original Message -------- > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > and COMMENT) > Date: Thu, 27 Jun 2013 06:18:24 -0700 > From: Benoit Claise > > To: The IESG > > > Benoit Claise has entered the following ballot position for > charter-ietf-sacm-00-06: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models." > > Fine. Now, I really would like to see an information model document > (see RFC 3444) as a deliverable. > And then the mapping to protocol/data model. > > I had to read the charter multiple times to get an idea of the > "security information" might mean... Software version, patches, vulnerabilities. > Maybe it's defined by "The initial focus of this work is to address > enterprise use cases pertaining to the assessment of endpoint posture > (using the definitions of Endpoint and Posture from RFC 5209).". > And I'm still not quite sure. Hence the importance of the information > model as a milestone. > > "An example of such an endpoint posture assessment could include, but > is not limited to, the following general steps: > 1. Identify endpoints > 2. Determine specific endpoint elements to assess 3. Collect actual > value of elements 4. Compare actual element values to expected element > values 5. Report results" > Then I see in the next sentence of the charter: "policy management" > > The WG scope is (too) huge: inventory management + monitoring + fault > management + policy management? > Please don't re-invent monitoring and fault management. > Is policy management in scope or not? I guess no. > And inventory: I understand that it means device inventory, but I see > later also "vulnerability identifiers". > Clearly mentions what's in scope and what is not. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above)." > I don't know what a repository protocol is. > _______________________________________________ > 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 ... 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. _______________________________________________ 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 ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. --_000_9904FB1B0159DA42B0B887B7FA8119CA1B3D93AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, I was looking at a= nother page which did not have the milestones listed.

 <= /p>

Just to make sure that we= have the same understanding about the differentiation made between informa= tion model and data model – Benoit is using the terminology defined by http://ww= w.rfc-editor.org/rfc/rfc3444.txt

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: Adam Mon= tville [mailto:Adam.Montville@cisecurity.org]
Sent: Thursday, June 27, 2013 6:20 PM
To: Kent_Landfield@McAfee.com; Romascanu, Dan (Dan); kathleen.moriar= ty@emc.com; turners@ieca.com
Cc: sacm@ietf.org
Subject: RE: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-= 00-06: (with BLOCK and COMMENT)

 

This seems to be the real is= sue.  We could wait and break it out later (I assume "it" is= the data model information), but then it looks like we don't really know what we're going to deliver because we don't have it explicitly listed.

 

I am amenable to adding the = deliverable as Dan has proposed.  Such a deliverable could end up bein= g a full-on technical specification or an applicability statement referencing existing work. 

 

Adam

 

 

From: sacm-bounces@ietf.org [sacm-bo= unces@ietf.org] on behalf of Kent_Landfield@McAfee.com = [Kent_Landfield@McAfee.com]
Sent: Thursday, June 27, 2013 7:49 AM
To: dromasca@avaya.com; Ad= am Montville; kathleen.moriarty@emc.com;= turners@ieca.com
Cc: sacm@ietf.org
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-= 00-06: (with BLOCK and COMMENT)

I would think that shoul= d be a part of the architecture document and if it needed expanding then we= could break it out later.

 =

The Milestones are liste= d in the draft charter at http://datatracker.ietf.org/wg/sacm/charter/

 =

 =

From: <Romascanu>, "Dan (Dan)"= ; <dromasca@avay= a.com>
Date: Thursday, June 27, 2013 4:40 PM
To: Adam Montville <Adam.Montville@cisecurity.org>, Kathleen Moria= rty <kath= leen.moriarty@emc.com>, Sean Turner <turners@ieca.com>
Cc: "sacm@ie= tf.org" <sac= m@ietf.org>
Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-= 00-06: (with BLOCK and COMMENT)

 =

From the operational per= spective what I believe Benoit would like to see added is a deliverable tha= t looks like:

 =

- A standards-track docu= ment specifying the informational model for endpoints data posture and its = mapping into the protocol and data format for

collecting actual endpoi= nt posture

 =

We can argue that the in= formation model can be part of the SACM architecture document.

 =

Do we need a data model = deliverable now? Maybe this can be the object of a later charter. This phas= e being focused on defining the architecture (including information model),= protocols and data formats (data modeling language) - a later phase or another WG can deal with the data models spec= ific to the various functions.

 =

I would also observe tha= t we did not define Milestones in the proposed charter. I am surprised that= no AD raised a BLOCK about it.

 =

Should it be something l= ike:

 =

- Initial submission of = SACM Architecture Internet-Draft - October 2013

- Initial submission of = protocol and data format for retrieving configuration and policy informatio= n for driving data collection and analysis Internet-Draft - January 2014

- Initial submission of = protocol and data format for collecting endpoint posture Internet-Draft - J= anuary 2014

- Submit SACM Architectu= re Internet-Draft to the IESG for consideration as Informational RFC - May = 2014

- Submit protocol and da= ta format for retrieving configuration and policy information for driving d= ata collection and analysis Internet-Draft to the IESG for consideration as= Proposed Standard - September 2014

- Submit protocol and da= ta format for collecting endpoint posture Internet-Draft to the IESG for co= nsideration as Proposed Standard - September 2014

 =

Dan

 =

-----Original Message---= --

Adam Montville

Sent: Thursday, June 27,= 2013 5:16 PM

To: Moriarty, Kathleen; = Sean Turner

Subject: Re: [sacm] Fwd:= Benoit Claise's Block on charter-ietf-sacm-00-

06: (with BLOCK and COMM= ENT)

Agree.=

This domain is problemat= ic in describing scope for the reasons I have

previously mentioned - a= ssessing posture (a security use case) is

something that undoubted= ly touches a lot of other related areas and

efforts.  As K= athleen points out, reuse is a key to managing scope.

Adam

________________________= ________________

Moriarty, Kathleen [kathleen.moriart= y@emc.com]

Sent: Thursday, June 27,= 2013 7:04 AM

To: Sean Turner

Subject: Re: [sacm] Fwd:= Benoit Claise's Block on charter-ietf-sacm-00-

06: (with BLOCK and COMM= ENT)

Hi Sean,

The second one could be = changed to repository access protocol and you

can list a RESTful inter= face as an example.

For the first, reuse wil= l make the scope possible.  There is no

intention of reinventing= the wheel, but rather to provide uniform ways

to perform these functio= ns where we may need to create mappings or

relationships between ex= isting methods.  In some cases, we may need to<= /p>

select from proposed met= hods, improve or combine them.

Thanks,

Kathleen

Sent from my iPhone=

On Jun 27, 2013, at 9:34= AM, "Sean Turner" <turners@ieca.com> wrote:

> Another block.=

> 

> Since the call is i= n about 2 hours I don't really expect to resolve

> these now, but be t= hinking about how we might address Benoit's points.

> These kind of comme= nts should come as no surprise being that he's the

> management AD and m= anagement is the proposed wg's name.

> 

> spt

> 

> 

> -------- Original M= essage --------

> Subject: Benoit Cla= ise's Block on charter-ietf-sacm-00-06: (with BLOCK

> and COMMENT)

> Date: Thu, 27 Jun 2= 013 06:18:24 -0700

> From: Benoit Claise= <bclaise@cisco.c= om>

> To: The IESG <iesg@ietf.org>=

> 

> Benoit Claise has e= ntered the following ballot position for

> charter-ietf-sacm-0= 0-06: Block

> 

> When responding, pl= ease keep the subject line intact and reply to all

> email addresses inc= luded in the To and CC lines. (Feel free to cut

> this introductory p= aragraph, however.)

> 

> 

> -------------------= ---------------------------------------------------

> BLOCK:

> -------------------= ---------------------------------------------------

> 

> "The working g= roup will, whenever reasonable and possible, reuse

> existing protocols,= mechanisms, information and data models."

> 

> Fine. Now, I really= would like to see an information model document

> (see RFC 3444) as a= deliverable.

> And then the mappin= g to protocol/data model.

> 

> I had to read the c= harter multiple times to get an idea of the

> "security info= rmation" might mean... Software version, patches,

vulnerabilities.

> Maybe it's defined = by "The initial focus of this work is to address

> enterprise use case= s pertaining to the assessment of endpoint posture

> (using the definiti= ons of Endpoint and Posture from RFC 5209).".

> And I'm still not q= uite sure. Hence the importance of the information

> model as a mileston= e.

> 

> "An example of= such an endpoint posture assessment could include, but

> is not limited to, = the following general steps:

> 1. Identify endpoin= ts

> 2. Determine specif= ic endpoint elements to assess 3. Collect actual

> value of elements 4= . Compare actual element values to expected element

> values 5. Report re= sults"

> Then I see in the n= ext sentence of the charter: "policy management"

> 

> The WG scope is (to= o) huge: inventory management + monitoring + fault

> management + po= licy management?

> Please don't re-inv= ent monitoring and fault management.

> Is policy managemen= t in scope or not? I guess no.

> And inventory: I un= derstand that it means device inventory, but I see

> later also "vu= lnerability identifiers".

> Clearly mentions wh= at's in scope and what is not.

> 

> 

> -------------------= ---------------------------------------------------

> COMMENT:=

> -------------------= ---------------------------------------------------

> 

> "Repository pr= otocols are needed to store, update, and retrieve

> configuration check= s and other types of content required for posture

> assessment (see ste= p 2 above)."

> I don't know what a= repository protocol is.

> ___________________= ____________________________

> sacm mailing list

> 

________________________= _______________________

sacm mailing list

...

This message and attachm= ents may contain confidential information.  If<= /p>

it appears that this mes= sage was sent to you by mistake, any retention,

dissemination, distribut= ion or copying of this message and attachments

is strictly prohibited.&= nbsp; Please notify the sender immediately and

permanently delete the m= essage and any attachments.

________________________= _______________________

sacm mailing list

________________________= _______________________

sacm mailing list

 =


...


This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

--_000_9904FB1B0159DA42B0B887B7FA8119CA1B3D93AZFFEXMB04globala_-- From eric.walker@us.ibm.com Thu Jun 27 09:01:58 2013 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 A770B21F9E63 for ; Thu, 27 Jun 2013 09:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=1.205] 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 W7075Ie9DOyX for ; Thu, 27 Jun 2013 09:01:41 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 24F0921F9E66 for ; Thu, 27 Jun 2013 09:01:26 -0700 (PDT) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 27 Jun 2013 10:01:20 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 27 Jun 2013 09:57:52 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 04B6D1FF002D for ; Thu, 27 Jun 2013 09:52:32 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5RFvZ9M051286 for ; Thu, 27 Jun 2013 09:57:38 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5RFvZNZ012927 for ; Thu, 27 Jun 2013 09:57:35 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.63.40.12]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r5RFvX3I012777 for ; Thu, 27 Jun 2013 09:57:34 -0600 In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> References: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com>, <3CBA099FBA0AB843895D72474092B8CF2B8FAF@MIVEXAMER1N1.corp.nai.org> <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> X-KeepSent: CF84465E:2E993AA3-87257B97:00574EA1; type=4; name=$KeepSent To: "sacm@ietf.org" X-Mailer: IBM Notes Build V90_CD6_12072012 December 07, 2012 Message-ID: From: Eric Walker Date: Thu, 27 Jun 2013 08:57:31 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 06/27/2013 09:57:33 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13062715-2876-0000-0000-00000A494C39 Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:01:59 -0000 --0__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831 Content-type: multipart/alternative; Boundary="1__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831" --1__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi, I have been following this conversation from the sidelines. I do not m= ind a document that makes reference to existing work as an initial step, bu= t my hope is that the IETF will eventually take full ownership of whatever i= t is that SACM covers, in the event that it forms as a working group. Eric From: Adam Montville To: "Kent_Landfield@McAfee.com" , "dromasca@avaya.com" , "kathleen.moriarty@emc.com" , "turners@ieca.com" Cc: "sacm@ietf.org" Date: 06/27/2013 08:34 AM Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Sent by: sacm-bounces@ietf.org This seems to be the real issue. We could wait and break it out later = (I assume "it" is the data model information), but then it looks like we d= on't really know what we're going to deliver because we don't have it explic= itly listed. I am amenable to adding the deliverable as Dan has proposed. Such a deliverable could end up being a full-on technical specification or an applicability statement referencing existing work. Adam From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Kent_Landfield@McAfee.com [Kent_Landfield@McAfee.com] Sent: Thursday, June 27, 2013 7:49 AM To: dromasca@avaya.com; Adam Montville; kathleen.moriarty@emc.com; turners@ieca.com Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-= 06: (with BLOCK and COMMENT) I would think that should be a part of the architecture document and if= it needed expanding then we could break it out later. The Milestones are listed in the draft charter at http://datatracker.ietf.org/wg/sacm/charter/ Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" Date: Thursday, June 27, 2013 4:40 PM To: Adam Montville , Kathleen Moriarty <= kathleen.moriarty@emc.com>, Sean Turner Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-= 06: (with BLOCK and COMMENT) From the operational perspective what I believe Benoit would like= to see added is a deliverable that looks like: - A standards-track document specifying the informational model f= or endpoints data posture and its mapping into the protocol and data= format for collecting actual endpoint posture We can argue that the information model can be part of the SACM architecture document. Do we need a data model deliverable now? Maybe this can be the ob= ject of a later charter. This phase being focused on defining the architecture (including information model), protocols and data formats (data modeling language) - a later phase or another WG ca= n deal with the data models specific to the various functions. I would also observe that we did not define Milestones in the proposed charter. I am surprised that no AD raised a BLOCK about = it. Should it be something like: - Initial submission of SACM Architecture Internet-Draft - Octobe= r 2013 - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection = and analysis Internet-Draft - January 2014 - Initial submission of protocol and data format for collecting endpoint posture Internet-Draft - January 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC - May 2014 - Submit protocol and data format for retrieving configuration an= d policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard= - September 2014 - Submit protocol and data format for collecting endpoint posture= Internet-Draft to the IESG for consideration as Proposed Standard= - September 2014 Dan -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] = On Behalf Of Adam Montville Sent: Thursday, June 27, 2013 5:16 PM To: Moriarty, Kathleen; Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Agree. This domain is problematic in describing scope for the reas= ons I have previously mentioned - assessing posture (a security use ca= se) is something that undoubtedly touches a lot of other related a= reas and efforts. As Kathleen points out, reuse is a key to managin= g scope. Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on beha= lf of Moriarty, Kathleen [kathleen.moriarty@emc.com] Sent: Thursday, June 27, 2013 7:04 AM To: Sean Turner Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- 06: (with BLOCK and COMMENT) Hi Sean, The second one could be changed to repository access protoc= ol and you can list a RESTful interface as an example. For the first, reuse will make the scope possible. There i= s no intention of reinventing the wheel, but rather to provide uniform ways to perform these functions where we may need to create mapp= ings or relationships between existing methods. In some cases, we = may need to select from proposed methods, improve or combine them. Thanks, Kathleen Sent from my iPhone On Jun 27, 2013, at 9:34 AM, "Sean Turner" wrote: > Another block. > > Since the call is in about 2 hours I don't really expect = to resolve > these now, but be thinking about how we might address Benoit's points. > These kind of comments should come as no surprise being t= hat he's the > management AD and management is the proposed wg's name. > > spt > > > -------- Original Message -------- > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06= : (with BLOCK > and COMMENT) > Date: Thu, 27 Jun 2013 06:18:24 -0700 > From: Benoit Claise > To: The IESG > > Benoit Claise has entered the following ballot position f= or > charter-ietf-sacm-00-06: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel fr= ee to cut > this introductory paragraph, however.) > > > -----------------------------------------------------------= ----------- > BLOCK: > -----------------------------------------------------------= ----------- > > "The working group will, whenever reasonable and possible= , reuse > existing protocols, mechanisms, information and data mode= ls." > > Fine. Now, I really would like to see an information mode= l document > (see RFC 3444) as a deliverable. > And then the mapping to protocol/data model. > > I had to read the charter multiple times to get an idea o= f the > "security information" might mean... Software version, patches, vulnerabilities. > Maybe it's defined by "The initial focus of this work is = to address > enterprise use cases pertaining to the assessment of endp= oint posture > (using the definitions of Endpoint and Posture from RFC 5209).". > And I'm still not quite sure. Hence the importance of the= information > model as a milestone. > > "An example of such an endpoint posture assessment could include, but > is not limited to, the following general steps: > 1. Identify endpoints > 2. Determine specific endpoint elements to assess 3. Coll= ect actual > value of elements 4. Compare actual element values to expected element > values 5. Report results" > Then I see in the next sentence of the charter: "policy management" > > The WG scope is (too) huge: inventory management + monito= ring + fault > management + policy management? > Please don't re-invent monitoring and fault management. > Is policy management in scope or not? I guess no. > And inventory: I understand that it means device inventor= y, but I see > later also "vulnerability identifiers". > Clearly mentions what's in scope and what is not. > > > -----------------------------------------------------------= ----------- > COMMENT: > -----------------------------------------------------------= ----------- > > "Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required = for posture > assessment (see step 2 above)." > I don't know what a repository protocol is. > _______________________________________________ > 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 ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, an= y retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediate= ly and permanently delete the message and any attachments. _______________________________________________ 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 ... This message and attachments may contain confidential information. If i= t 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 permanent= ly delete the message and any attachments. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm = --1__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable



This seems to be the real issue.  = ;We could wait and break it out later (I assume "it" is the d= ata model information), but then it looks like we don't really know wha= t we're going to deliver because we don't have it explicitly listed.

I am amenable to adding the deliverabl= e as Dan has proposed.  Such a deliverable could end up being a fu= ll-on technical specification or an applicability statement referencing= existing work.

Adam



From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on be= half of Kent_Landfield@McAfee.com [Kent_Landfield@McAfee.com]
Sent: Thursday, June 2= 7, 2013 7:49 AM
To: dromasca@avaya.com= ; Adam Montville; kathleen.moriarty@emc.com; turners@ieca.com
Cc: sacm@ietf.org
Subject: Re: [sacm] Fw= d: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and CO= MMENT)

I would think that should be a part of = the architecture document and if it needed expanding then we could brea= k it out later.

The Milestones are listed in the draft = charter at = http://datatracker.ietf.org/wg/sacm/charter/

Kent Landfield=

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

From: <Romascanu>, "Dan (Dan)" <dromasca@avaya.com= >
Date: Thursday, June 27, 2= 013 4:40 PM
To: Adam Montville <= Adam.Montville@c= isecurity.org>, Kat= hleen Moriarty <<= u>kathleen.moriarty@emc.com>, Sean Turner <turners@ieca.com><= /font>
Cc: "sacm@ietf.org" <sa= cm@ietf.org>=
Subject: Re: [sacm] Fwd: B= enoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMEN= T)
    From t= he operational perspective what I believe Benoit would like to see adde= d is a deliverable that looks like:

    - A standards-track document specifying= the informational model for endpoints data posture and its mapping int= o the protocol and data format for
    collecting actual endpoint posture

    We can argue that the information model= can be part of the SACM architecture document.

    Do we need a data model deliverable now= ? Maybe this can be the object of a later charter. This phase being foc= used on defining the architecture (including information model), protoc= ols and data formats (data modeling language) - a later phase or anothe= r WG can deal with the data models specific to the various functions. <= /font>

    I would also observe that we did not de= fine Milestones in the proposed charter. I am surprised that no AD rais= ed a BLOCK about it.

    Should it be something like:
    - Initial submission of SACM Architectu= re Internet-Draft - October 2013
    - Initial submission of protocol and da= ta format for retrieving configuration and policy information for drivi= ng data collection and analysis Internet-Draft - January 2014 - Initial submission of protocol and da= ta format for collecting endpoint posture Internet-Draft - January 2014=
    - Submit SACM Architecture Internet-Dra= ft to the IESG for consideration as Informational RFC - May 2014=
    - Submit protocol and data format for r= etrieving configuration and policy information for driving data collect= ion and analysis Internet-Draft to the IESG for consideration as Propos= ed Standard - September 2014
    - Submit protocol and data format for c= ollecting endpoint posture Internet-Draft to the IESG for consideration= as Proposed Standard - September 2014

    Dan
      -----O= riginal Message-----
      From: sacm-bounces@ietf.org [mail= to:sacm-bounces@ietf.org= ] On Behalf Of
      Adam Montville
      Sent: Thursday, June 27, 2013 5:16 PM
      To: Moriarty, Kathleen; Sean Turner
      Cc: sacm@ietf.org
      Subject: Re: [sacm] Fwd: Benoit Claise'= s Block on charter-ietf-sacm-00-
      06: (with BLOCK and COMMENT)
      = Agree.
      This domain is problematic in describin= g scope for the reasons I have
      previously mentioned - assessing postur= e (a security use case) is
      something that undoubtedly touches a lo= t of other related areas and
      efforts.  As Kathleen points out, = reuse is a key to managing scope.
      Adam
      _______________________________________= _
      From: sacm-bounces@ietf.org [sacm= -bounces@ietf.org] on be= half of
      Moriarty, Kathleen [kathleen.moriarty@emc.com]
      Sent: Thursday, June 27, 2013 7:04 AM
      To: Sean Turner
      Cc:       sacm@ietf.org
      Subject: Re: [sacm] Fwd: Benoit Claise'= s Block on charter-ietf-sacm-00-
      06: (with BLOCK and COMMENT)
      = Hi Sean,
      The second one could be changed to repo= sitory access protocol and you
      can list a RESTful interface as an exam= ple.
      For the first, reuse will make the scop= e possible.  There is no
      intention of reinventing the wheel, but= rather to provide uniform ways
      to perform these functions where we may= need to create mappings or
      relationships between existing methods.=  In some cases, we may need to
      select from proposed methods, improve o= r combine them.
      Thanks,
      Kathleen
      Sent from my iPhone
      On Jun 27, 2013, at 9:34 AM, "Sean= Turner" <turners@ie= ca.com> wrote:=
      > Another block.
      >
      > Since the call is in about 2 hours= I don't really expect to resolve
      > these now, but be thinking about h= ow we might address Benoit's points.
      > These kind of comments should come= as no surprise being that he's the
      > management AD and management is th= e proposed wg's name.
      >
      > spt
      >
      >
      > -------- Original Message --------=
      > Subject: Benoit Claise's Block on = charter-ietf-sacm-00-06: (with BLOCK
      > and COMMENT)
      > Date: Thu, 27 Jun 2013 06:18:24 -0= 700
      > From: Benoit Claise <bclaise@cisco.com>
      > To: The IESG <iesg@ietf.org>
      >
      > Benoit Claise has entered the foll= owing ballot position for
      > charter-ietf-sacm-00-06: Block
      >
      > When responding, please keep the s= ubject line intact and reply to all
      > email addresses included in the To= and CC lines. (Feel free to cut
      > this introductory paragraph, howev= er.)
      >
      >
      > ----------------------------------= ------------------------------------
      > BLOCK:
      > ----------------------------------= ------------------------------------
      >
      > "The working group will, when= ever reasonable and possible, reuse
      > existing protocols, mechanisms, in= formation and data models."
      >
      > Fine. Now, I really would like to = see an information model document
      > (see RFC 3444) as a deliverable.
      > And then the mapping to protocol/d= ata model.
      >
      > I had to read the charter multiple= times to get an idea of the
      > "security information" m= ight mean... Software version, patches,
      vulnerabilities.
      > Maybe it's defined by "The in= itial focus of this work is to address
      > enterprise use cases pertaining to= the assessment of endpoint posture
      > (using the definitions of Endpoint= and Posture from RFC 5209).".
      > And I'm still not quite sure. Henc= e the importance of the information
      > model as a milestone.
      >
      > "An example of such an endpoi= nt posture assessment could include, but
      > is not limited to, the following g= eneral steps:
      > 1. Identify endpoints
      > 2. Determine specific endpoint ele= ments to assess 3. Collect actual
      > value of elements 4. Compare actua= l element values to expected element
      > values 5. Report results"
      > Then I see in the next sentence of= the charter: "policy management"
      >
      > The WG scope is (too) huge: invent= ory management + monitoring + fault
      > management + policy management?
      > Please don't re-invent monitoring = and fault management.
      > Is policy management in scope or n= ot? I guess no.
      > And inventory: I understand that i= t means device inventory, but I see
      > later also "vulnerability ide= ntifiers".
      > Clearly mentions what's in scope a= nd what is not.
      >
      >
      > ----------------------------------= ------------------------------------
      > COMMENT:
      > ----------------------------------= ------------------------------------
      >
      > "Repository protocols are nee= ded to store, update, and retrieve
      > configuration checks and other typ= es of content required for posture
      > assessment (see step 2 above).&quo= t;
      > I don't know what a repository pro= tocol is.
      > __________________________________= _____________
      > sacm mailing list
      > sacm@ietf.org
      > https://www.ietf.org/mailman/listinfo/sacm<= /u>
      >
      _______________________________________= ________
      sacm mailing list
      sacm@ietf.org
      https://www.ietf= .org/mailman/listinfo/sacm
      ...
      This message and attachments may contai= n confidential information.  If
      it appears that this message was sent t= o you by mistake, any retention,
      dissemination, distribution or copying = of this message and attachments
      is strictly prohibited.  Please no= tify the sender immediately and
      permanently delete the message and any = attachments.
      _______________________________________= ________
      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

...

This message and attachments may contain confidential information. If i= t 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 perman= ently delete the message and any attachments._______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm<= /tt>

= --1__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831-- --0__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=08BBF104DFC4C8318f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=08BBF104DFC4C8318f9e8a93df938690918c08BBF104DFC4C831-- From turners@ieca.com Thu Jun 27 09:11:59 2013 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 750EE21F9E71 for ; Thu, 27 Jun 2013 09:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.666 X-Spam-Level: X-Spam-Status: No, score=-99.666 tagged_above=-999 required=5 tests=[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 PN0UqcKPcTD0 for ; Thu, 27 Jun 2013 09:11:54 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.70.6]) by ietfa.amsl.com (Postfix) with ESMTP id 568E521F9E1F for ; Thu, 27 Jun 2013 09:11:54 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id EB1FE6A7BC440; Thu, 27 Jun 2013 11:11:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id D83036A7BC3E7 for ; Thu, 27 Jun 2013 11:11:53 -0500 (CDT) Received: from [198.180.150.142] (port=50129 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsEnZ-0000lJ-Dp; Thu, 27 Jun 2013 11:11:53 -0500 Message-ID: <51CC6448.3080101@ieca.com> Date: Thu, 27 Jun 2013 12:11:52 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Montville , "dromasca@avaya.com" References: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com>, <3CBA099FBA0AB843895D72474092B8CF2B8FAF@MIVEXAMER1N1.corp.nai.org> <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:50129 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "kathleen.moriarty@emc.com" , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:11:59 -0000 We're all thinking the same thing because that's what I suggested his counter point was that the information will grow while the architecture draft ought to remain fixed. I can see it go either way. I'll see if he'll buy off on Dan's proposal. We can always merge or split drafts later. As to the milestones I like to make 'em think, but I'll add your suggestions ;) spt On 6/27/13 11:20 AM, Adam Montville wrote: > This seems to be the real issue. We could wait and break it out later > (I assume "it" is the data model information), but then it looks like we > don't really know what we're going to deliver because we don't have it > explicitly listed. > > I am amenable to adding the deliverable as Dan has proposed. Such a > deliverable could end up being a full-on technical specification or an > applicability statement referencing existing work. > > Adam > > > ------------------------------------------------------------------------ > *From:* sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of > Kent_Landfield@McAfee.com [Kent_Landfield@McAfee.com] > *Sent:* Thursday, June 27, 2013 7:49 AM > *To:* dromasca@avaya.com; Adam Montville; kathleen.moriarty@emc.com; > turners@ieca.com > *Cc:* sacm@ietf.org > *Subject:* Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00-06: (with BLOCK and COMMENT) > > I would think that should be a part of the architecture document and if > it needed expanding then we could break it out later. > > The Milestones are listed in the draft charter at > http://datatracker.ietf.org/wg/sacm/charter/ > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: , "Dan (Dan)" > > Date: Thursday, June 27, 2013 4:40 PM > To: Adam Montville >, Kathleen Moriarty > >, Sean > Turner > > Cc: "sacm@ietf.org " > > Subject: Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00-06: (with BLOCK and COMMENT) > > From the operational perspective what I believe Benoit would like > to see added is a deliverable that looks like: > > - A standards-track document specifying the informational model for > endpoints data posture and its mapping into the protocol and data > format for > collecting actual endpoint posture > > We can argue that the information model can be part of the SACM > architecture document. > > Do we need a data model deliverable now? Maybe this can be the > object of a later charter. This phase being focused on defining the > architecture (including information model), protocols and data > formats (data modeling language) - a later phase or another WG can > deal with the data models specific to the various functions. > > I would also observe that we did not define Milestones in the > proposed charter. I am surprised that no AD raised a BLOCK about it. > > Should it be something like: > > - Initial submission of SACM Architecture Internet-Draft - October 2013 > - Initial submission of protocol and data format for retrieving > configuration and policy information for driving data collection and > analysis Internet-Draft - January 2014 > - Initial submission of protocol and data format for collecting > endpoint posture Internet-Draft - January 2014 > - Submit SACM Architecture Internet-Draft to the IESG for > consideration as Informational RFC - May 2014 > - Submit protocol and data format for retrieving configuration and > policy information for driving data collection and analysis > Internet-Draft to the IESG for consideration as Proposed Standard - > September 2014 > - Submit protocol and data format for collecting endpoint posture > Internet-Draft to the IESG for consideration as Proposed Standard - > September 2014 > > Dan > > -----Original Message----- > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, June 27, 2013 5:16 PM > To: Moriarty, Kathleen; Sean Turner > Cc: sacm@ietf.org > Subject: Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00- > 06: (with BLOCK and COMMENT) > Agree. > This domain is problematic in describing scope for the reasons I > have > previously mentioned - assessing posture (a security use case) is > something that undoubtedly touches a lot of other related areas and > efforts. As Kathleen points out, reuse is a key to managing scope. > Adam > ________________________________________ > From: sacm-bounces@ietf.org > [sacm-bounces@ietf.org ] on behalf of > Moriarty, Kathleen [kathleen.moriarty@emc.com > ] > Sent: Thursday, June 27, 2013 7:04 AM > To: Sean Turner > Cc: sacm@ietf.org > Subject: Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00- > 06: (with BLOCK and COMMENT) > Hi Sean, > The second one could be changed to repository access protocol > and you > can list a RESTful interface as an example. > For the first, reuse will make the scope possible. There is no > intention of reinventing the wheel, but rather to provide > uniform ways > to perform these functions where we may need to create mappings or > relationships between existing methods. In some cases, we may > need to > select from proposed methods, improve or combine them. > Thanks, > Kathleen > Sent from my iPhone > On Jun 27, 2013, at 9:34 AM, "Sean Turner" > wrote: > > Another block. > > > > Since the call is in about 2 hours I don't really expect to resolve > > these now, but be thinking about how we might address Benoit's points. > > These kind of comments should come as no surprise being that he's the > > management AD and management is the proposed wg's name. > > > > spt > > > > > > -------- Original Message -------- > > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > > and COMMENT) > > Date: Thu, 27 Jun 2013 06:18:24 -0700 > > From: Benoit Claise > > > To: The IESG > > > > > Benoit Claise has entered the following ballot position for > > charter-ietf-sacm-00-06: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > "The working group will, whenever reasonable and possible, reuse > > existing protocols, mechanisms, information and data models." > > > > Fine. Now, I really would like to see an information model document > > (see RFC 3444) as a deliverable. > > And then the mapping to protocol/data model. > > > > I had to read the charter multiple times to get an idea of the > > "security information" might mean... Software version, patches, > vulnerabilities. > > Maybe it's defined by "The initial focus of this work is to address > > enterprise use cases pertaining to the assessment of endpoint posture > > (using the definitions of Endpoint and Posture from RFC 5209).". > > And I'm still not quite sure. Hence the importance of the information > > model as a milestone. > > > > "An example of such an endpoint posture assessment could include, but > > is not limited to, the following general steps: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess 3. Collect actual > > value of elements 4. Compare actual element values to expected element > > values 5. Report results" > > Then I see in the next sentence of the charter: "policy management" > > > > The WG scope is (too) huge: inventory management + monitoring + fault > > management + policy management? > > Please don't re-invent monitoring and fault management. > > Is policy management in scope or not? I guess no. > > And inventory: I understand that it means device inventory, but I see > > later also "vulnerability identifiers". > > Clearly mentions what's in scope and what is not. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > "Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for posture > > assessment (see step 2 above)." > > I don't know what a repository protocol is. > > _______________________________________________ > > 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 > ... > 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. > _______________________________________________ > 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 > > > ... > > 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 turners@ieca.com Thu Jun 27 09:16:10 2013 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 75E1621F9CD5 for ; Thu, 27 Jun 2013 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.666 X-Spam-Level: X-Spam-Status: No, score=-99.666 tagged_above=-999 required=5 tests=[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 hyITZbSCIYaz for ; Thu, 27 Jun 2013 09:16:05 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.16.76]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0E21F9D48 for ; Thu, 27 Jun 2013 09:16:05 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 93D099A56892A; Thu, 27 Jun 2013 11:15:51 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 78F589A5688A1 for ; Thu, 27 Jun 2013 11:15:51 -0500 (CDT) Received: from [198.180.150.142] (port=50138 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsErb-0002n5-QV; Thu, 27 Jun 2013 11:16:03 -0500 Message-ID: <51CC6543.6050305@ieca.com> Date: Thu, 27 Jun 2013 12:16:03 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com>, <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:50138 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Moriarty, Kathleen" , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:16:10 -0000 I love the instant gratification of jabber. Benoit's point was the mapping should be in the DM so if we simply went to: A standards-track document specifying the informational model for endpoints data posture he'd be happy spt On 6/27/13 10:40 AM, Romascanu, Dan (Dan) wrote: >>From the operational perspective what I believe Benoit would like to see added is a deliverable that looks like: > > - A standards-track document specifying the informational model for endpoints data posture and its mapping into the protocol and data format for > collecting actual endpoint posture > > We can argue that the information model can be part of the SACM architecture document. > > Do we need a data model deliverable now? Maybe this can be the object of a later charter. This phase being focused on defining the architecture (including information model), protocols and data formats (data modeling language) - a later phase or another WG can deal with the data models specific to the various functions. > > I would also observe that we did not define Milestones in the proposed charter. I am surprised that no AD raised a BLOCK about it. > > Should it be something like: > > - Initial submission of SACM Architecture Internet-Draft - October 2013 > - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft - January 2014 > - Initial submission of protocol and data format for collecting endpoint posture Internet-Draft - January 2014 > - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC - May 2014 > - Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard - September 2014 > - Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard - September 2014 > > Dan > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Thursday, June 27, 2013 5:16 PM >> To: Moriarty, Kathleen; Sean Turner >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- >> 06: (with BLOCK and COMMENT) >> >> Agree. >> >> This domain is problematic in describing scope for the reasons I have >> previously mentioned - assessing posture (a security use case) is >> something that undoubtedly touches a lot of other related areas and >> efforts. As Kathleen points out, reuse is a key to managing scope. >> >> Adam >> >> ________________________________________ >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of >> Moriarty, Kathleen [kathleen.moriarty@emc.com] >> Sent: Thursday, June 27, 2013 7:04 AM >> To: Sean Turner >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- >> 06: (with BLOCK and COMMENT) >> >> Hi Sean, >> >> The second one could be changed to repository access protocol and you >> can list a RESTful interface as an example. >> >> For the first, reuse will make the scope possible. There is no >> intention of reinventing the wheel, but rather to provide uniform ways >> to perform these functions where we may need to create mappings or >> relationships between existing methods. In some cases, we may need to >> select from proposed methods, improve or combine them. >> >> Thanks, >> Kathleen >> >> Sent from my iPhone >> >> On Jun 27, 2013, at 9:34 AM, "Sean Turner" wrote: >> >>> Another block. >>> >>> Since the call is in about 2 hours I don't really expect to resolve >>> these now, but be thinking about how we might address Benoit's points. >>> These kind of comments should come as no surprise being that he's the >>> management AD and management is the proposed wg's name. >>> >>> spt >>> >>> >>> -------- Original Message -------- >>> Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK >>> and COMMENT) >>> Date: Thu, 27 Jun 2013 06:18:24 -0700 >>> From: Benoit Claise >>> To: The IESG >>> >>> Benoit Claise has entered the following ballot position for >>> charter-ietf-sacm-00-06: Block >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut >>> this introductory paragraph, however.) >>> >>> >>> ---------------------------------------------------------------------- >>> BLOCK: >>> ---------------------------------------------------------------------- >>> >>> "The working group will, whenever reasonable and possible, reuse >>> existing protocols, mechanisms, information and data models." >>> >>> Fine. Now, I really would like to see an information model document >>> (see RFC 3444) as a deliverable. >>> And then the mapping to protocol/data model. >>> >>> I had to read the charter multiple times to get an idea of the >>> "security information" might mean... Software version, patches, >> vulnerabilities. >>> Maybe it's defined by "The initial focus of this work is to address >>> enterprise use cases pertaining to the assessment of endpoint posture >>> (using the definitions of Endpoint and Posture from RFC 5209).". >>> And I'm still not quite sure. Hence the importance of the information >>> model as a milestone. >>> >>> "An example of such an endpoint posture assessment could include, but >>> is not limited to, the following general steps: >>> 1. Identify endpoints >>> 2. Determine specific endpoint elements to assess 3. Collect actual >>> value of elements 4. Compare actual element values to expected element >>> values 5. Report results" >>> Then I see in the next sentence of the charter: "policy management" >>> >>> The WG scope is (too) huge: inventory management + monitoring + fault >>> management + policy management? >>> Please don't re-invent monitoring and fault management. >>> Is policy management in scope or not? I guess no. >>> And inventory: I understand that it means device inventory, but I see >>> later also "vulnerability identifiers". >>> Clearly mentions what's in scope and what is not. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> "Repository protocols are needed to store, update, and retrieve >>> configuration checks and other types of content required for posture >>> assessment (see step 2 above)." >>> I don't know what a repository protocol is. >>> _______________________________________________ >>> 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 >> >> ... >> >> 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. >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > From ietfdbh@comcast.net Thu Jun 27 09:16:42 2013 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 4F65521F9E16 for ; Thu, 27 Jun 2013 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.838 X-Spam-Level: X-Spam-Status: No, score=-97.838 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 U8s0SMH6lKzY for ; Thu, 27 Jun 2013 09:16:36 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 59F5421F9DAF for ; Thu, 27 Jun 2013 09:16:36 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id tQ2A1l0041ei1Bg58UGbqa; Thu, 27 Jun 2013 16:16:35 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta24.westchester.pa.mail.comcast.net with comcast id tUGa1l0142yZEBF3kUGb6q; Thu, 27 Jun 2013 16:16:35 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , "'Adam Montville'" , "'Moriarty, Kathleen'" , "'Sean Turner'" References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com>, <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> Date: Thu, 27 Jun 2013 12:16:18 -0400 Message-ID: <019e01ce7351$a83146f0$f893d4d0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHTavWM+hhGxmnxZKXAbP5vFdiuBAEkI1wOAawuqeoDLVycyQL2WAQZmPgZFUA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372349795; bh=ifD4gYjZ7rG+y345cX8z8zyC2MMiAEwUSE6/sAE/Krs=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ipkNV9D5GzQCGATh6dKIMDTMbUqNQGQgHXUrsyOLjJVjxAl1vzFNu7687hk9+7PR+ cwvzrp28M++fV6bvoVZCpmJureaFWPU1/iZkTunVRGPZLvzZfIAawr7ckPDgyW/lEQ RbByN/IxDqfZyRcCIBiLt3criv9z+EdQB69qC0ftNWFdNQTKGJEdmVaTewCpFI4yQv gkJjBWq7U2HTQwhhEEfoKXVKfl8aEP6RzlSnYgehPQu57ltWKn9YTIppQN2X8uUu0x gXP37jEEPATShv2vtm/7BFPDUNC9+z3lW+IHrmK9/q9HvbrqdxG10yZIYDa5Lx5zyO 3Pa8UfI+YZm2g== Cc: sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:16:42 -0000 Hi, I have found it difficult to suss out just what this WG plans to standardize for information. "Security automation" covers a huge scope, and despite pressing for more details, including to document in the use-cases document, I have been unable to get much of anything that better scopes the information involved. In my requests for use cases, I keep getting emails that say "you should look at the work being done in organization." Few have actually contributed proposals for IETF consideration, or provided details useable for use cases. The information model is a major area of discussion yet to be discussed, and it could be contentious. I think the information model should be a separate document from the architecture. That helps keep each effort manageable. David Harrington ietfdbh@comcast.net +1-603-828-1401 From dromasca@avaya.com Thu Jun 27 09:19:17 2013 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 DD32021F9D02 for ; Thu, 27 Jun 2013 09:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=-0.499, 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 7oMNE3R0wscY for ; Thu, 27 Jun 2013 09:19:11 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0D921F9D0A for ; Thu, 27 Jun 2013 09:19:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAI9lzFHGmAcF/2dsb2JhbABYA4JoIXq/C4EAFnSCIwEBAQEDEig/DAQCAQgNBAEDAQELFAkHMhQDBggCBAENBQgah1oDDwGfO5MGCIhAF48kIRAHBguCcWMDngmLAYFYgTmCKA X-IronPort-AV: E=Sophos;i="4.87,953,1363147200"; d="scan'208";a="18019946" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Jun 2013 12:19:08 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jun 2013 12:16:40 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 12:19:07 -0400 From: "Romascanu, Dan (Dan)" To: ietfdbh , 'Adam Montville' , "'Moriarty, Kathleen'" , 'Sean Turner' Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: AQHOczsVIyzy33Rs5kyF4TP6qh4485lJ2tSAgAADaYD//71bIP///7kAgAAh7nA= Date: Thu, 27 Jun 2013 16:19:07 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1B3E1B@AZ-FFEXMB04.global.avaya.com> References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com>, <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> <019e01ce7351$a83146f0$f893d4d0$@comcast.net> In-Reply-To: <019e01ce7351$a83146f0$f893d4d0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:19:18 -0000 Yes, this would be an advantage - plus it would allow an evolution of the I= M that is not tied into the architecture document.=20 Regards, Dan > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Thursday, June 27, 2013 7:16 PM > To: Romascanu, Dan (Dan); 'Adam Montville'; 'Moriarty, Kathleen'; 'Sean > Turner' > Cc: sacm@ietf.org > Subject: RE: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- > 06: (with BLOCK and COMMENT) >=20 > Hi, >=20 > I have found it difficult to suss out just what this WG plans to > standardize for information. > "Security automation" covers a huge scope, and despite pressing for more > details, including to document in the use-cases document, I have been > unable to get much of anything that better scopes the information > involved. > In my requests for use cases, I keep getting emails that say "you should > look at the work being done in organization." > Few have actually contributed proposals for IETF consideration, or > provided details useable for use cases. >=20 > The information model is a major area of discussion yet to be discussed, > and it could be contentious. > I think the information model should be a separate document from the > architecture. > That helps keep each effort manageable. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 From kathleen.moriarty@emc.com Thu Jun 27 09:38:21 2013 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 E766021F9E2D for ; Thu, 27 Jun 2013 09:38:21 -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=[none] 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 Ej9o0ktEe1Vw for ; Thu, 27 Jun 2013 09:38:16 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0321F9DF5 for ; Thu, 27 Jun 2013 09:38:14 -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 r5RGc7X6020337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 12:38:07 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 27 Jun 2013 12:37:50 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5RGbn02001855; Thu, 27 Jun 2013 12:37:49 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 27 Jun 2013 12:37:49 -0400 From: "Moriarty, Kathleen" To: ietfdbh Date: Thu, 27 Jun 2013 12:37:44 -0400 Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: Ac5zVKkPEYiXWrOwS+eU/aiTRBAUQA== Message-ID: References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com> <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> <019e01ce7351$a83146f0$f893d4d0$@comcast.net> In-Reply-To: <019e01ce7351$a83146f0$f893d4d0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Romascanu, Dan \(Dan\)" , Sean Turner , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:38:22 -0000 Hi, As for a use case and how the work is scoped down, here is an example. Currently, security teams need to follow hardening guides and lock down sys= tem and applications on each system (or device), an image of that system, o= r through a vendor provided management system specific to that vendor. The= compliance and audit teams have to assess those controls, often through so= me manual tasks on a regular basis for all different regulations or just re= porting cycles. We would like a uniform method to set, monitor and enforce security control= s across platforms and vendors. The regulatory controls and high-level con= trol frameworks have already been defined. We also have guidance on what n= eeds to be locked down on systems to meet a desired assurance level. We ha= ve methods to configure devices (numerous ones). We need a common way to m= ap between these existing protocols with a common language to enable consis= tent monitoring and management. We need to aggregate this data and assess = the overall security state of a system as well as the network. That's wher= e the protocols come in to play for repositories, etc. if we can provide t= he consistent capability, then vendors and security professionals can help = with the per-product mappings to get us away from the manual hardening, ass= essment and reporting. =20 I am sure there are other use cases, but thought this might be a helpful ex= planation. Thanks, Kathleen=20 Sent from my iPhone On Jun 27, 2013, at 12:17 PM, "ietfdbh" wrote: > Hi, >=20 > I have found it difficult to suss out just what this WG plans to standard= ize > for information. > "Security automation" covers a huge scope, and despite pressing for more > details, including to document in the use-cases document, I have been una= ble > to get much of anything that better scopes the information involved. > In my requests for use cases, I keep getting emails that say "you should > look at the work being done in organization." > Few have actually contributed proposals for IETF consideration, or provid= ed > details useable for use cases. >=20 > The information model is a major area of discussion yet to be discussed, = and > it could be contentious. > I think the information model should be a separate document from the > architecture. > That helps keep each effort manageable. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 From ietfdbh@comcast.net Thu Jun 27 09:58:35 2013 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 C8ADA21F9E30 for ; Thu, 27 Jun 2013 09:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.138 X-Spam-Level: X-Spam-Status: No, score=-99.138 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 F2qqEedREgh0 for ; Thu, 27 Jun 2013 09:58:29 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDCE21F9D79 for ; Thu, 27 Jun 2013 09:58:29 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id tRPT1l0051ap0As51UyMRo; Thu, 27 Jun 2013 16:58:21 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta22.westchester.pa.mail.comcast.net with comcast id tUyL1l00l2yZEBF3iUyLrW; Thu, 27 Jun 2013 16:58:21 +0000 From: "ietfdbh" To: "'Sean Turner'" , References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com> <51CC4C90.6040107@ieca.com> In-Reply-To: <51CC4C90.6040107@ieca.com> Date: Thu, 27 Jun 2013 12:58:03 -0400 Message-ID: <01a801ce7357$7d6541a0$782fc4e0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHTavWM+hhGxmnxZKXAbP5vFdiuBAEkI1wOAkWyXoiZJH9CgA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372352301; bh=dCvYpg/rm1H8NhuQazHBch+kCiBdL44jetiF/QA7M1M=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=WxNJLSDl0SWYTmd6XqU7bB9YkNg+6AkHkgwfI3jA0k/D5nMA2XLc6i94YLOvBXBcf CgyUSd1nMUF/Mgp1gqwUpUfQVfZwS2Y0iPNZkGOwz6qUE8Gd8AcePf94vLaG00uZOy ojgrx470PrC3yBGhG9qIcolZt3XVDH+/2xSAsrBrLNeJFI+S96KzI2VdlnbDWiaZY9 7e97010WezV2LzA4ysZUg+G/J16/Jn8niOw7ic7qqewXfXvjvRKpLXWtyWy66TL2ht kOuiJkoM1GQJVxuzVmre9Of3svCFEF7CM5r/zuNnCrepLLzczEa3BGJ3+e5D/dJ19V zDXWnZBbOwsgg== Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:58:36 -0000 > On 6/27/13 9:34 AM, Sean Turner wrote: > > Another block. > > > > Since the call is in about 2 hours I don't really expect to resolve > > these now, but be thinking about how we might address Benoit's points. > > These kind of comments should come as no surprise being that he's the > > management AD and management is the proposed wg's name. > > > > spt Why is this work not being proposed in the OPS/NM Area, which typically is responsible for management protocols and management data modeling languages, to execute on the operational requirements identified by operators? Aren't they likely to have the best expertise on the existing standard management protocols and DMLs available, as well as expertise on existing data models? That area, with the NMRG and IAB, has done extensive work understanding user (operator) requirements relevant to this work, such as RFC3198 Terminology for Policy-based Management, RFC3535 Overview of the 2002 IAB Network Management Workshop, RFC3444 On the Difference between Information Models and Data Models, multiple management-related information models, and of course lots of data models. Importantly, OPS/NM also has pretty extensive knowledge of what has and has not worked in the past regarding IETF standard management protocols and DMLs, especially policy-driven management. From kathleen.moriarty@emc.com Thu Jun 27 10:09:18 2013 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 6207D21F99BA for ; Thu, 27 Jun 2013 10:09:18 -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 YaOEAOYa0DGl for ; Thu, 27 Jun 2013 10:09:14 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1072A21F99A0 for ; Thu, 27 Jun 2013 10:09:13 -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 r5RH989D021846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 13:09:09 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 27 Jun 2013 13:08:59 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5RH8xbH002216; Thu, 27 Jun 2013 13:08:59 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Thu, 27 Jun 2013 13:08:58 -0400 From: "Moriarty, Kathleen" To: ietfdbh Date: Thu, 27 Jun 2013 13:08:55 -0400 Thread-Topic: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) Thread-Index: Ac5zWQM6eNYmbXiMR7OnB2nI+LS1+Q== Message-ID: <6A9B09F4-4BEC-4AA4-B2E6-6DAB5B2FF941@emc.com> References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com> <51CC4C90.6040107@ieca.com> <01a801ce7357$7d6541a0$782fc4e0$@comcast.net> In-Reply-To: <01a801ce7357$7d6541a0$782fc4e0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: Sean Turner , "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:09:18 -0000 Wherever it winds up is fine with me. Please remember that the group bring= ing the work in also has experience and 50 implementations of some of the p= roposed work. They do want to benefit from the experience of various group= s in the IETF. Thank you, Kathleen=20 Sent from my iPhone On Jun 27, 2013, at 12:59 PM, "ietfdbh" wrote: >> On 6/27/13 9:34 AM, Sean Turner wrote: >>> Another block. >>>=20 >>> Since the call is in about 2 hours I don't really expect to resolve >>> these now, but be thinking about how we might address Benoit's points. >>> These kind of comments should come as no surprise being that he's the >>> management AD and management is the proposed wg's name. >>>=20 >>> spt >=20 > Why is this work not being proposed in the OPS/NM Area, which typically i= s > responsible for management protocols and management data modeling languag= es, > to execute on the operational requirements identified by operators? Aren'= t > they likely to have the best expertise on the existing standard managemen= t > protocols and DMLs available, as well as expertise on existing data model= s? > That area, with the NMRG and IAB, has done extensive work understanding u= ser > (operator) requirements relevant to this work, such as RFC3198 Terminolog= y > for Policy-based Management, RFC3535 Overview of the 2002 IAB Network > Management Workshop, RFC3444 On the Difference between Information Models > and Data Models, multiple management-related information models, and of > course lots of data models.=20 >=20 > Importantly, OPS/NM also has pretty extensive knowledge of what has and h= as > not worked in the past regarding IETF standard management protocols and > DMLs, especially policy-driven management.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From hannes.tschofenig@gmx.net Thu Jun 27 12:03:31 2013 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 3470B21F9DDE for ; Thu, 27 Jun 2013 12:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwTVSV8h1OPL for ; Thu, 27 Jun 2013 12:03:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id AE2AB21F9DEB for ; Thu, 27 Jun 2013 12:03:25 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MhOyy-1UfifP0NKU-00MeSu for ; Thu, 27 Jun 2013 21:03:25 +0200 Received: (qmail invoked by alias); 27 Jun 2013 19:03:24 -0000 Received: from host-94-101-1-228.igua.fi (EHLO [192.168.4.115]) [94.101.1.228] by mail.gmx.net (mp034) with SMTP; 27 Jun 2013 21:03:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19a8N4si4taTGBbq1PXaxLAbx7xccs8LwKY4NzOeL 09/4hdmM7qwkKa From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jun 2013 22:03:23 +0300 Message-Id: <67DD3175-2B71-4A55-BE1B-10EB31A5C802@gmx.net> To: sacm@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [sacm] Fwd: Workshop on Security Incident Information Sharing (July 26 2013, Berlin) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 19:03:31 -0000 In case someone of you has not yet seen the workshop announcement. We = are also planning to cover the SACM work.=20 Begin forwarded message: > From: Hannes Tschofenig > Date: June 25, 2013 12:40:08 AM GMT+03:00 > To: 87attendees@ietf.org > Cc: Hannes Tschofenig > Subject: Workshop on Security Incident Information Sharing (July 26 = 2013, Berlin) >=20 > [Sorry if you see this message twice. I had accidentally posted it to = the IETF#86 attendees list...] >=20 > Hi all,=20 >=20 > We would like to invite you to participate in the upcoming half-day = workshop on Security Incident Information Sharing (SIIS). It is = scheduled on July 26 (Friday), 2013 in Berlin, Germany, the Friday = before the next IETF meeting. >=20 > You might find this workshop interesting if you want to learn about = the IETF standardization work in that area, or if you want to share your = experience in that area. Incident information sharing has gotten more = attention recently as governments develop their ideas on how to increase = Internet security. For example, Article 14 of the proposed EU = Cybersecurity Directive contains provisions regarding incident sharing = and the recently launched "Network and Information Security Platform" = will have a working group on the same topic as well. Similar = developments also happen in other parts of the world.=20 >=20 > Details about the workshop can be found on the following web site: = http://siis.realmv6.org/ >=20 > Registration is required (for room planning purposes). There is no = requirement to submit a position paper and the workshop is free of = charge.=20 >=20 > Ciao > Hannes >=20 From turners@ieca.com Thu Jun 27 21:19:42 2013 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 B3CCA11E8167 for ; Thu, 27 Jun 2013 21:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 7S4krQ8eEbvu for ; Thu, 27 Jun 2013 21:19:16 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.93.35.7]) by ietfa.amsl.com (Postfix) with ESMTP id BEE4411E8133 for ; Thu, 27 Jun 2013 21:19:16 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id AFEE1BF4774DB; Thu, 27 Jun 2013 23:19:15 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id A3ECEBF4774BA for ; Thu, 27 Jun 2013 23:19:15 -0500 (CDT) Received: from [173.73.135.86] (port=50384 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsQ9T-0002mW-8w; Thu, 27 Jun 2013 23:19:15 -0500 Message-ID: <51CD0EC2.70009@ieca.com> Date: Fri, 28 Jun 2013 00:19:14 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com>, <3CBA099FBA0AB843895D72474092B8CF2B8FAF@MIVEXAMER1N1.corp.nai.org> <05BCCEB107AF88469B9F99783D47C1D6702628@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA1B3D93@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1B3D93@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:50384 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "kathleen.moriarty@emc.com" , Adam Montville , "Kent_Landfield@McAfee.com" , "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) 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, 28 Jun 2013 04:19:42 -0000 I cut the wrong text in. Benoit pointed this out and I've pasted the right version in. spt On 6/27/13 11:55 AM, Romascanu, Dan (Dan) wrote: > Sorry, I was looking at another page which did not have the milestones > listed. > > Just to make sure that we have the same understanding about the > differentiation made between information model and data model – Benoit > is using the terminology defined by > http://www.rfc-editor.org/rfc/rfc3444.txt > > Regards, > > Dan > > *From:*Adam Montville [mailto:Adam.Montville@cisecurity.org] > *Sent:* Thursday, June 27, 2013 6:20 PM > *To:* Kent_Landfield@McAfee.com; Romascanu, Dan (Dan); > kathleen.moriarty@emc.com; turners@ieca.com > *Cc:* sacm@ietf.org > *Subject:* RE: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00-06: (with BLOCK and COMMENT) > > This seems to be the real issue. We could wait and break it out later > (I assume "it" is the data model information), but then it looks like we > don't really know what we're going to deliver because we don't have it > explicitly listed. > > I am amenable to adding the deliverable as Dan has proposed. Such a > deliverable could end up being a full-on technical specification or an > applicability statement referencing existing work. > > Adam > > ------------------------------------------------------------------------ > > *From:*sacm-bounces@ietf.org > [sacm-bounces@ietf.org] on behalf of Kent_Landfield@McAfee.com > [Kent_Landfield@McAfee.com] > *Sent:* Thursday, June 27, 2013 7:49 AM > *To:* dromasca@avaya.com ; Adam Montville; > kathleen.moriarty@emc.com ; > turners@ieca.com > *Cc:* sacm@ietf.org > *Subject:* Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00-06: (with BLOCK and COMMENT) > > I would think that should be a part of the architecture document and if > it needed expanding then we could break it out later. > > The Milestones are listed in the draft charter at > http://datatracker.ietf.org/wg/sacm/charter/ > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *, "Dan (Dan)" > > *Date: *Thursday, June 27, 2013 4:40 PM > *To: *Adam Montville >, Kathleen Moriarty > >, Sean > Turner > > *Cc: *"sacm@ietf.org " > > *Subject: *Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00-06: (with BLOCK and COMMENT) > > From the operational perspective what I believe Benoit would like > to see added is a deliverable that looks like: > > - A standards-track document specifying the informational model for > endpoints data posture and its mapping into the protocol and data > format for > > collecting actual endpoint posture > > We can argue that the information model can be part of the SACM > architecture document. > > Do we need a data model deliverable now? Maybe this can be the > object of a later charter. This phase being focused on defining the > architecture (including information model), protocols and data > formats (data modeling language) - a later phase or another WG can > deal with the data models specific to the various functions. > > I would also observe that we did not define Milestones in the > proposed charter. I am surprised that no AD raised a BLOCK about it. > > Should it be something like: > > - Initial submission of SACM Architecture Internet-Draft - October 2013 > > - Initial submission of protocol and data format for retrieving > configuration and policy information for driving data collection and > analysis Internet-Draft - January 2014 > > - Initial submission of protocol and data format for collecting > endpoint posture Internet-Draft - January 2014 > > - Submit SACM Architecture Internet-Draft to the IESG for > consideration as Informational RFC - May 2014 > > - Submit protocol and data format for retrieving configuration and > policy information for driving data collection and analysis > Internet-Draft to the IESG for consideration as Proposed Standard - > September 2014 > > - Submit protocol and data format for collecting endpoint posture > Internet-Draft to the IESG for consideration as Proposed Standard - > September 2014 > > Dan > > -----Original Message----- > > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Adam Montville > > Sent: Thursday, June 27, 2013 5:16 PM > > To: Moriarty, Kathleen; Sean Turner > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00- > > 06: (with BLOCK and COMMENT) > > Agree. > > This domain is problematic in describing scope for the reasons I > have > > previously mentioned - assessing posture (a security use case) is > > something that undoubtedly touches a lot of other related areas and > > efforts. As Kathleen points out, reuse is a key to managing scope. > > Adam > > ________________________________________ > > From: sacm-bounces@ietf.org > [sacm-bounces@ietf.org ] on behalf of > > Moriarty, Kathleen [kathleen.moriarty@emc.com > ] > > Sent: Thursday, June 27, 2013 7:04 AM > > To: Sean Turner > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Fwd: Benoit Claise's Block on > charter-ietf-sacm-00- > > 06: (with BLOCK and COMMENT) > > Hi Sean, > > The second one could be changed to repository access protocol > and you > > can list a RESTful interface as an example. > > For the first, reuse will make the scope possible. There is no > > intention of reinventing the wheel, but rather to provide > uniform ways > > to perform these functions where we may need to create mappings or > > relationships between existing methods. In some cases, we may > need to > > select from proposed methods, improve or combine them. > > Thanks, > > Kathleen > > Sent from my iPhone > > On Jun 27, 2013, at 9:34 AM, "Sean Turner" > wrote: > > > Another block. > > > > > > Since the call is in about 2 hours I don't really expect to resolve > > > these now, but be thinking about how we might address Benoit's points. > > > These kind of comments should come as no surprise being that he's the > > > management AD and management is the proposed wg's name. > > > > > > spt > > > > > > > > > -------- Original Message -------- > > > Subject: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK > > > and COMMENT) > > > Date: Thu, 27 Jun 2013 06:18:24 -0700 > > > From: Benoit Claise > > > > To: The IESG > > > > > > > Benoit Claise has entered the following ballot position for > > > charter-ietf-sacm-00-06: Block > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut > > > this introductory paragraph, however.) > > > > > > > > > ---------------------------------------------------------------------- > > > BLOCK: > > > ---------------------------------------------------------------------- > > > > > > "The working group will, whenever reasonable and possible, reuse > > > existing protocols, mechanisms, information and data models." > > > > > > Fine. Now, I really would like to see an information model document > > > (see RFC 3444) as a deliverable. > > > And then the mapping to protocol/data model. > > > > > > I had to read the charter multiple times to get an idea of the > > > "security information" might mean... Software version, patches, > > vulnerabilities. > > > Maybe it's defined by "The initial focus of this work is to address > > > enterprise use cases pertaining to the assessment of endpoint posture > > > (using the definitions of Endpoint and Posture from RFC 5209).". > > > And I'm still not quite sure. Hence the importance of the information > > > model as a milestone. > > > > > > "An example of such an endpoint posture assessment could include, but > > > is not limited to, the following general steps: > > > 1. Identify endpoints > > > 2. Determine specific endpoint elements to assess 3. Collect actual > > > value of elements 4. Compare actual element values to expected element > > > values 5. Report results" > > > Then I see in the next sentence of the charter: "policy management" > > > > > > The WG scope is (too) huge: inventory management + monitoring + fault > > > management + policy management? > > > Please don't re-invent monitoring and fault management. > > > Is policy management in scope or not? I guess no. > > > And inventory: I understand that it means device inventory, but I see > > > later also "vulnerability identifiers". > > > Clearly mentions what's in scope and what is not. > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > "Repository protocols are needed to store, update, and retrieve > > > configuration checks and other types of content required for posture > > > assessment (see step 2 above)." > > > I don't know what a repository protocol is. > > > _______________________________________________ > > > 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 > > ... > > 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. > > _______________________________________________ > > 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 > > > ... > > > 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 turners@ieca.com Thu Jun 27 21:25:17 2013 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 5BDF311E8159 for ; Thu, 27 Jun 2013 21:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 CRXpp5ytu51Z for ; Thu, 27 Jun 2013 21:25:12 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.179.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4186B11E80E1 for ; Thu, 27 Jun 2013 21:25:12 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id ADB0A923F5D63; Thu, 27 Jun 2013 23:24:32 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 9B83A923F5CF7 for ; Thu, 27 Jun 2013 23:24:32 -0500 (CDT) Received: from [173.73.135.86] (port=50385 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsQFD-00059b-I4; Thu, 27 Jun 2013 23:25:11 -0500 Message-ID: <51CD1026.2030200@ieca.com> Date: Fri, 28 Jun 2013 00:25:10 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , ietfdbh References: <20130627131824.5953.9120.idtracker@ietfa.amsl.com> <51CC3F56.9030202@ieca.com>, <8577236E-602F-4BDD-A268-10FDD323EA76@emc.com> <05BCCEB107AF88469B9F99783D47C1D67025E4@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA1B3988@AZ-FFEXMB04.global.avaya.com> <019e01ce7351$a83146f0$f893d4d0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA1B3E1B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1B3E1B@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:50385 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "'Moriarty, Kathleen'" , 'Adam Montville' , "sacm@ietf.org" Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: (with BLOCK and COMMENT) 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, 28 Jun 2013 04:25:17 -0000 Dave, I've done some editing (https://datatracker.ietf.org/doc/charter-ietf-sacm/) and based on Benoit's input the informational model is in fact a separate draft. I have not included a submit to the IESG date because I'm not sure when that might be but I'm hoping that an initial draft in Nov is too ambitious. spt On 6/27/13 12:19 PM, Romascanu, Dan (Dan) wrote: > Yes, this would be an advantage - plus it would allow an evolution of the IM that is not tied into the architecture document. > > Regards, > > Dan > > > > >> -----Original Message----- >> From: ietfdbh [mailto:ietfdbh@comcast.net] >> Sent: Thursday, June 27, 2013 7:16 PM >> To: Romascanu, Dan (Dan); 'Adam Montville'; 'Moriarty, Kathleen'; 'Sean >> Turner' >> Cc: sacm@ietf.org >> Subject: RE: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00- >> 06: (with BLOCK and COMMENT) >> >> Hi, >> >> I have found it difficult to suss out just what this WG plans to >> standardize for information. >> "Security automation" covers a huge scope, and despite pressing for more >> details, including to document in the use-cases document, I have been >> unable to get much of anything that better scopes the information >> involved. >> In my requests for use cases, I keep getting emails that say "you should >> look at the work being done in organization." >> Few have actually contributed proposals for IETF consideration, or >> provided details useable for use cases. >> >> The information model is a major area of discussion yet to be discussed, >> and it could be contentious. >> I think the information model should be a separate document from the >> architecture. >> That helps keep each effort manageable. >> >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> >> > > From RNATALE@mitre.org Thu Jun 27 21:29:22 2013 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 2D14621F9D39 for ; Thu, 27 Jun 2013 21:29:22 -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 Iz5jYKozaWG9 for ; Thu, 27 Jun 2013 21:29:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 36D5921F9971 for ; Thu, 27 Jun 2013 21:29:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFDFE2260095; Fri, 28 Jun 2013 00:29:03 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A3BD222600B9; Fri, 28 Jun 2013 00:29:03 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.23]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 00:29:03 -0400 From: "Natale, Bob" To: "Moriarty, Kathleen" Thread-Topic: DMTF VMAN work as a model for SACM "Unified Method"? Thread-Index: Ac5zuALSMJrGyLxHTjqkD7gs9dcC3A== Date: Fri, 28 Jun 2013 04:29:03 +0000 Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: [sacm] DMTF VMAN work as a model for SACM "Unified Method"? 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, 28 Jun 2013 04:29:22 -0000 Concerning Kathleen's "use case", maybe something _analogous_ to the DMTF's= VMAN, VMI, and OVF work...? See http://dmtf.org/standards/vman. Takes a bit of thought to see the parallels but, if the concept were accept= ed, then this DMTF work could provide a useful model for the "uniform metho= d to set, monitor and enforce security controls across platforms and vendor= s" that Kathleen proposes...? Avanti, BobN -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Thursday, June 27, 2013 12:38 PM To: ietfdbh Cc: Romascanu, Dan (Dan); Sean Turner; Adam Montville; sacm@ietf.org Subject: Re: [sacm] Fwd: Benoit Claise's Block on charter-ietf-sacm-00-06: = (with BLOCK and COMMENT) Hi, As for a use case and how the work is scoped down, here is an example. Currently, security teams need to follow hardening guides and lock down sys= tem and applications on each system (or device), an image of that system, o= r through a vendor provided management system specific to that vendor. The= compliance and audit teams have to assess those controls, often through so= me manual tasks on a regular basis for all different regulations or just re= porting cycles. We would like a uniform method to set, monitor and enforce security control= s across platforms and vendors. The regulatory controls and high-level con= trol frameworks have already been defined. We also have guidance on what n= eeds to be locked down on systems to meet a desired assurance level. We ha= ve methods to configure devices (numerous ones). We need a common way to m= ap between these existing protocols with a common language to enable consis= tent monitoring and management. We need to aggregate this data and assess = the overall security state of a system as well as the network. That's wher= e the protocols come in to play for repositories, etc. if we can provide t= he consistent capability, then vendors and security professionals can help = with the per-product mappings to get us away from the manual hardening, ass= essment and reporting. =20 I am sure there are other use cases, but thought this might be a helpful ex= planation. Thanks, Kathleen=20 Sent from my iPhone On Jun 27, 2013, at 12:17 PM, "ietfdbh" wrote: > Hi, >=20 > I have found it difficult to suss out just what this WG plans to standard= ize > for information. > "Security automation" covers a huge scope, and despite pressing for more > details, including to document in the use-cases document, I have been una= ble > to get much of anything that better scopes the information involved. > In my requests for use cases, I keep getting emails that say "you should > look at the work being done in organization." > Few have actually contributed proposals for IETF consideration, or provid= ed > details useable for use cases. >=20 > The information model is a major area of discussion yet to be discussed, = and > it could be contentious. > I think the information model should be a separate document from the > architecture. > That helps keep each effort manageable. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From ietf-secretariat-reply@ietf.org Thu Jun 27 09:09:53 2013 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 6420921F9E6D for ; Thu, 27 Jun 2013 09:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.913 X-Spam-Level: X-Spam-Status: No, score=-99.913 tagged_above=-999 required=5 tests=[AWL=0.088, NO_RELAYS=-0.001, 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 TvSUli7Ijkj5 for ; Thu, 27 Jun 2013 09:09:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12F21F9E6E for ; Thu, 27 Jun 2013 09:09:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: sacm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130627160952.6859.62605.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2013 09:09:52 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 28 Jun 2013 13:24:08 -0700 Subject: [sacm] Milestones changed for sacm WG X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:09:53 -0000 Deleted milestone "Initial submission of an Internet-Draft on Use Cases". Deleted milestone "Initial submission of an Internet-Draft on Requirements taking into consideration RFC5706 and RFC3535". Changed milestone "Submission to the IESG of the Internet-Draft on Use Cases for consideration as Informational RFC", set description to "Submit SACM Architecture Internet-Draft for consideration as Standards-track RFC". Changed milestone "Submission to the IESG of the Internet-Draft on Requirements for consideration as Informational RFC", set description to "Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard", set due date to September 2014 from April 2014. Changed milestone "Submission to the IESG of the Internet-Draft on SACM Architecture for consideration as Informational RFC", set description to "Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard", set due date to September 2014 from April 2014. Deleted milestone "Submission to the IESG of the Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis for consideration as standards-track RFC". Deleted milestone "Submission to the IESG of the Internet-Draft a protocol and data format for collecting actual endpoint posture for consideration as standards-track RFC". URL: http://datatracker.ietf.org/wg/sacm/charter/ From iesg-secretary@ietf.org Fri Jun 28 09:31:29 2013 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 2AB2B21F9AE1; Fri, 28 Jun 2013 09:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.491 X-Spam-Level: X-Spam-Status: No, score=-101.491 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 vkFTYv--iC7X; Fri, 28 Jun 2013 09:31:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E5121F9ADC; Fri, 28 Jun 2013 09:31:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628163127.12364.87316.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 09:31:27 -0700 X-Mailman-Approved-At: Fri, 28 Jun 2013 13:24:08 -0700 Cc: sacm WG Subject: [sacm] WG Review: Security Automation and Continuous Monitoring (sacm) 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, 28 Jun 2013 16:31:29 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08. Security Automation and Continuous Monitoring (sacm) ------------------------------------------------ Current Status: Proposed WG Chairs: Dan Romascanu Kathleen Moriarty Assigned Area Director: Sean Turner Mailing list Address: sacm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm/ Charter: Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols to collect, verify, and update system security configurations would allow this process to be automated, which would free security practitioners to focus on high priority tasks and should improve their ability to prioritize risk based on timely information about threats and vulnerabilities. Because this is a broad area of work, this working group will first address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. An example of such an endpoint posture assessment could include, but is not limited to, the following general steps: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. asset inventory, configuration settings, or vulnerabilities). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. This working group will produce the following deliverables: - A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. This may be a single standards-track document, or may be split up as the WG sees fit. - A standards-track document specifying the informational model for endpoints data posture. - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis - A standards-track document specifying a protocol and data format for collecting actual endpoint posture The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap and can be used or re-used to meet the goals of more than one working group. The working group will communicate with non-IETF organizations working on related specifications and will encourage industry participation in the development of the WG's documents. Other organizations involved in the sacm space include ISO/IEC and TCG, as well as government agencies such as NIST. SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and their configurations along with an understanding of layered defenses. Transports from MILE may be used by SACM. This charter will expire in Month Year (36 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Oct 2013 - Initial submission of SACM Architecture Internet-Draft Nov 2013 - Initial submission of SACM Information Model Internet-Draft Jan 2014 - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft Jan 2014 - Initial submission of protocol and data format for collecting endpoint posture Internet-Draft May 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC Sep 2014 - Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard Sep 2014 - Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard From iesg-secretary@ietf.org Fri Jun 28 10:18:15 2013 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 4EDC121F9AF3; Fri, 28 Jun 2013 10:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 sbOn5eg1MEJA; Fri, 28 Jun 2013 10:18:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7721F9ADC; Fri, 28 Jun 2013 10:18:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628171814.28773.49527.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 10:18:14 -0700 X-Mailman-Approved-At: Fri, 28 Jun 2013 13:24:08 -0700 Cc: sacm WG Subject: [sacm] UPDATED WG Review: Security Automation and Continuous Monitoring (sacm) 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, 28 Jun 2013 17:18:15 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08. Security Automation and Continuous Monitoring (sacm) ------------------------------------------------ Current Status: Proposed WG Chairs: Dan Romascanu Adam Montville Assigned Area Director: Sean Turner Mailing list Address: sacm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sacm Archive: http://www.ietf.org/mail-archive/web/sacm/ Charter: Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols to collect, verify, and update system security configurations would allow this process to be automated, which would free security practitioners to focus on high priority tasks and should improve their ability to prioritize risk based on timely information about threats and vulnerabilities. Because this is a broad area of work, this working group will first address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are existing industry standards, preferably IETF standards, that could support automation of asset, change, configuration, and vulnerability management. The working group will define: 1. A set of standards to enable assessment of endpoint posture. This area of focus provides for necessary language and data format specifications. An example of such an endpoint posture assessment could include, but is not limited to, the following general steps: 1. Identify endpoints 2. Determine specific endpoint elements to assess 3. Collect actual value of elements 4. Compare actual element values to expected element values 5. Report results This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic. 2. A set of standards for interacting with repositories of content related to assessment of endpoint posture. Repository protocols are needed to store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above). A content repository is expected to house specific versions of checklists (i.e. benchmarks), may be required to satisfy different use cases (i.e. asset inventory, configuration settings, or vulnerabilities). In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. This working group will produce the following deliverables: - A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system. This may be a single standards-track document, or may be split up as the WG sees fit. - A standards-track document specifying the informational model for endpoints data posture. - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis - A standards-track document specifying a protocol and data format for collecting actual endpoint posture The working group will create an Internet-Draft documenting the existing work in the IETF and in other organizations that might be used as-is or as a starting point for developing solutions to the SACM requirements. The working group may decide to make of this document an Informational RFC, but this is not a mandatory deliverable. The working group will work in close coordination with other WGs in the IETF (including, but not limited to MILE and NEA) in order to create solutions that do not overlap and can be used or re-used to meet the goals of more than one working group. The working group will communicate with non-IETF organizations working on related specifications and will encourage industry participation in the development of the WG's documents. Other organizations involved in the sacm space include ISO/IEC and TCG, as well as government agencies such as NIST. SACM-related efforts are largely aligned, and may overlap, with other IETF (and non-IETF) standardization efforts. There are common "problems" found in SACM, that may be addressed by the work done in SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular interest to SACM is understanding and respecting the distinctions between itself and NEA and MILE. One way the NEA protocols can be used is as the transport for data collected on the endpoint to an external service or data repository for further analysis and action. NEA may also serve the purpose of carrying data-collection instructions. The MILE data formats provide a format to describe incident, threat-related incident, and indicator information. SACM data formats provide ways to understand what endpoints are in your environment, whether they meet policy requirements, and their current configuration state. The data exchanged in MILE, supplementing the SACM data, creates enhanced situational awareness, thus enabling increased understanding of current threats and mitigations. The combined SACM and MILE data sets become a powerful tool to automate security with descriptions of endpoints, known vulnerabilities to those endpoints, and their configurations along with an understanding of layered defenses. Transports from MILE may be used by SACM. This charter will expire in Month Year (36 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Oct 2013 - Initial submission of SACM Architecture Internet-Draft Nov 2013 - Initial submission of SACM Information Model Internet-Draft Jan 2014 - Initial submission of protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft Jan 2014 - Initial submission of protocol and data format for collecting endpoint posture Internet-Draft May 2014 - Submit SACM Architecture Internet-Draft to the IESG for consideration as Informational RFC Sep 2014 - Submit protocol and data format for retrieving configuration and policy information for driving data collection and analysis Internet-Draft to the IESG for consideration as Proposed Standard Sep 2014 - Submit protocol and data format for collecting endpoint posture Internet-Draft to the IESG for consideration as Proposed Standard From yaronf.ietf@gmail.com Fri Jun 28 12:43:04 2013 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 DFCF921F9C08 for ; Fri, 28 Jun 2013 12:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUNFYITDYNRK for ; Fri, 28 Jun 2013 12:43:03 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3E21F9C06 for ; Fri, 28 Jun 2013 12:43:02 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so1994247wgh.7 for ; Fri, 28 Jun 2013 12:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=f7KSdcUlTRAqw5qpowDXLZ2HLq4rUtUb+KZvToivQW4=; b=oDnx+WrD941UCZcjJdoYV3viiyxtc/NTRNZoOSvMSOGUWlCotB5csJzw0H8HI5p0SL zPCa79acL/42lUM9zcqI1/kvRXMxdzUf1lpNSy6iGtYN+loIrR2N1rzQYpjPuRLlCUMy YVG5O9h4yjQ+N6HTygy77EHNOC7Fv6lTnRWgXvnkN95SwDEiFthJQvDRerI13Xy3eGhP 3iVCpnP2sf9Ehn/TNLB8gXbh505AzgwbDqKYT6ZbZ7BhEnjUtkC8/WsXsyeXnc7CBU+T P5D9Lz7vs3K0YD+nbr3F/XiNsMa2hfyjMlKfLyDJ4t2qsCAil4qATxDyDSbF1r0oqwDe HPYA== X-Received: by 10.180.36.36 with SMTP id n4mr3512817wij.0.1372448581398; Fri, 28 Jun 2013 12:43:01 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-179-102-222.red.bezeqint.net. [79.179.102.222]) by mx.google.com with ESMTPSA id h8sm8834wie.1.2013.06.28.12.43.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 12:43:00 -0700 (PDT) Message-ID: <51CDE741.1070903@gmail.com> Date: Fri, 28 Jun 2013 22:42:57 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: sacm WG References: <20130628171814.28773.49527.idtracker@ietfa.amsl.com> In-Reply-To: <20130628171814.28773.49527.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 28 Jun 2013 13:24:08 -0700 Subject: Re: [sacm] UPDATED WG Review: Security Automation and Continuous Monitoring (sacm) 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, 28 Jun 2013 19:43:04 -0000 An annoying nit in the charter: I believe the first sentence is misleading. As far as I understand, the WG is not about "securing information" in general, but rather about "securing security/posture information" or maybe "security information". Thanks, Yaron On 2013-06-28 20:18, The IESG wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-08. > > Security Automation and Continuous Monitoring (sacm) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Dan Romascanu > Adam Montville > > Assigned Area Director: > Sean Turner > > Mailing list > Address: sacm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/sacm > Archive: http://www.ietf.org/mail-archive/web/sacm/ > > Charter: > > Securing information and the systems that store, process, and transmit > that information is a challenging task for organizations of all sizes, > and many security practitioners spend much of their time on manual > processes. Standardized protocols to collect, verify, and update system > security configurations would allow this process to be automated, which > would free security practitioners to focus on high priority tasks and > should improve their ability to prioritize risk based on timely > information about threats and vulnerabilities. Because this is a broad > area of work, this working group will first address enterprise use cases > pertaining to the assessment of endpoint posture (using the definitions > of Endpoint and Posture from RFC 5209). > > The working group will, whenever reasonable and possible, reuse existing > protocols, mechanisms, information and data models. Of particular > interest to this working group are existing industry standards, > preferably IETF standards, that could support automation of asset, > change, configuration, and vulnerability management. > > The working group will define: > > 1. A set of standards to enable assessment of endpoint posture. This area > of focus provides for necessary language and data format specifications. > > An example of such an endpoint posture assessment could include, > but is not limited to, the following general steps: > > 1. Identify endpoints > > 2. Determine specific endpoint elements to assess > > 3. Collect actual value of elements > > 4. Compare actual element values to expected element values > > 5. Report results > > This approach to endpoint posture collection enables multiple policies > to be evaluated based on a single data collection activity. Policies > will be evaluated by comparing available endpoint posture data > according to rules expressed in the policy. Typically, these rules > will compare the actual value against an expected value or range for > specific posture elements. In some cases, the posture element may > pertain to software installation state, in which case the actual and > expected values may be "installed" or "not installed." Evaluation of > multiple posture elements may be combined using Boolean logic. > > 2. A set of standards for interacting with repositories of content > related to assessment of endpoint posture. > > Repository protocols are needed to store, update, and retrieve > configuration checks and other types of content required for posture > assessment (see step 2 above). A content repository is expected to > house specific versions of checklists (i.e. benchmarks), may be > required to satisfy different use cases (i.e. asset inventory, > configuration settings, or vulnerabilities). In addition, content > repositories are expected to store up-to-date dictionary of specific > enumerations, such as those used for configuration element > identifiers, asset classifications, vulnerability identifiers, and so > on. > > This working group will produce the following deliverables: > > - A document or documents describing the SACM Architecture. This will > include protocol requirements and their associated use cases as well as a > description of how SACM protocols fit together into a system. This may be > a single standards-track document, or may be split up as the WG sees fit. > - A standards-track document specifying the informational model for > endpoints data posture. > - A standards-track document specifying a protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis > - A standards-track document specifying a protocol and data format for > collecting actual endpoint posture > > The working group will create an Internet-Draft documenting the existing > work in the IETF and in other organizations that might be used as-is or > as a starting point for developing solutions to the SACM requirements. > The working group may decide to make of this document an Informational > RFC, but this is not a mandatory deliverable. > > The working group will work in close coordination with other WGs in the > IETF (including, but not limited to MILE and NEA) in order to create > solutions that do not overlap and can be used or re-used to meet the > goals of more than one working group. > > The working group will communicate with non-IETF organizations working on > related specifications and will encourage industry participation in the > development of the WG's documents. Other organizations involved in the > sacm space include ISO/IEC and TCG, as well as government agencies such > as NIST. > > SACM-related efforts are largely aligned, and may overlap, with other > IETF (and non-IETF) standardization efforts. There are common "problems" > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > interest to SACM is understanding and respecting the distinctions between > itself and NEA and MILE. > > One way the NEA protocols can be used is as the transport for data > collected on the endpoint to an external service or data repository for > further analysis and action. NEA may also serve the purpose of carrying > data-collection instructions. > > The MILE data formats provide a format to describe incident, > threat-related incident, and indicator information. SACM data formats > provide ways to understand what endpoints are in your environment, > whether they meet policy requirements, and their current configuration > state. The data exchanged in MILE, supplementing the SACM data, creates > enhanced situational awareness, thus enabling increased understanding of > current threats and mitigations. The combined SACM and MILE data sets > become a powerful tool to automate security with descriptions of > endpoints, known vulnerabilities to those endpoints, and their > configurations along with an understanding of layered defenses. > Transports from MILE may be used by SACM. > > This charter will expire in Month Year (36 months from approval). If the > charter is not updated before that time, the WG will be closed and any > remaining documents revert back to individual Internet-Drafts. > > Milestones: > Oct 2013 - Initial submission of SACM Architecture Internet-Draft > Nov 2013 - Initial submission of SACM Information Model Internet-Draft > Jan 2014 - Initial submission of protocol and data format for > retrieving configuration and policy information for driving data > collection and analysis Internet-Draft > Jan 2014 - Initial submission of protocol and data format for > collecting endpoint posture Internet-Draft > May 2014 - Submit SACM Architecture Internet-Draft to the IESG for > consideration as Informational RFC > Sep 2014 - Submit protocol and data format for retrieving configuration > and policy information for driving data collection and analysis > Internet-Draft to the IESG for consideration as Proposed Standard > Sep 2014 - Submit protocol and data format for collecting endpoint > posture Internet-Draft to the IESG for consideration as Proposed Standard > > > From turners@ieca.com Fri Jun 28 15:00:06 2013 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 6F2BD21F9D8B for ; Fri, 28 Jun 2013 15:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.268, 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 GCnwdXhufpiW for ; Fri, 28 Jun 2013 15:00:01 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.115.20]) by ietfa.amsl.com (Postfix) with ESMTP id 59A5421F9360 for ; Fri, 28 Jun 2013 15:00:01 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 515E89F610F15; Fri, 28 Jun 2013 16:59:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 4567D9F610ECC for ; Fri, 28 Jun 2013 16:59:53 -0500 (CDT) Received: from [173.73.135.86] (port=51881 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Usgi0-0006YI-AO for sacm@ietf.org; Fri, 28 Jun 2013 17:00:00 -0500 Message-ID: <51CE075F.3010601@ieca.com> Date: Fri, 28 Jun 2013 17:59:59 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:51881 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] charter update 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, 28 Jun 2013 22:00:06 -0000 The last block on the charter was lifted early this morning. The charter is here: https://datatracker.ietf.org/doc/charter-ietf-sacm/ I made some edits to resolve the blocks and comments on the charter. I believe the spirit of what the WG passed to me is still captured in the charter we just picked up one more deliverable. There is still more time for comment because the charter is going to go out for external review (see s2.3 of RFC 2418) before the IESG re-evaluates it on the 11th of July. At that time, "the IESG MAY approve the charter as-is, it MAY request that changes be made in the charter, or MAY decline to approve chartering of the working group". spt From Adam.Montville@cisecurity.org Fri Jun 28 15:42:28 2013 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 CC7DF21F9D5C for ; Fri, 28 Jun 2013 15:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxBpJVtDW6xo for ; Fri, 28 Jun 2013 15:42:24 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0A71221F9D17 for ; Fri, 28 Jun 2013 15:42:23 -0700 (PDT) Received: from [216.82.250.19:49677] by server-16.bemta-12.messagelabs.com id 12/BE-15704-D411EC15; Fri, 28 Jun 2013 22:42:21 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-87.messagelabs.com!1372459339!13226761!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 1998 invoked from network); 28 Jun 2013 22:42:20 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 28 Jun 2013 22:42:20 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 18:42:00 -0400 From: Adam Montville To: Yaron Sheffer , sacm WG Thread-Topic: [sacm] UPDATED WG Review: Security Automation and Continuous Monitoring (sacm) Thread-Index: AQHOdD13lFQRYFEK20ab93KyOHReSJlLtoeQ Date: Fri, 28 Jun 2013 22:42:01 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6703429@CISEXCHANGE1.msisac.org.local> References: <20130628171814.28773.49527.idtracker@ietfa.amsl.com> <51CDE741.1070903@gmail.com> In-Reply-To: <51CDE741.1070903@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] UPDATED WG Review: Security Automation and Continuous Monitoring (sacm) 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, 28 Jun 2013 22:42:28 -0000 Yaron, you're right. =20 We're not securing information directly. =20 The sentence in question is setting the context for the purpose of the WG,= rather than describing what the WG will be doing, which is automating wha= t we can, so that systems can be configured correctly and kept up to date = in an effort to secure the information they handle. Adam > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Friday, June 28, 2013 1:24 PM > To: sacm WG > Subject: Re: [sacm] UPDATED WG Review: Security Automation and > Continuous Monitoring (sacm) >=20 > An annoying nit in the charter: I believe the first sentence is misleadi= ng. As > far as I understand, the WG is not about "securing information" in gener= al, > but rather about "securing security/posture information" or maybe "secur= ity > information". >=20 > Thanks, > =09Yaron >=20 > On 2013-06-28 20:18, The IESG wrote: > > A new IETF working group has been proposed in the Security Area. The > > IESG has not made any determination yet. The following draft charter > > was submitted, and is provided for informational purposes only. Please= > > send your comments to the IESG mailing list (iesg at ietf.org) by 2013= -07-08. > > > > Security Automation and Continuous Monitoring (sacm) > > ------------------------------------------------ > > Current Status: Proposed WG > > > > Chairs: > > Dan Romascanu > > Adam Montville > > > > Assigned Area Director: > > Sean Turner > > > > Mailing list > > Address: sacm@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/sacm > > Archive: http://www.ietf.org/mail-archive/web/sacm/ > > > > Charter: > > > > Securing information and the systems that store, process, and transmit= > > that information is a challenging task for organizations of all sizes,= > > and many security practitioners spend much of their time on manual > > processes. Standardized protocols to collect, verify, and update > > system security configurations would allow this process to be > > automated, which would free security practitioners to focus on high > > priority tasks and should improve their ability to prioritize risk > > based on timely information about threats and vulnerabilities. > > Because this is a broad area of work, this working group will first > > address enterprise use cases pertaining to the assessment of endpoint > > posture (using the definitions of Endpoint and Posture from RFC 5209).= > > > > The working group will, whenever reasonable and possible, reuse > > existing protocols, mechanisms, information and data models. Of > > particular interest to this working group are existing industry > > standards, preferably IETF standards, that could support automation of= > > asset, change, configuration, and vulnerability management. > > > > The working group will define: > > > > 1. A set of standards to enable assessment of endpoint posture. This > > area of focus provides for necessary language and data format > specifications. > > > > An example of such an endpoint posture assessment could include, > > but is not limited to, the following general steps: > > > > 1. Identify endpoints > > > > 2. Determine specific endpoint elements to assess > > > > 3. Collect actual value of elements > > > > 4. Compare actual element values to expected element values > > > > 5. Report results > > > > This approach to endpoint posture collection enables multiple polic= ies > > to be evaluated based on a single data collection activity. Policie= s > > will be evaluated by comparing available endpoint posture data > > according to rules expressed in the policy. Typically, these rules > > will compare the actual value against an expected value or range fo= r > > specific posture elements. In some cases, the posture element may > > pertain to software installation state, in which case the actual an= d > > expected values may be "installed" or "not installed." Evaluation o= f > > multiple posture elements may be combined using Boolean logic. > > > > 2. A set of standards for interacting with repositories of content > > related to assessment of endpoint posture. > > > > Repository protocols are needed to store, update, and retrieve > > configuration checks and other types of content required for postur= e > > assessment (see step 2 above). A content repository is expected to > > house specific versions of checklists (i.e. benchmarks), may be > > required to satisfy different use cases (i.e. asset inventory, > > configuration settings, or vulnerabilities). In addition, content > > repositories are expected to store up-to-date dictionary of specifi= c > > enumerations, such as those used for configuration element > > identifiers, asset classifications, vulnerability identifiers, and = so > > on. > > > > This working group will produce the following deliverables: > > > > - A document or documents describing the SACM Architecture. This will > > include protocol requirements=20and their associated use cases as well= > > as a description of how SACM protocols fit together into a system. > > This may be a single standards-track document, or may be split up as t= he > WG sees fit. > > - A standards-track document specifying the informational model for > > endpoints data posture. > > - A standards-track document specifying a protocol and data format for= > > retrieving configuration and policy information for driving data > > collection and analysis > > - A standards-track document specifying a protocol and data format for= > > collecting actual endpoint posture > > > > The working group will create an Internet-Draft documenting the > > existing work in the IETF and in other organizations that might be > > used as-is or as a starting point for developing solutions to the SACM= > requirements. > > The working group may decide to make of this document an Informational= > > RFC, but this is not a mandatory deliverable. > > > > The working group will work in close coordination with other WGs in > > the IETF (including, but not limited to MILE and NEA) in order to > > create solutions that do not overlap and can be used or re-used to > > meet the goals of more than one working group. > > > > The working group will communicate with non-IETF organizations working= > > on related specifications and will encourage industry participation in= > > the development of the WG's documents. Other organizations involved > > in the sacm space include ISO/IEC and TCG, as well as government > > agencies such as NIST. > > > > SACM-related efforts are largely aligned, and may overlap, with other > > IETF (and non-IETF) standardization efforts. There are common "problem= s" > > found in SACM, that may be addressed by the work done in SNMP, IPFIX, > > NETCONF, SYSLOG, NEA, MILE, and potentially others. Of particular > > interest to SACM is understanding and respecting the distinctions > > between itself and NEA and MILE. > > > > One way the NEA protocols can be used is as the transport for data > > collected on the endpoint to an external service or data repository > > for further analysis and action. NEA may also serve the purpose of > > carrying data-collection instructions. > > > > The MILE data formats provide a format to describe incident, > > threat-related incident, and indicator information. SACM data formats > > provide ways to understand what endpoints are in your environment, > > whether they meet policy requirements, and their current configuration= > > state. The data exchanged in MILE, supplementing the SACM data, > > creates enhanced situational awareness, thus enabling increased > > understanding of current threats and mitigations. The combined SACM > > and MILE data sets become a powerful tool to automate security with > > descriptions of endpoints, known vulnerabilities to those endpoints, > > and their configurations along with an understanding of layered defens= es. > > Transports from MILE may be used by SACM. > > > > This charter will expire in Month Year (36 months from approval). If > > the charter is not updated before that time, the WG will be closed and= > > any remaining documents revert back to individual Internet-Drafts. > > > > Milestones: > > Oct 2013 - Initial submission of SACM Architecture Internet-Draft > > Nov 2013 - Initial submission of SACM Information Model Internet-Dr= aft > > Jan 2014 - Initial submission of protocol and data format for > > retrieving configuration and policy information for driving data > > collection and analysis Internet-Draft > > Jan 2014 - Initial submission of protocol and data format for > > collecting endpoint posture Internet-Draft > > May 2014 - Submit SACM Architecture Internet-Draft to the IESG for > > consideration as Informational RFC > > Sep 2014 - Submit protocol and data format for retrieving > > configuration and policy information for driving data collection and > > analysis Internet-Draft to the IESG for consideration as Proposed Stan= dard > > Sep 2014 - Submit protocol and data format for collecting endpoint > > posture Internet-Draft to the IESG for consideration as Proposed > > Standard > > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... 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.

Hi,

I have been following this convers= ation from the sidelines.  I do not mind a document that makes ref= erence to existing work as an initial step, but my hope is that the IET= F will eventually take full ownership of whatever it is that SACM cover= s, in the event that it forms as a working group.

Eric


3D"InactiveAdam Montville ---06/27/2013 08:34:32 AM---This seems to be = the real issue.  We could wait and break it out later (I assume &q= uot;it" is the data mo

From: Adam Montville <Adam.Montville@cis= ecurity.org>
To: "Kent_Landfield@McAfee.com" &= lt;Kent_Landfield@McAfee.com>, "dromasca@avaya.com" <dr= omasca@avaya.com>, "kathleen.moriarty@emc.com" <kathlee= n.moriarty@emc.com>, "turners@ieca.com" <turners@ieca.c= om>
Cc: "sacm@ietf.org" <sacm@ietf= .org>
Date: 06/27/2013 08:34 AM
Subject: = Re: [sacm] Fwd: Benoit Claise's Bl= ock on charter-ietf-sacm-00-06: (with BLOCK and COMMENT)
Sent by: = sacm-bounces@ietf.org