From turners@ieca.com Thu May 2 08:23: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 5995321F8F41 for ; Thu, 2 May 2013 08:23:24 -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 NWquhJXicUVC for ; Thu, 2 May 2013 08:23:19 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.71.3]) by ietfa.amsl.com (Postfix) with ESMTP id 27BB421F8F29 for ; Thu, 2 May 2013 08:23:19 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id B9F12E2391888; Thu, 2 May 2013 10:23:18 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id A461AE2391862 for ; Thu, 2 May 2013 10:23:18 -0500 (CDT) Received: from [96.231.222.90] (port=49989 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXvLq-0000ko-FW for sacm@ietf.org; Thu, 02 May 2013 10:23:18 -0500 Message-ID: <518284E5.1040608@ieca.com> Date: Thu, 02 May 2013 11:23:17 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 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) [96.231.222.90]:49989 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] drafts you might care about X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 02 May 2013 15:23:27 -0000 Two drafts are up for IESG evaluation on the 16th of April. These two drafts should be of interest to those on this list: https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ YANG is used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) and these two drafts define data models for network interface management and ip management. If you think there's something that's missing please post to the ietf@ietf.org list or send them to me. My concern here is that sacm will want to manage something related to interfaces or ip that's just not going to be made available by a client or server. spt From turners@ieca.com Thu May 2 10:04: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 3554521F8952 for ; Thu, 2 May 2013 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 e18TY5vZxoIK for ; Thu, 2 May 2013 10:04:09 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.66.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACBE21F868B for ; Thu, 2 May 2013 10:04:07 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id D66B311C5A600; Thu, 2 May 2013 12:04:01 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id C8E0511C5A5AE for ; Thu, 2 May 2013 12:04:01 -0500 (CDT) Received: from [96.231.222.90] (port=50707 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXwvO-00068v-PS for sacm@ietf.org; Thu, 02 May 2013 12:04:07 -0500 Message-ID: <51829C86.7010407@ieca.com> Date: Thu, 02 May 2013 13:04:06 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "sacm@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@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) [96.231.222.90]:50707 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 02 May 2013 17:04:15 -0000 On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: > > Hi Sean, > > Following the second BOF in Orlando and your instructions, we have reached consensus on the mailing list on requesting the formation of a SACM Working Group, as well as on the proposed text for the future Working Group charter as listed below. Please forward this to the IESG for approval and let us know what are the next steps. > > Thanks and Regards, > > Kathleen and Dan Apologies for taking so long to get back to everyone on this. I've been trying to piece together my thoughts on this charter coupled with a lot of input I've gathered or that was unsolicited. These are for background so no need to reply to these. I think these can all be addressed by charter text: 1. The comment I've received most often when discussing this charter is "what are they going to do that's not already being done in nea or mile." We need to make that clear. I'm sure we'll get dinged by somebody about mentioning other WGs in the charter because they might close/etc but I think explicitly explaining how the work done elsewhere in the IETF relates to this possible work is warranted in this case because I've been asked about this so many times. I think it can be said that sacm is about using mile, nea, and likely other to do more and we should say that somewhere. 2. 2nd most asked question "what exactly are they going to do?" This, I think, is easily addressed by including more about what exactly is entailed in "enabling endpoint assessment." 3. The next I've been struggling with. The 2nd paragraph about reusing existing "stuff" and the paragraph about doing a survey to determine which "stuff" could meet our needs are intertwined. I think the phrase "whenever possible" might address my concern about adopting other's work because the WG can't just take "stuff" developed elsewhere; those that developed the "thing" may need give it to us to adopt. Because as everybody should be well aware of: nothing you submit to an SDO will emerge unchanged when it gets published by the SDO. 4. This is a rubberstamping exercise. We're going to work from requirements, then folks will champion solutions, and then the wg will pick from those solutions. Now on to the charter itself. I split it up into sections. Sections start with and end with . "spt:" is before points I'd like to make. spt: chairs, ADs, mailing list looks fine so I took it out for brevity. spt: BTW - I've recruited more than a few possible chairs. If you're interested in becoming a WG chair, the first step is to ask. Note: if you're planning on authoring some of the drafts, you might be out of the running because we normally try to avoid author/chair conflicts as much as possible. 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 (wg) will define security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners 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 wg is to address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). spt: I think the intro is good, what I'd like to see next is some text about what "assesment of endpoint posture" entails but that'll go in the section. Few folks are going to take the time to read all the documents and putting it in the charter will end this line of questioning. This discussion continues in the section. The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management. spt: This needs to be merged with the last paragraph in the section. 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. spt: Instead of this numbered list I'd like as much text as it takes to explain what is entailed in the assessment of endpoint posture and why we need repository protocols. This is what people are going to want to know when reading this charter. I think this is the important part of the pact you're making with the IESG. What ought these next two paragraph say: Assessment of endpoint posture entails ... Repository protocols are needed to ... spt: Here's where I'd like some discussion about the NEA-based protocols and how they can and can't be used, whether they are "the" protocols and if not why not. NEA-based protocols provide ... but we're doing ... spt: I'd also like to give some lip service to the MILE-based protocols and how they'll fit in. Even if it's that's for a later stage I'd argue we need to include it now so that it's clear we're not trying to overlap. MILE-based/like protocols/formats provide ... and will fit in the overall SACM architecture ... spt: Is there anything we can say about the existing management protocols such as SNMP/NETCONF? spt: We'll have a motherhood and apple pie statement later about reuse so no need to put it in this section. sacm will achieve the following deliverables: - An Informational document on Use Cases - An Informational document on Requirements spt: Are the use cases and deliverables about sacm or just the endpoint assessment bit? - An Informational document on SACM Architecture spt: The architecture document is where you can go nuts and explain the grand vision. - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis spt: Yeah so the above bullet needs to be introduced in the section. spt: Are you sure the data format and protocol will be in one draft? spt: Is it really "a protocol" or is it "protocols"? - A standards-track document specifying a protocol and data format for collecting actual endpoint posture spt: strike "actual" spt: Is it really "a protocol" or is it "protocols"? Is it nea? spt: Are you sure the data format and protocol will be in one draft? 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. spt: Funny I would have liked to have had this survey draft long ago ;) spt: I'm trying to see how this optional deliverable relates to the requirements draft and the mandate to reuse whenever protocols possible. What I've seen happen: WG documents requirements, solutions are documented (disclose IPR step here), authors of those solutions make their case to the WG as to why their solution is the best, wg then decides which to choose. spt: I don't want to limit this to SDO-developed work. First I don't want to get in to defining an SDO and second there might exist a non-SDO that has done great work and that is willing to further develop their work in the IETF. spt: Normally, I'd not impose this restriction but based on the number of "rubberstamp" questions I think the requirements draft is pretty darn important; seems like it needs to be done first or shortly after the use cases and architecture. I made that point in the provided text and moved the milestones around. spt: This is slightly tweaking the two paragraphs you had: There already exist protocols and data formats (i.e., solutions) at various levels of maturity and industry adoption that might be embraced to solve aspects of the SACM charter beyond those NEA-based protocols and MILE-based protocols/formats. To assist the wg when its comparing possible solutions against the wg-defined requirements, a draft will be produced that documents sacm-related IETF-developed (e.g., NEA and MILE) and non-IETF-developed solutions. This draft may or may not progress out of the wg but it will complete and the wg will progress the use cases, requirements and architecture drafts to the IESG prior to shifting its focus to protocol work. 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. I know we discussed wgs previously, but here I think we can leave them out: Close coordination with other WGs in the IETF is needed to avoid duplicative and overlapping solutions (e.g., management and repository protocols). spt: Hopefully with the earlier additions to the section this paragraph won't come so quite out of the blue. 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. spt: IAB alert! What regulatory organizations are we talking about here? You don't have to burn this list in the charter, but you'd better give me a preliminary list so that I can pre-grease the IAB's wheels on this issue. After the work items in the current charter have been submitted to and approved by the IESG, the WG will recharter or close. spt: Because I don't want this to go on forever, I'd like to do something a little more radical: let's put a 2 year limit on the charter. The milestones seem to think we'll be done by then so let's burn it in the charter: After the work items in the current charter have been submitted to and approved by the IESG or after two years from the date of approval of this charter, the WG will recharter or close. spt: some minor tweaks: Goals and Milestones Sep 2013 - Adopt Use Case draft (informational) Oct 2013 - Adopt Requirements draft (informational) Oct 2013 - Adopt SACM Architecture draft (informational) Nov 2013 - Adopt overview of sacm-related work draft (informational) spt: To line up with the earlier comment I want at least want a WGLC of the use cases, requirements, and architecture to do out before protocol data formats. Apr 2014 - Submit Use Cases for consideration as Informational RFC Apr 2014 - Submit Requirements for consideration as Informational RFC Apr 2014 - Submit SACM Architecture for consideration as Informational RFC May 2014 - Adopt protocol and data format draft for retrieving configuration and policy information for driving data collection and analysis (standards track) May 2014 - Adopt a protocol and data format for collecting endpoint posture Oct 2014 - Submit 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 - Submit a protocol and data format for collecting actual endpoint posture for consideration as standards-track RFC spt From shanna@juniper.net Thu May 2 10:25: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 6238E21F85EE for ; Thu, 2 May 2013 10:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 M4+WM5fp3+W7 for ; Thu, 2 May 2013 10:25:05 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3897421F8FB3 for ; Thu, 2 May 2013 10:25:05 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUYKhcBDprWfyqPyv9EamQI7i4+VJFeA5@postini.com; Thu, 02 May 2013 10:25:05 PDT 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; Thu, 2 May 2013 10:21:57 -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; Thu, 2 May 2013 10:21:56 -0700 Received: from DB8EHSOBE028.bigfish.com (213.199.154.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 May 2013 10:32:44 -0700 Received: from mail198-db8-R.bigfish.com (10.174.8.231) by DB8EHSOBE028.bigfish.com (10.174.4.91) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 May 2013 17:21:53 +0000 Received: from mail198-db8 (localhost [127.0.0.1]) by mail198-db8-R.bigfish.com (Postfix) with ESMTP id 349C0A40515 for ; Thu, 2 May 2013 17:21:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI98dI9371IfecI9feI542I1432I4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275dh1033ILz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail198-db8 (localhost.localdomain [127.0.0.1]) by mail198-db8 (MessageSwitch) id 136751531152909_18247; Thu, 2 May 2013 17:21:51 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.246]) by mail198-db8.bigfish.com (Postfix) with ESMTP id 0A0CB50004D; Thu, 2 May 2013 17:21:51 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 May 2013 17:21:48 +0000 Received: from CH1PRD0510MB369.namprd05.prod.outlook.com ([169.254.10.8]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0305.001; Thu, 2 May 2013 17:21:45 +0000 From: Stephen Hanna To: Sean Turner Thread-Topic: [sacm] Proposed text for the SACM WG charter Thread-Index: Ac40XoQq+XliguO6Trm+y2ynAw9zFAS+ImoAAAA8j/A= Date: Thu, 2 May 2013 17:21:45 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> In-Reply-To: <51829C86.7010407@ieca.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%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 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 02 May 2013 17:25:11 -0000 Sean, Thanks for your helpful comments. One quick question. You wrote: > 4. This is a rubberstamping exercise. We're going to work from > requirements, then folks will champion solutions, and then the wg > will pick from those solutions. Did you mean that this SHOULD NOT be a rubberstamping exercise or it SHOULD be one? Please clarify. Given the preceding sentences, which explain that "nothing you submit to an SDO will emerge unchanged when it gets published by the SDO", I assume that you mean SACM SHOULD NOT be a rubberstamping exercise and the charter SHOULD say so. I agree with that view. I have a bunch of other questions or comments related to your other comments below but I figured I'd get this quick question answered first. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Thursday, May 02, 2013 1:04 PM > To: sacm@ietf.org > Subject: Re: [sacm] Proposed text for the SACM WG charter >=20 > On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: > > > > Hi Sean, > > > > Following the second BOF in Orlando and your instructions, we have > reached consensus on the mailing list on requesting the formation of a > SACM Working Group, as well as on the proposed text for the future > Working Group charter as listed below. Please forward this to the IESG > for approval and let us know what are the next steps. > > > > Thanks and Regards, > > > > Kathleen and Dan >=20 > Apologies for taking so long to get back to everyone on this. > I've been trying to piece together my thoughts on this charter > coupled with a lot of input I've gathered or that was > unsolicited. >=20 > >=20 > These are for background so no need to reply to these. I think > these can all be addressed by charter text: >=20 > 1. The comment I've received most often when discussing this > charter is "what are they going to do that's not already being > done in nea or mile." We need to make that clear. I'm sure > we'll get dinged by somebody about mentioning other WGs in the > charter because they might close/etc but I think explicitly > explaining how the work done elsewhere in the IETF relates to > this possible work is warranted in this case because I've been > asked about this so many times. I think it can be said that sacm > is about using mile, nea, and likely other to do more and we > should say that somewhere. >=20 > 2. 2nd most asked question "what exactly are they going to do?" > This, I think, is easily addressed by including more about what > exactly is entailed in "enabling endpoint assessment." >=20 > 3. The next I've been struggling with. The 2nd paragraph about > reusing existing "stuff" and the paragraph about doing a survey > to determine which "stuff" could meet our needs are intertwined. > I think the phrase "whenever possible" might address my concern > about adopting other's work because the WG can't just > take "stuff" developed elsewhere; those that developed the > "thing" may need give it to us to adopt. Because as everybody > should be well aware of: nothing you submit to an SDO will emerge > unchanged when it gets published by the SDO. >=20 > 4. This is a rubberstamping exercise. We're going to work from > requirements, then folks will champion solutions, and then the wg > will pick from those solutions. >=20 > >=20 > Now on to the charter itself. I split it up into sections. > Sections start with and end with . > "spt:" is before points I'd like to make. >=20 > >=20 > >=20 > spt: chairs, ADs, mailing list looks fine so I took it out for > brevity. >=20 > spt: BTW - I've recruited more than a few possible chairs. > If you're interested in becoming a WG chair, the first step is to > ask. Note: if you're planning on authoring some of the drafts, > you might be out of the running because we normally try to avoid > author/chair conflicts as much as possible. >=20 > >=20 > of work we're going to do, c) what we're not going to do, > d) deliverables, and e) misc> >=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 (wg) will define security automation protocols and data > format standards in support of information security processes > and practices. These standards will help security practitioners > 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 wg is to address enterprise > use cases pertaining to the assessment of endpoint posture > (using the definitions of Endpoint and Posture from RFC 5209). >=20 > spt: I think the intro is good, what I'd like to see next is some > text about what "assesment of endpoint posture" entails but > that'll go in the section. > Few folks are going to take the time to read all the documents > and putting it in the charter will end this line of questioning. > This discussion continues in the do> section. >=20 > >=20 > >=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 the security > automation specifications supporting asset, change, > configuration, and vulnerability management. >=20 > spt: This needs to be merged with the last paragraph in the > section. >=20 > >=20 > >=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 > spt: Instead of this numbered list I'd like as much text as it > takes to explain what is entailed in the assessment of endpoint > posture and why we need repository protocols. This is what > people are going to want to know when reading this charter. I > think this is the important part of the pact you're making with > the IESG. What ought these next two paragraph say: >=20 > Assessment of endpoint posture entails ... >=20 > Repository protocols are needed to ... >=20 > >=20 > >=20 > spt: Here's where I'd like some discussion about the NEA-based > protocols and how they can and can't be used, whether they are > "the" protocols and if not why not. >=20 > NEA-based protocols provide ... but we're doing ... >=20 > spt: I'd also like to give some lip service to the MILE-based > protocols and how they'll fit in. Even if it's that's for a > later stage I'd argue we need to include it now so that it's > clear we're not trying to overlap. >=20 > MILE-based/like protocols/formats provide ... and will fit in > the overall SACM architecture ... >=20 > spt: Is there anything we can say about the existing management > protocols such as SNMP/NETCONF? >=20 > spt: We'll have a motherhood and apple pie statement later about > reuse so no need to put it in this section. >=20 > >=20 > >=20 > sacm will achieve the following deliverables: >=20 > - An Informational document on Use Cases >=20 > - An Informational document on Requirements >=20 > spt: Are the use cases and deliverables about sacm or just the > endpoint assessment bit? >=20 > - An Informational document on SACM Architecture >=20 > spt: The architecture document is where you can go nuts and > explain the grand vision. >=20 > - A standards-track document specifying a protocol and data > format for retrieving configuration and policy information for > driving data collection and analysis >=20 > spt: Yeah so the above bullet needs to be introduced in the > section. >=20 > spt: Are you sure the data format and protocol will be in one > draft? >=20 > spt: Is it really "a protocol" or is it "protocols"? >=20 > - A standards-track document specifying a protocol and data > format for collecting actual endpoint posture >=20 > spt: strike "actual" >=20 > spt: Is it really "a protocol" or is it "protocols"? Is it nea? >=20 > spt: Are you sure the data format and protocol will be in one > draft? >=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 > spt: Funny I would have liked to have had this survey draft long > ago ;) >=20 > spt: I'm trying to see how this optional deliverable relates to > the requirements draft and the mandate to reuse whenever > protocols possible. What I've seen happen: WG documents > requirements, solutions are documented (disclose IPR step here), > authors of those solutions make their case to the WG as to why > their solution is the best, wg then decides which to choose. >=20 > spt: I don't want to limit this to SDO-developed work. First I > don't want to get in to defining an SDO and second there might > exist a non-SDO that has done great work and that is willing to > further develop their work in the IETF. >=20 > spt: Normally, I'd not impose this restriction but based on the > number of "rubberstamp" questions I think the requirements draft > is pretty darn important; seems like it needs to be done first or > shortly after the use cases and architecture. I made that point > in the provided text and moved the milestones around. >=20 > spt: This is slightly tweaking the two paragraphs you had: >=20 > There already exist protocols and data formats (i.e., > solutions) at various levels of maturity and industry adoption > that might be embraced to solve aspects of the SACM charter > beyond those NEA-based protocols and MILE-based > protocols/formats. To assist the wg when its comparing > possible solutions against the wg-defined requirements, a draft > will be produced that documents sacm-related IETF-developed > (e.g., NEA and MILE) and non-IETF-developed solutions. This > draft may or may not progress out of the wg but it will > complete and the wg will progress the use cases, requirements > and architecture drafts to the IESG prior to shifting its focus > to protocol work. >=20 > >=20 > >=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 > I know we discussed wgs previously, but here I think we can leave > them out: >=20 > Close coordination with other WGs in the IETF is needed to > avoid duplicative and overlapping solutions (e.g., management > and repository protocols). >=20 > spt: Hopefully with the earlier additions to the going to do> section this paragraph won't come so quite out of > the blue. >=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 > spt: IAB alert! What regulatory organizations are we talking > about here? You don't have to burn this list in the charter, but > you'd better give me a preliminary list so that I can pre-grease > the IAB's wheels on this issue. >=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 > spt: Because I don't want this to go on forever, I'd like to do > something a little more radical: let's put a 2 year limit on the > charter. The milestones seem to think we'll be done by then so > let's burn it in the charter: >=20 > After the work items in the current charter have been submitted > to and approved by the IESG or after two years from the date of > approval of this charter, the WG will recharter or close. >=20 > >=20 > >=20 > >=20 > spt: some minor tweaks: >=20 > Goals and Milestones >=20 > Sep 2013 - Adopt Use Case draft (informational) >=20 > Oct 2013 - Adopt Requirements draft (informational) >=20 > Oct 2013 - Adopt SACM Architecture draft (informational) >=20 > Nov 2013 - Adopt overview of sacm-related work draft > (informational) >=20 > spt: To line up with the earlier comment I want at least want a > WGLC of the use cases, requirements, and architecture to do out > before protocol data formats. >=20 > Apr 2014 - Submit Use Cases for consideration as Informational > RFC >=20 > Apr 2014 - Submit Requirements for consideration as > Informational RFC >=20 > Apr 2014 - Submit SACM Architecture for consideration as > Informational RFC >=20 > May 2014 - Adopt protocol and data format draft for retrieving > configuration and policy information for driving data > collection and analysis (standards track) >=20 > May 2014 - Adopt a protocol and data format for collecting > endpoint posture >=20 > Oct 2014 - Submit 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 - Submit a protocol and data format for collecting > actual endpoint posture for consideration as standards-track > RFC >=20 > >=20 > >=20 > spt > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From turners@ieca.com Thu May 2 10:48: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 5503121F91BB for ; Thu, 2 May 2013 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.893 X-Spam-Level: X-Spam-Status: No, score=-101.893 tagged_above=-999 required=5 tests=[AWL=0.372, 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 y07Xlhg1knao for ; Thu, 2 May 2013 10:48:38 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.66.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB0A21F91A3 for ; Thu, 2 May 2013 10:48:38 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 84ACE11E1B9AC; Thu, 2 May 2013 12:48:32 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id A891811E1B603 for ; Thu, 2 May 2013 12:48:31 -0500 (CDT) Received: from [96.231.222.90] (port=50810 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXxcS-0000Kq-IO; Thu, 02 May 2013 12:48:36 -0500 Message-ID: <5182A6F3.5040808@ieca.com> Date: Thu, 02 May 2013 13:48:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Stephen Hanna References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.222.90]:50810 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 02 May 2013 17:48:43 -0000 On 5/2/13 1:21 PM, Stephen Hanna wrote: > Sean, > > Thanks for your helpful comments. One quick question. > > You wrote: >> 4. This is a rubberstamping exercise. We're going to work from >> requirements, then folks will champion solutions, and then the wg >> will pick from those solutions. > > Did you mean that this SHOULD NOT be a rubberstamping > exercise or it SHOULD be one? Please clarify. Some people think it is going to be one. It SHOULD NOT be one and I think forcing the requirements to get done first SHOULD make others feel more comfortable that it won't be. spt > Given the preceding sentences, which explain that > "nothing you submit to an SDO will emerge unchanged > when it gets published by the SDO", I assume that > you mean SACM SHOULD NOT be a rubberstamping exercise > and the charter SHOULD say so. I agree with that view. > > I have a bunch of other questions or comments > related to your other comments below but I > figured I'd get this quick question answered > first. > > Thanks, > > Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Thursday, May 02, 2013 1:04 PM >> To: sacm@ietf.org >> Subject: Re: [sacm] Proposed text for the SACM WG charter >> >> On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: >>> >>> Hi Sean, >>> >>> Following the second BOF in Orlando and your instructions, we have >> reached consensus on the mailing list on requesting the formation of a >> SACM Working Group, as well as on the proposed text for the future >> Working Group charter as listed below. Please forward this to the IESG >> for approval and let us know what are the next steps. >>> >>> Thanks and Regards, >>> >>> Kathleen and Dan >> >> Apologies for taking so long to get back to everyone on this. >> I've been trying to piece together my thoughts on this charter >> coupled with a lot of input I've gathered or that was >> unsolicited. >> >> >> >> These are for background so no need to reply to these. I think >> these can all be addressed by charter text: >> >> 1. The comment I've received most often when discussing this >> charter is "what are they going to do that's not already being >> done in nea or mile." We need to make that clear. I'm sure >> we'll get dinged by somebody about mentioning other WGs in the >> charter because they might close/etc but I think explicitly >> explaining how the work done elsewhere in the IETF relates to >> this possible work is warranted in this case because I've been >> asked about this so many times. I think it can be said that sacm >> is about using mile, nea, and likely other to do more and we >> should say that somewhere. >> >> 2. 2nd most asked question "what exactly are they going to do?" >> This, I think, is easily addressed by including more about what >> exactly is entailed in "enabling endpoint assessment." >> >> 3. The next I've been struggling with. The 2nd paragraph about >> reusing existing "stuff" and the paragraph about doing a survey >> to determine which "stuff" could meet our needs are intertwined. >> I think the phrase "whenever possible" might address my concern >> about adopting other's work because the WG can't just >> take "stuff" developed elsewhere; those that developed the >> "thing" may need give it to us to adopt. Because as everybody >> should be well aware of: nothing you submit to an SDO will emerge >> unchanged when it gets published by the SDO. >> >> 4. This is a rubberstamping exercise. We're going to work from >> requirements, then folks will champion solutions, and then the wg >> will pick from those solutions. >> >> >> >> Now on to the charter itself. I split it up into sections. >> Sections start with and end with . >> "spt:" is before points I'd like to make. >> >> >> >> >> >> spt: chairs, ADs, mailing list looks fine so I took it out for >> brevity. >> >> spt: BTW - I've recruited more than a few possible chairs. >> If you're interested in becoming a WG chair, the first step is to >> ask. Note: if you're planning on authoring some of the drafts, >> you might be out of the running because we normally try to avoid >> author/chair conflicts as much as possible. >> >> >> >> > of work we're going to do, c) what we're not going to do, >> d) deliverables, and e) misc> >> >> >> >> 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 (wg) will define security automation protocols and data >> format standards in support of information security processes >> and practices. These standards will help security practitioners >> 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 wg is to address enterprise >> use cases pertaining to the assessment of endpoint posture >> (using the definitions of Endpoint and Posture from RFC 5209). >> >> spt: I think the intro is good, what I'd like to see next is some >> text about what "assesment of endpoint posture" entails but >> that'll go in the section. >> Few folks are going to take the time to read all the documents >> and putting it in the charter will end this line of questioning. >> This discussion continues in the > do> section. >> >> >> >> >> >> The working group will, whenever reasonable and possible, reuse >> existing protocols, mechanisms, information and data models. Of >> particular interest to this working group are the security >> automation specifications supporting asset, change, >> configuration, and vulnerability management. >> >> spt: This needs to be merged with the last paragraph in the >> section. >> >> >> >> >> >> 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. >> >> spt: Instead of this numbered list I'd like as much text as it >> takes to explain what is entailed in the assessment of endpoint >> posture and why we need repository protocols. This is what >> people are going to want to know when reading this charter. I >> think this is the important part of the pact you're making with >> the IESG. What ought these next two paragraph say: >> >> Assessment of endpoint posture entails ... >> >> Repository protocols are needed to ... >> >> >> >> >> >> spt: Here's where I'd like some discussion about the NEA-based >> protocols and how they can and can't be used, whether they are >> "the" protocols and if not why not. >> >> NEA-based protocols provide ... but we're doing ... >> >> spt: I'd also like to give some lip service to the MILE-based >> protocols and how they'll fit in. Even if it's that's for a >> later stage I'd argue we need to include it now so that it's >> clear we're not trying to overlap. >> >> MILE-based/like protocols/formats provide ... and will fit in >> the overall SACM architecture ... >> >> spt: Is there anything we can say about the existing management >> protocols such as SNMP/NETCONF? >> >> spt: We'll have a motherhood and apple pie statement later about >> reuse so no need to put it in this section. >> >> >> >> >> >> sacm will achieve the following deliverables: >> >> - An Informational document on Use Cases >> >> - An Informational document on Requirements >> >> spt: Are the use cases and deliverables about sacm or just the >> endpoint assessment bit? >> >> - An Informational document on SACM Architecture >> >> spt: The architecture document is where you can go nuts and >> explain the grand vision. >> >> - A standards-track document specifying a protocol and data >> format for retrieving configuration and policy information for >> driving data collection and analysis >> >> spt: Yeah so the above bullet needs to be introduced in the >> section. >> >> spt: Are you sure the data format and protocol will be in one >> draft? >> >> spt: Is it really "a protocol" or is it "protocols"? >> >> - A standards-track document specifying a protocol and data >> format for collecting actual endpoint posture >> >> spt: strike "actual" >> >> spt: Is it really "a protocol" or is it "protocols"? Is it nea? >> >> spt: Are you sure the data format and protocol will be in one >> draft? >> >> 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. >> >> spt: Funny I would have liked to have had this survey draft long >> ago ;) >> >> spt: I'm trying to see how this optional deliverable relates to >> the requirements draft and the mandate to reuse whenever >> protocols possible. What I've seen happen: WG documents >> requirements, solutions are documented (disclose IPR step here), >> authors of those solutions make their case to the WG as to why >> their solution is the best, wg then decides which to choose. >> >> spt: I don't want to limit this to SDO-developed work. First I >> don't want to get in to defining an SDO and second there might >> exist a non-SDO that has done great work and that is willing to >> further develop their work in the IETF. >> >> spt: Normally, I'd not impose this restriction but based on the >> number of "rubberstamp" questions I think the requirements draft >> is pretty darn important; seems like it needs to be done first or >> shortly after the use cases and architecture. I made that point >> in the provided text and moved the milestones around. >> >> spt: This is slightly tweaking the two paragraphs you had: >> >> There already exist protocols and data formats (i.e., >> solutions) at various levels of maturity and industry adoption >> that might be embraced to solve aspects of the SACM charter >> beyond those NEA-based protocols and MILE-based >> protocols/formats. To assist the wg when its comparing >> possible solutions against the wg-defined requirements, a draft >> will be produced that documents sacm-related IETF-developed >> (e.g., NEA and MILE) and non-IETF-developed solutions. This >> draft may or may not progress out of the wg but it will >> complete and the wg will progress the use cases, requirements >> and architecture drafts to the IESG prior to shifting its focus >> to protocol work. >> >> >> >> >> >> 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. >> >> I know we discussed wgs previously, but here I think we can leave >> them out: >> >> Close coordination with other WGs in the IETF is needed to >> avoid duplicative and overlapping solutions (e.g., management >> and repository protocols). >> >> spt: Hopefully with the earlier additions to the > going to do> section this paragraph won't come so quite out of >> the blue. >> >> 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. >> >> spt: IAB alert! What regulatory organizations are we talking >> about here? You don't have to burn this list in the charter, but >> you'd better give me a preliminary list so that I can pre-grease >> the IAB's wheels on this issue. >> >> After the work items in the current charter have been submitted >> to and approved by the IESG, the WG will recharter or close. >> >> spt: Because I don't want this to go on forever, I'd like to do >> something a little more radical: let's put a 2 year limit on the >> charter. The milestones seem to think we'll be done by then so >> let's burn it in the charter: >> >> After the work items in the current charter have been submitted >> to and approved by the IESG or after two years from the date of >> approval of this charter, the WG will recharter or close. >> >> >> >> >> >> >> >> spt: some minor tweaks: >> >> Goals and Milestones >> >> Sep 2013 - Adopt Use Case draft (informational) >> >> Oct 2013 - Adopt Requirements draft (informational) >> >> Oct 2013 - Adopt SACM Architecture draft (informational) >> >> Nov 2013 - Adopt overview of sacm-related work draft >> (informational) >> >> spt: To line up with the earlier comment I want at least want a >> WGLC of the use cases, requirements, and architecture to do out >> before protocol data formats. >> >> Apr 2014 - Submit Use Cases for consideration as Informational >> RFC >> >> Apr 2014 - Submit Requirements for consideration as >> Informational RFC >> >> Apr 2014 - Submit SACM Architecture for consideration as >> Informational RFC >> >> May 2014 - Adopt protocol and data format draft for retrieving >> configuration and policy information for driving data >> collection and analysis (standards track) >> >> May 2014 - Adopt a protocol and data format for collecting >> endpoint posture >> >> Oct 2014 - Submit 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 - Submit a protocol and data format for collecting >> actual endpoint posture for consideration as standards-track >> RFC >> >> >> >> >> >> spt >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > > From kathleen.moriarty@emc.com Thu May 2 13:34: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 C897F21F85ED for ; Thu, 2 May 2013 13:34:19 -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 vmYwTxfUAzFT for ; Thu, 2 May 2013 13:34: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 BCEE121F8712 for ; Thu, 2 May 2013 13:34:14 -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 r42KYAQ9031013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 May 2013 16:34:11 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 2 May 2013 16:33:50 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r42KXjL1031455; Thu, 2 May 2013 16:33:50 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Thu, 2 May 2013 16:33:48 -0400 From: "Moriarty, Kathleen" To: Sean Turner , Stephen Hanna Date: Thu, 2 May 2013 16:33:47 -0400 Thread-Topic: [sacm] Proposed text for the SACM WG charter Thread-Index: Ac5HXWQxFGG91FW/QY+kiL19p2JpJQAFsBnw Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> <5182A6F3.5040808@ieca.com> In-Reply-To: <5182A6F3.5040808@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: "Nancy Cam-Winget \(ncamwing\)" , "sacm@ietf.org" Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 02 May 2013 20:34:19 -0000 FYI - We did have at least one volunteer (graciously) confirm that she woul= d work on the requirements document and a second that is reaching out to Na= ncy Cam-Winget to assist. This should help. Thank you, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sea= n Turner Sent: Thursday, May 02, 2013 1:49 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: [sacm] Proposed text for the SACM WG charter On 5/2/13 1:21 PM, Stephen Hanna wrote: > Sean, > > Thanks for your helpful comments. One quick question. > > You wrote: >> 4. This is a rubberstamping exercise. We're going to work from >> requirements, then folks will champion solutions, and then the wg >> will pick from those solutions. > > Did you mean that this SHOULD NOT be a rubberstamping > exercise or it SHOULD be one? Please clarify. Some people think it is going to be one. It SHOULD NOT be one and I think forcing the requirements to get done first SHOULD make others feel more comfortable that it won't be. spt > Given the preceding sentences, which explain that > "nothing you submit to an SDO will emerge unchanged > when it gets published by the SDO", I assume that > you mean SACM SHOULD NOT be a rubberstamping exercise > and the charter SHOULD say so. I agree with that view. > > I have a bunch of other questions or comments > related to your other comments below but I > figured I'd get this quick question answered > first. > > Thanks, > > Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Thursday, May 02, 2013 1:04 PM >> To: sacm@ietf.org >> Subject: Re: [sacm] Proposed text for the SACM WG charter >> >> On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: >>> >>> Hi Sean, >>> >>> Following the second BOF in Orlando and your instructions, we have >> reached consensus on the mailing list on requesting the formation of a >> SACM Working Group, as well as on the proposed text for the future >> Working Group charter as listed below. Please forward this to the IESG >> for approval and let us know what are the next steps. >>> >>> Thanks and Regards, >>> >>> Kathleen and Dan >> >> Apologies for taking so long to get back to everyone on this. >> I've been trying to piece together my thoughts on this charter >> coupled with a lot of input I've gathered or that was >> unsolicited. >> >> >> >> These are for background so no need to reply to these. I think >> these can all be addressed by charter text: >> >> 1. The comment I've received most often when discussing this >> charter is "what are they going to do that's not already being >> done in nea or mile." We need to make that clear. I'm sure >> we'll get dinged by somebody about mentioning other WGs in the >> charter because they might close/etc but I think explicitly >> explaining how the work done elsewhere in the IETF relates to >> this possible work is warranted in this case because I've been >> asked about this so many times. I think it can be said that sacm >> is about using mile, nea, and likely other to do more and we >> should say that somewhere. >> >> 2. 2nd most asked question "what exactly are they going to do?" >> This, I think, is easily addressed by including more about what >> exactly is entailed in "enabling endpoint assessment." >> >> 3. The next I've been struggling with. The 2nd paragraph about >> reusing existing "stuff" and the paragraph about doing a survey >> to determine which "stuff" could meet our needs are intertwined. >> I think the phrase "whenever possible" might address my concern >> about adopting other's work because the WG can't just >> take "stuff" developed elsewhere; those that developed the >> "thing" may need give it to us to adopt. Because as everybody >> should be well aware of: nothing you submit to an SDO will emerge >> unchanged when it gets published by the SDO. >> >> 4. This is a rubberstamping exercise. We're going to work from >> requirements, then folks will champion solutions, and then the wg >> will pick from those solutions. >> >> >> >> Now on to the charter itself. I split it up into sections. >> Sections start with and end with . >> "spt:" is before points I'd like to make. >> >> >> >> >> >> spt: chairs, ADs, mailing list looks fine so I took it out for >> brevity. >> >> spt: BTW - I've recruited more than a few possible chairs. >> If you're interested in becoming a WG chair, the first step is to >> ask. Note: if you're planning on authoring some of the drafts, >> you might be out of the running because we normally try to avoid >> author/chair conflicts as much as possible. >> >> >> >> > of work we're going to do, c) what we're not going to do, >> d) deliverables, and e) misc> >> >> >> >> 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 (wg) will define security automation protocols and data >> format standards in support of information security processes >> and practices. These standards will help security practitioners >> 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 wg is to address enterprise >> use cases pertaining to the assessment of endpoint posture >> (using the definitions of Endpoint and Posture from RFC 5209). >> >> spt: I think the intro is good, what I'd like to see next is some >> text about what "assesment of endpoint posture" entails but >> that'll go in the section. >> Few folks are going to take the time to read all the documents >> and putting it in the charter will end this line of questioning. >> This discussion continues in the > do> section. >> >> >> >> >> >> The working group will, whenever reasonable and possible, reuse >> existing protocols, mechanisms, information and data models. Of >> particular interest to this working group are the security >> automation specifications supporting asset, change, >> configuration, and vulnerability management. >> >> spt: This needs to be merged with the last paragraph in the >> section. >> >> >> >> >> >> 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. >> >> spt: Instead of this numbered list I'd like as much text as it >> takes to explain what is entailed in the assessment of endpoint >> posture and why we need repository protocols. This is what >> people are going to want to know when reading this charter. I >> think this is the important part of the pact you're making with >> the IESG. What ought these next two paragraph say: >> >> Assessment of endpoint posture entails ... >> >> Repository protocols are needed to ... >> >> >> >> >> >> spt: Here's where I'd like some discussion about the NEA-based >> protocols and how they can and can't be used, whether they are >> "the" protocols and if not why not. >> >> NEA-based protocols provide ... but we're doing ... >> >> spt: I'd also like to give some lip service to the MILE-based >> protocols and how they'll fit in. Even if it's that's for a >> later stage I'd argue we need to include it now so that it's >> clear we're not trying to overlap. >> >> MILE-based/like protocols/formats provide ... and will fit in >> the overall SACM architecture ... >> >> spt: Is there anything we can say about the existing management >> protocols such as SNMP/NETCONF? >> >> spt: We'll have a motherhood and apple pie statement later about >> reuse so no need to put it in this section. >> >> >> >> >> >> sacm will achieve the following deliverables: >> >> - An Informational document on Use Cases >> >> - An Informational document on Requirements >> >> spt: Are the use cases and deliverables about sacm or just the >> endpoint assessment bit? >> >> - An Informational document on SACM Architecture >> >> spt: The architecture document is where you can go nuts and >> explain the grand vision. >> >> - A standards-track document specifying a protocol and data >> format for retrieving configuration and policy information for >> driving data collection and analysis >> >> spt: Yeah so the above bullet needs to be introduced in the >> section. >> >> spt: Are you sure the data format and protocol will be in one >> draft? >> >> spt: Is it really "a protocol" or is it "protocols"? >> >> - A standards-track document specifying a protocol and data >> format for collecting actual endpoint posture >> >> spt: strike "actual" >> >> spt: Is it really "a protocol" or is it "protocols"? Is it nea? >> >> spt: Are you sure the data format and protocol will be in one >> draft? >> >> 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. >> >> spt: Funny I would have liked to have had this survey draft long >> ago ;) >> >> spt: I'm trying to see how this optional deliverable relates to >> the requirements draft and the mandate to reuse whenever >> protocols possible. What I've seen happen: WG documents >> requirements, solutions are documented (disclose IPR step here), >> authors of those solutions make their case to the WG as to why >> their solution is the best, wg then decides which to choose. >> >> spt: I don't want to limit this to SDO-developed work. First I >> don't want to get in to defining an SDO and second there might >> exist a non-SDO that has done great work and that is willing to >> further develop their work in the IETF. >> >> spt: Normally, I'd not impose this restriction but based on the >> number of "rubberstamp" questions I think the requirements draft >> is pretty darn important; seems like it needs to be done first or >> shortly after the use cases and architecture. I made that point >> in the provided text and moved the milestones around. >> >> spt: This is slightly tweaking the two paragraphs you had: >> >> There already exist protocols and data formats (i.e., >> solutions) at various levels of maturity and industry adoption >> that might be embraced to solve aspects of the SACM charter >> beyond those NEA-based protocols and MILE-based >> protocols/formats. To assist the wg when its comparing >> possible solutions against the wg-defined requirements, a draft >> will be produced that documents sacm-related IETF-developed >> (e.g., NEA and MILE) and non-IETF-developed solutions. This >> draft may or may not progress out of the wg but it will >> complete and the wg will progress the use cases, requirements >> and architecture drafts to the IESG prior to shifting its focus >> to protocol work. >> >> >> >> >> >> 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. >> >> I know we discussed wgs previously, but here I think we can leave >> them out: >> >> Close coordination with other WGs in the IETF is needed to >> avoid duplicative and overlapping solutions (e.g., management >> and repository protocols). >> >> spt: Hopefully with the earlier additions to the > going to do> section this paragraph won't come so quite out of >> the blue. >> >> 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. >> >> spt: IAB alert! What regulatory organizations are we talking >> about here? You don't have to burn this list in the charter, but >> you'd better give me a preliminary list so that I can pre-grease >> the IAB's wheels on this issue. >> >> After the work items in the current charter have been submitted >> to and approved by the IESG, the WG will recharter or close. >> >> spt: Because I don't want this to go on forever, I'd like to do >> something a little more radical: let's put a 2 year limit on the >> charter. The milestones seem to think we'll be done by then so >> let's burn it in the charter: >> >> After the work items in the current charter have been submitted >> to and approved by the IESG or after two years from the date of >> approval of this charter, the WG will recharter or close. >> >> >> >> >> >> >> >> spt: some minor tweaks: >> >> Goals and Milestones >> >> Sep 2013 - Adopt Use Case draft (informational) >> >> Oct 2013 - Adopt Requirements draft (informational) >> >> Oct 2013 - Adopt SACM Architecture draft (informational) >> >> Nov 2013 - Adopt overview of sacm-related work draft >> (informational) >> >> spt: To line up with the earlier comment I want at least want a >> WGLC of the use cases, requirements, and architecture to do out >> before protocol data formats. >> >> Apr 2014 - Submit Use Cases for consideration as Informational >> RFC >> >> Apr 2014 - Submit Requirements for consideration as >> Informational RFC >> >> Apr 2014 - Submit SACM Architecture for consideration as >> Informational RFC >> >> May 2014 - Adopt protocol and data format draft for retrieving >> configuration and policy information for driving data >> collection and analysis (standards track) >> >> May 2014 - Adopt a protocol and data format for collecting >> endpoint posture >> >> Oct 2014 - Submit 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 - Submit a protocol and data format for collecting >> actual endpoint posture for consideration as standards-track >> RFC >> >> >> >> >> >> 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 From ietfdbh@comcast.net Thu May 2 15:40: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 1B0C121F85A4 for ; Thu, 2 May 2013 15:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Mros8QJmdAHp for ; Thu, 2 May 2013 15:40:42 -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 2BD7B21F8551 for ; Thu, 2 May 2013 15:40:42 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Wzod1l0010EZKEL5BAghKR; Thu, 02 May 2013 22:40:41 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta01.westchester.pa.mail.comcast.net with comcast id XAgh1l00C2yZEBF3MAghX0; Thu, 02 May 2013 22:40:41 +0000 From: "ietfdbh" To: "'Sean Turner'" , "'Stephen Hanna'" References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> <5182A6F3.5040808@ieca.com> In-Reply-To: <5182A6F3.5040808@ieca.com> Date: Thu, 2 May 2013 18:40:42 -0400 Message-ID: <03e501ce4786$1417fff0$3c47ffd0$@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: AQHCAA9DOqX0z1AQiolgaTyJBGGUcwERz5jxAec6MYACIEP2+JjiPB8g Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367534441; bh=h9VBHTLNqGFmgXTfXaLYuGq4g2lhhIUATEtvH+vPL1A=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=XaVx89L+1hE1if2aJXDxxX/1n4lB2Hwgl3pjC73H+bSTxdSEF9dtgRK9K9h/kEPNF 1mfBikkGWnLcXWy2qY03wR9qdLZYBUTKqTf1Uyx/O0fm5eUbCA/I1I2541HENqVgz+ 5+EhVJ5mO5S7lwkWGo5juwYk/rfFNl9MtSDPbgcI7Ixhb1ntK0u3/ziCKqvPnRokgs oBAGVaOr3887uH4kBtoEzEz3SPi2pM6oQTGjZovCCbJJSIekS+rjLIR7aFVUGtOM4Y 5mMOM971iBc4Cbw5hKWuuqO/9nEjCIE7ZbHJGaoXZIP1DZXstywjdEUOs39L6RZ4tz Y1EVEv1Mecd4A== Cc: sacm@ietf.org Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 02 May 2013 22:40:47 -0000 Hi, I think it makes sense to consider requirements first. However, I think you need to be careful that the requirements don't imply a particular solution. It is common practice to write RFP specs to favor a particular vendor's solution, and eliminating all others. Requirements can lead to a rubber-stamping approach. Requirements for a greenfield solution might differ from requirements that permit use of existing technologies. I would hate to see SACM "require" a new protocol be designed for their "special case" requirements. (I've seen this a few times in twenty years of IETF work ;-) Often thinking about the problem a little differently can make existing technologies a viable solution. SNMPv3 invented their own security protocol because the protocol designers (incl. me) "required" no 3rd-party dependencies. And SNMPv3 designers "required" the ability to support multiple messaging models, security models, user-based access controls, and other options. But operators preferred SSH- and TLS-based solutions so they didn't have to maintain yet another security infrastructure. And there have been no other optional messaging models to date, and many of the other "required" features are never used. So we need to make sure the requirements are real and not unnecessary nice-to-haves. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sean Turner Sent: Thursday, May 02, 2013 1:49 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: [sacm] Proposed text for the SACM WG charter On 5/2/13 1:21 PM, Stephen Hanna wrote: > Sean, > > Thanks for your helpful comments. One quick question. > > You wrote: >> 4. This is a rubberstamping exercise. We're going to work from >> requirements, then folks will champion solutions, and then the wg >> will pick from those solutions. > > Did you mean that this SHOULD NOT be a rubberstamping exercise or it > SHOULD be one? Please clarify. Some people think it is going to be one. It SHOULD NOT be one and I think forcing the requirements to get done first SHOULD make others feel more comfortable that it won't be. spt > Given the preceding sentences, which explain that "nothing you submit > to an SDO will emerge unchanged when it gets published by the SDO", I > assume that you mean SACM SHOULD NOT be a rubberstamping exercise and > the charter SHOULD say so. I agree with that view. > > I have a bunch of other questions or comments related to your other > comments below but I figured I'd get this quick question answered > first. > > Thanks, > > Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of Sean Turner >> Sent: Thursday, May 02, 2013 1:04 PM >> To: sacm@ietf.org >> Subject: Re: [sacm] Proposed text for the SACM WG charter >> >> On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: >>> >>> Hi Sean, >>> >>> Following the second BOF in Orlando and your instructions, we have >> reached consensus on the mailing list on requesting the formation of >> a SACM Working Group, as well as on the proposed text for the future >> Working Group charter as listed below. Please forward this to the >> IESG for approval and let us know what are the next steps. >>> >>> Thanks and Regards, >>> >>> Kathleen and Dan >> >> Apologies for taking so long to get back to everyone on this. >> I've been trying to piece together my thoughts on this charter >> coupled with a lot of input I've gathered or that was unsolicited. >> >> >> >> These are for background so no need to reply to these. I think these >> can all be addressed by charter text: >> >> 1. The comment I've received most often when discussing this charter >> is "what are they going to do that's not already being done in nea or >> mile." We need to make that clear. I'm sure we'll get dinged by >> somebody about mentioning other WGs in the charter because they might >> close/etc but I think explicitly explaining how the work done >> elsewhere in the IETF relates to this possible work is warranted in >> this case because I've been asked about this so many times. I think >> it can be said that sacm is about using mile, nea, and likely other >> to do more and we should say that somewhere. >> >> 2. 2nd most asked question "what exactly are they going to do?" >> This, I think, is easily addressed by including more about what >> exactly is entailed in "enabling endpoint assessment." >> >> 3. The next I've been struggling with. The 2nd paragraph about >> reusing existing "stuff" and the paragraph about doing a survey to >> determine which "stuff" could meet our needs are intertwined. >> I think the phrase "whenever possible" might address my concern about >> adopting other's work because the WG can't just take "stuff" >> developed elsewhere; those that developed the "thing" may need give >> it to us to adopt. Because as everybody should be well aware of: >> nothing you submit to an SDO will emerge unchanged when it gets >> published by the SDO. >> >> 4. This is a rubberstamping exercise. We're going to work from >> requirements, then folks will champion solutions, and then the wg >> will pick from those solutions. >> >> >> >> Now on to the charter itself. I split it up into sections. >> Sections start with and end with . >> "spt:" is before points I'd like to make. >> >> >> >> >> >> spt: chairs, ADs, mailing list looks fine so I took it out for >> brevity. >> >> spt: BTW - I've recruited more than a few possible chairs. >> If you're interested in becoming a WG chair, the first step is to >> ask. Note: if you're planning on authoring some of the drafts, you >> might be out of the running because we normally try to avoid >> author/chair conflicts as much as possible. >> >> >> >> > going to do, c) what we're not going to do, >> d) deliverables, and e) misc> >> >> >> >> 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 (wg) will define security automation protocols and data >> format standards in support of information security processes >> and practices. These standards will help security practitioners >> 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 wg is to address enterprise >> use cases pertaining to the assessment of endpoint posture >> (using the definitions of Endpoint and Posture from RFC 5209). >> >> spt: I think the intro is good, what I'd like to see next is some >> text about what "assesment of endpoint posture" entails but that'll >> go in the section. >> Few folks are going to take the time to read all the documents and >> putting it in the charter will end this line of questioning. >> This discussion continues in the > do> section. >> >> >> >> >> >> The working group will, whenever reasonable and possible, reuse >> existing protocols, mechanisms, information and data models. Of >> particular interest to this working group are the security >> automation specifications supporting asset, change, >> configuration, and vulnerability management. >> >> spt: This needs to be merged with the last paragraph in the >> section. >> >> >> >> >> >> 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. >> >> spt: Instead of this numbered list I'd like as much text as it takes >> to explain what is entailed in the assessment of endpoint posture and >> why we need repository protocols. This is what people are going to >> want to know when reading this charter. I think this is the >> important part of the pact you're making with the IESG. What ought >> these next two paragraph say: >> >> Assessment of endpoint posture entails ... >> >> Repository protocols are needed to ... >> >> >> >> >> >> spt: Here's where I'd like some discussion about the NEA-based >> protocols and how they can and can't be used, whether they are "the" >> protocols and if not why not. >> >> NEA-based protocols provide ... but we're doing ... >> >> spt: I'd also like to give some lip service to the MILE-based >> protocols and how they'll fit in. Even if it's that's for a later >> stage I'd argue we need to include it now so that it's clear we're >> not trying to overlap. >> >> MILE-based/like protocols/formats provide ... and will fit in >> the overall SACM architecture ... >> >> spt: Is there anything we can say about the existing management >> protocols such as SNMP/NETCONF? >> >> spt: We'll have a motherhood and apple pie statement later about >> reuse so no need to put it in this section. >> >> >> >> >> >> sacm will achieve the following deliverables: >> >> - An Informational document on Use Cases >> >> - An Informational document on Requirements >> >> spt: Are the use cases and deliverables about sacm or just the >> endpoint assessment bit? >> >> - An Informational document on SACM Architecture >> >> spt: The architecture document is where you can go nuts and explain >> the grand vision. >> >> - A standards-track document specifying a protocol and data >> format for retrieving configuration and policy information for >> driving data collection and analysis >> >> spt: Yeah so the above bullet needs to be introduced in the > of work we're going to do> section. >> >> spt: Are you sure the data format and protocol will be in one draft? >> >> spt: Is it really "a protocol" or is it "protocols"? >> >> - A standards-track document specifying a protocol and data >> format for collecting actual endpoint posture >> >> spt: strike "actual" >> >> spt: Is it really "a protocol" or is it "protocols"? Is it nea? >> >> spt: Are you sure the data format and protocol will be in one draft? >> >> 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. >> >> spt: Funny I would have liked to have had this survey draft long ago >> ;) >> >> spt: I'm trying to see how this optional deliverable relates to the >> requirements draft and the mandate to reuse whenever protocols >> possible. What I've seen happen: WG documents requirements, >> solutions are documented (disclose IPR step here), authors of those >> solutions make their case to the WG as to why their solution is the >> best, wg then decides which to choose. >> >> spt: I don't want to limit this to SDO-developed work. First I don't >> want to get in to defining an SDO and second there might exist a >> non-SDO that has done great work and that is willing to further >> develop their work in the IETF. >> >> spt: Normally, I'd not impose this restriction but based on the >> number of "rubberstamp" questions I think the requirements draft is >> pretty darn important; seems like it needs to be done first or >> shortly after the use cases and architecture. I made that point in >> the provided text and moved the milestones around. >> >> spt: This is slightly tweaking the two paragraphs you had: >> >> There already exist protocols and data formats (i.e., >> solutions) at various levels of maturity and industry adoption >> that might be embraced to solve aspects of the SACM charter >> beyond those NEA-based protocols and MILE-based >> protocols/formats. To assist the wg when its comparing >> possible solutions against the wg-defined requirements, a draft >> will be produced that documents sacm-related IETF-developed >> (e.g., NEA and MILE) and non-IETF-developed solutions. This >> draft may or may not progress out of the wg but it will >> complete and the wg will progress the use cases, requirements >> and architecture drafts to the IESG prior to shifting its focus >> to protocol work. >> >> >> >> >> >> 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. >> >> I know we discussed wgs previously, but here I think we can leave >> them out: >> >> Close coordination with other WGs in the IETF is needed to >> avoid duplicative and overlapping solutions (e.g., management >> and repository protocols). >> >> spt: Hopefully with the earlier additions to the > do> section this paragraph won't come so quite out of the blue. >> >> 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. >> >> spt: IAB alert! What regulatory organizations are we talking about >> here? You don't have to burn this list in the charter, but you'd >> better give me a preliminary list so that I can pre-grease the IAB's >> wheels on this issue. >> >> After the work items in the current charter have been submitted >> to and approved by the IESG, the WG will recharter or close. >> >> spt: Because I don't want this to go on forever, I'd like to do >> something a little more radical: let's put a 2 year limit on the >> charter. The milestones seem to think we'll be done by then so let's >> burn it in the charter: >> >> After the work items in the current charter have been submitted >> to and approved by the IESG or after two years from the date of >> approval of this charter, the WG will recharter or close. >> >> >> >> >> >> >> >> spt: some minor tweaks: >> >> Goals and Milestones >> >> Sep 2013 - Adopt Use Case draft (informational) >> >> Oct 2013 - Adopt Requirements draft (informational) >> >> Oct 2013 - Adopt SACM Architecture draft (informational) >> >> Nov 2013 - Adopt overview of sacm-related work draft >> (informational) >> >> spt: To line up with the earlier comment I want at least want a WGLC >> of the use cases, requirements, and architecture to do out before >> protocol data formats. >> >> Apr 2014 - Submit Use Cases for consideration as Informational >> RFC >> >> Apr 2014 - Submit Requirements for consideration as >> Informational RFC >> >> Apr 2014 - Submit SACM Architecture for consideration as >> Informational RFC >> >> May 2014 - Adopt protocol and data format draft for retrieving >> configuration and policy information for driving data >> collection and analysis (standards track) >> >> May 2014 - Adopt a protocol and data format for collecting >> endpoint posture >> >> Oct 2014 - Submit 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 - Submit a protocol and data format for collecting >> actual endpoint posture for consideration as standards-track >> RFC >> >> >> >> >> >> 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 From turners@ieca.com Thu May 2 18:15:05 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 7519C21F87FB for ; Thu, 2 May 2013 18:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=0.248, 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 9xoVdNDYp-nI for ; Thu, 2 May 2013 18:15:00 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.7.5]) by ietfa.amsl.com (Postfix) with ESMTP id 437B021F87CB for ; Thu, 2 May 2013 18:15:00 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id D4A0AE35F4608; Thu, 2 May 2013 20:14:59 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id C2A43E35F45B9 for ; Thu, 2 May 2013 20:14:59 -0500 (CDT) Received: from [96.231.222.90] (port=51620 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UY4aR-0004Ny-As; Thu, 02 May 2013 20:14:59 -0500 Message-ID: <51830F92.7090505@ieca.com> Date: Thu, 02 May 2013 21:14:58 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ietfdbh References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> <5182A6F3.5040808@ieca.com> <03e501ce4786$1417fff0$3c47ffd0$@comcast.net> In-Reply-To: <03e501ce4786$1417fff0$3c47ffd0$@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) [96.231.222.90]:51620 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: 'Stephen Hanna' , sacm@ietf.org Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 03 May 2013 01:15:05 -0000 On 5/2/13 6:40 PM, ietfdbh wrote: > Hi, > > I think it makes sense to consider requirements first. > However, I think you need to be careful that the requirements don't imply a > particular solution. > It is common practice to write RFP specs to favor a particular vendor's > solution, and eliminating all others. > Requirements can lead to a rubber-stamping approach. > > Requirements for a greenfield solution might differ from requirements that > permit use of existing technologies. > I would hate to see SACM "require" a new protocol be designed for their > "special case" requirements. > (I've seen this a few times in twenty years of IETF work ;-) > Often thinking about the problem a little differently can make existing > technologies a viable solution. > > SNMPv3 invented their own security protocol because the protocol designers > (incl. me) "required" no 3rd-party dependencies. > And SNMPv3 designers "required" the ability to support multiple messaging > models, security models, user-based access controls, and other options. > But operators preferred SSH- and TLS-based solutions so they didn't have to > maintain yet another security infrastructure. > And there have been no other optional messaging models to date, and many of > the other "required" features are never used. > So we need to make sure the requirements are real and not unnecessary > nice-to-haves. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 Dave, Because this is not an entirely greenfield design I so absolutely want to make it clear now to everybody that we're going to have to do some kind of beauty contest. And, I really want to make sure that we don't end up writing the requirements in such a way as to pigeonhole us into a solution. You, others, and myself will need to make sure we don't stray from that goal. Obviously, I'd like to ensure reality is injected in the process. If we get to a place where there's one unopposed solution and there's a couple of tweaks required to meet the wg requirements, I hope the proponents of the solution will see the benefit in making those tweaks. I'd fully expect the proponent to fight (possibly a lot) on making willy-nilly changes, but if the wg consensus is to make a change then the authors of the wg draft really need to make that change - that's just how we do it. If we get to a place where there's more than one solution that seemingly meets the requirement, then I truly hope that the proponents won't take their marbles and go home and will work together to bring something kind of merged/compromised solution forward. spt > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sean > Turner > Sent: Thursday, May 02, 2013 1:49 PM > To: Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed text for the SACM WG charter > > On 5/2/13 1:21 PM, Stephen Hanna wrote: >> Sean, >> >> Thanks for your helpful comments. One quick question. >> >> You wrote: >>> 4. This is a rubberstamping exercise. We're going to work from >>> requirements, then folks will champion solutions, and then the wg >>> will pick from those solutions. >> >> Did you mean that this SHOULD NOT be a rubberstamping exercise or it >> SHOULD be one? Please clarify. > > Some people think it is going to be one. It SHOULD NOT be one and I think > forcing the requirements to get done first SHOULD make others feel more > comfortable that it won't be. > > spt > >> Given the preceding sentences, which explain that "nothing you submit >> to an SDO will emerge unchanged when it gets published by the SDO", I >> assume that you mean SACM SHOULD NOT be a rubberstamping exercise and >> the charter SHOULD say so. I agree with that view. >> >> I have a bunch of other questions or comments related to your other >> comments below but I figured I'd get this quick question answered >> first. >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>> Of Sean Turner >>> Sent: Thursday, May 02, 2013 1:04 PM >>> To: sacm@ietf.org >>> Subject: Re: [sacm] Proposed text for the SACM WG charter >>> >>> On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: >>>> >>>> Hi Sean, >>>> >>>> Following the second BOF in Orlando and your instructions, we have >>> reached consensus on the mailing list on requesting the formation of >>> a SACM Working Group, as well as on the proposed text for the future >>> Working Group charter as listed below. Please forward this to the >>> IESG for approval and let us know what are the next steps. >>>> >>>> Thanks and Regards, >>>> >>>> Kathleen and Dan >>> >>> Apologies for taking so long to get back to everyone on this. >>> I've been trying to piece together my thoughts on this charter >>> coupled with a lot of input I've gathered or that was unsolicited. >>> >>> >>> >>> These are for background so no need to reply to these. I think these >>> can all be addressed by charter text: >>> >>> 1. The comment I've received most often when discussing this charter >>> is "what are they going to do that's not already being done in nea or >>> mile." We need to make that clear. I'm sure we'll get dinged by >>> somebody about mentioning other WGs in the charter because they might >>> close/etc but I think explicitly explaining how the work done >>> elsewhere in the IETF relates to this possible work is warranted in >>> this case because I've been asked about this so many times. I think >>> it can be said that sacm is about using mile, nea, and likely other >>> to do more and we should say that somewhere. >>> >>> 2. 2nd most asked question "what exactly are they going to do?" >>> This, I think, is easily addressed by including more about what >>> exactly is entailed in "enabling endpoint assessment." >>> >>> 3. The next I've been struggling with. The 2nd paragraph about >>> reusing existing "stuff" and the paragraph about doing a survey to >>> determine which "stuff" could meet our needs are intertwined. >>> I think the phrase "whenever possible" might address my concern about >>> adopting other's work because the WG can't just take "stuff" >>> developed elsewhere; those that developed the "thing" may need give >>> it to us to adopt. Because as everybody should be well aware of: >>> nothing you submit to an SDO will emerge unchanged when it gets >>> published by the SDO. >>> >>> 4. This is a rubberstamping exercise. We're going to work from >>> requirements, then folks will champion solutions, and then the wg >>> will pick from those solutions. >>> >>> >>> >>> Now on to the charter itself. I split it up into sections. >>> Sections start with and end with . >>> "spt:" is before points I'd like to make. >>> >>> >>> >>> >>> >>> spt: chairs, ADs, mailing list looks fine so I took it out for >>> brevity. >>> >>> spt: BTW - I've recruited more than a few possible chairs. >>> If you're interested in becoming a WG chair, the first step is to >>> ask. Note: if you're planning on authoring some of the drafts, you >>> might be out of the running because we normally try to avoid >>> author/chair conflicts as much as possible. >>> >>> >>> >>> >> going to do, c) what we're not going to do, >>> d) deliverables, and e) misc> >>> >>> >>> >>> 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 (wg) will define security automation protocols and data >>> format standards in support of information security processes >>> and practices. These standards will help security practitioners >>> 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 wg is to address enterprise >>> use cases pertaining to the assessment of endpoint posture >>> (using the definitions of Endpoint and Posture from RFC 5209). >>> >>> spt: I think the intro is good, what I'd like to see next is some >>> text about what "assesment of endpoint posture" entails but that'll >>> go in the section. >>> Few folks are going to take the time to read all the documents and >>> putting it in the charter will end this line of questioning. >>> This discussion continues in the >> do> section. >>> >>> >>> >>> >>> >>> The working group will, whenever reasonable and possible, reuse >>> existing protocols, mechanisms, information and data models. Of >>> particular interest to this working group are the security >>> automation specifications supporting asset, change, >>> configuration, and vulnerability management. >>> >>> spt: This needs to be merged with the last paragraph in the >>> section. >>> >>> >>> >>> >>> >>> 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. >>> >>> spt: Instead of this numbered list I'd like as much text as it takes >>> to explain what is entailed in the assessment of endpoint posture and >>> why we need repository protocols. This is what people are going to >>> want to know when reading this charter. I think this is the >>> important part of the pact you're making with the IESG. What ought >>> these next two paragraph say: >>> >>> Assessment of endpoint posture entails ... >>> >>> Repository protocols are needed to ... >>> >>> >>> >>> >>> >>> spt: Here's where I'd like some discussion about the NEA-based >>> protocols and how they can and can't be used, whether they are "the" >>> protocols and if not why not. >>> >>> NEA-based protocols provide ... but we're doing ... >>> >>> spt: I'd also like to give some lip service to the MILE-based >>> protocols and how they'll fit in. Even if it's that's for a later >>> stage I'd argue we need to include it now so that it's clear we're >>> not trying to overlap. >>> >>> MILE-based/like protocols/formats provide ... and will fit in >>> the overall SACM architecture ... >>> >>> spt: Is there anything we can say about the existing management >>> protocols such as SNMP/NETCONF? >>> >>> spt: We'll have a motherhood and apple pie statement later about >>> reuse so no need to put it in this section. >>> >>> >>> >>> >>> >>> sacm will achieve the following deliverables: >>> >>> - An Informational document on Use Cases >>> >>> - An Informational document on Requirements >>> >>> spt: Are the use cases and deliverables about sacm or just the >>> endpoint assessment bit? >>> >>> - An Informational document on SACM Architecture >>> >>> spt: The architecture document is where you can go nuts and explain >>> the grand vision. >>> >>> - A standards-track document specifying a protocol and data >>> format for retrieving configuration and policy information for >>> driving data collection and analysis >>> >>> spt: Yeah so the above bullet needs to be introduced in the >> of work we're going to do> section. >>> >>> spt: Are you sure the data format and protocol will be in one draft? >>> >>> spt: Is it really "a protocol" or is it "protocols"? >>> >>> - A standards-track document specifying a protocol and data >>> format for collecting actual endpoint posture >>> >>> spt: strike "actual" >>> >>> spt: Is it really "a protocol" or is it "protocols"? Is it nea? >>> >>> spt: Are you sure the data format and protocol will be in one draft? >>> >>> 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. >>> >>> spt: Funny I would have liked to have had this survey draft long ago >>> ;) >>> >>> spt: I'm trying to see how this optional deliverable relates to the >>> requirements draft and the mandate to reuse whenever protocols >>> possible. What I've seen happen: WG documents requirements, >>> solutions are documented (disclose IPR step here), authors of those >>> solutions make their case to the WG as to why their solution is the >>> best, wg then decides which to choose. >>> >>> spt: I don't want to limit this to SDO-developed work. First I don't >>> want to get in to defining an SDO and second there might exist a >>> non-SDO that has done great work and that is willing to further >>> develop their work in the IETF. >>> >>> spt: Normally, I'd not impose this restriction but based on the >>> number of "rubberstamp" questions I think the requirements draft is >>> pretty darn important; seems like it needs to be done first or >>> shortly after the use cases and architecture. I made that point in >>> the provided text and moved the milestones around. >>> >>> spt: This is slightly tweaking the two paragraphs you had: >>> >>> There already exist protocols and data formats (i.e., >>> solutions) at various levels of maturity and industry adoption >>> that might be embraced to solve aspects of the SACM charter >>> beyond those NEA-based protocols and MILE-based >>> protocols/formats. To assist the wg when its comparing >>> possible solutions against the wg-defined requirements, a draft >>> will be produced that documents sacm-related IETF-developed >>> (e.g., NEA and MILE) and non-IETF-developed solutions. This >>> draft may or may not progress out of the wg but it will >>> complete and the wg will progress the use cases, requirements >>> and architecture drafts to the IESG prior to shifting its focus >>> to protocol work. >>> >>> >>> >>> >>> >>> 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. >>> >>> I know we discussed wgs previously, but here I think we can leave >>> them out: >>> >>> Close coordination with other WGs in the IETF is needed to >>> avoid duplicative and overlapping solutions (e.g., management >>> and repository protocols). >>> >>> spt: Hopefully with the earlier additions to the >> do> section this paragraph won't come so quite out of the blue. >>> >>> 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. >>> >>> spt: IAB alert! What regulatory organizations are we talking about >>> here? You don't have to burn this list in the charter, but you'd >>> better give me a preliminary list so that I can pre-grease the IAB's >>> wheels on this issue. >>> >>> After the work items in the current charter have been submitted >>> to and approved by the IESG, the WG will recharter or close. >>> >>> spt: Because I don't want this to go on forever, I'd like to do >>> something a little more radical: let's put a 2 year limit on the >>> charter. The milestones seem to think we'll be done by then so let's >>> burn it in the charter: >>> >>> After the work items in the current charter have been submitted >>> to and approved by the IESG or after two years from the date of >>> approval of this charter, the WG will recharter or close. >>> >>> >>> >>> >>> >>> >>> >>> spt: some minor tweaks: >>> >>> Goals and Milestones >>> >>> Sep 2013 - Adopt Use Case draft (informational) >>> >>> Oct 2013 - Adopt Requirements draft (informational) >>> >>> Oct 2013 - Adopt SACM Architecture draft (informational) >>> >>> Nov 2013 - Adopt overview of sacm-related work draft >>> (informational) >>> >>> spt: To line up with the earlier comment I want at least want a WGLC >>> of the use cases, requirements, and architecture to do out before >>> protocol data formats. >>> >>> Apr 2014 - Submit Use Cases for consideration as Informational >>> RFC >>> >>> Apr 2014 - Submit Requirements for consideration as >>> Informational RFC >>> >>> Apr 2014 - Submit SACM Architecture for consideration as >>> Informational RFC >>> >>> May 2014 - Adopt protocol and data format draft for retrieving >>> configuration and policy information for driving data >>> collection and analysis (standards track) >>> >>> May 2014 - Adopt a protocol and data format for collecting >>> endpoint posture >>> >>> Oct 2014 - Submit 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 - Submit a protocol and data format for collecting >>> actual endpoint posture for consideration as standards-track >>> RFC >>> >>> >>> >>> >>> >>> 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 > > From turners@ieca.com Thu May 2 18:15: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 C288D21F87CB for ; Thu, 2 May 2013 18:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.079 X-Spam-Level: X-Spam-Status: No, score=-102.079 tagged_above=-999 required=5 tests=[AWL=0.186, 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 WWy7rOIQLXW0 for ; Thu, 2 May 2013 18:15:51 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.139.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9741621F8540 for ; Thu, 2 May 2013 18:15:51 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id BD8E212B7E00F; Thu, 2 May 2013 20:15:45 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id B114F12B7DFCD for ; Thu, 2 May 2013 20:15:45 -0500 (CDT) Received: from [96.231.222.90] (port=51621 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UY4bG-0004lV-JE; Thu, 02 May 2013 20:15:50 -0500 Message-ID: <51830FC5.1010100@ieca.com> Date: Thu, 02 May 2013 21:15:49 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> <5182A6F3.5040808@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.222.90]:51621 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "Nancy Cam-Winget \(ncamwing\)" , Stephen Hanna , "sacm@ietf.org" Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 03 May 2013 01:15:56 -0000 That's good news. spt On 5/2/13 4:33 PM, Moriarty, Kathleen wrote: > FYI - We did have at least one volunteer (graciously) confirm that she would work on the requirements document and a second that is reaching out to Nancy Cam-Winget to assist. This should help. > > Thank you, > Kathleen > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sean Turner > Sent: Thursday, May 02, 2013 1:49 PM > To: Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Proposed text for the SACM WG charter > > On 5/2/13 1:21 PM, Stephen Hanna wrote: >> Sean, >> >> Thanks for your helpful comments. One quick question. >> >> You wrote: >>> 4. This is a rubberstamping exercise. We're going to work from >>> requirements, then folks will champion solutions, and then the wg >>> will pick from those solutions. >> >> Did you mean that this SHOULD NOT be a rubberstamping >> exercise or it SHOULD be one? Please clarify. > > Some people think it is going to be one. It SHOULD NOT be one and I > think forcing the requirements to get done first SHOULD make others feel > more comfortable that it won't be. > > spt > >> Given the preceding sentences, which explain that >> "nothing you submit to an SDO will emerge unchanged >> when it gets published by the SDO", I assume that >> you mean SACM SHOULD NOT be a rubberstamping exercise >> and the charter SHOULD say so. I agree with that view. >> >> I have a bunch of other questions or comments >> related to your other comments below but I >> figured I'd get this quick question answered >> first. >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Sean Turner >>> Sent: Thursday, May 02, 2013 1:04 PM >>> To: sacm@ietf.org >>> Subject: Re: [sacm] Proposed text for the SACM WG charter >>> >>> On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: >>>> >>>> Hi Sean, >>>> >>>> Following the second BOF in Orlando and your instructions, we have >>> reached consensus on the mailing list on requesting the formation of a >>> SACM Working Group, as well as on the proposed text for the future >>> Working Group charter as listed below. Please forward this to the IESG >>> for approval and let us know what are the next steps. >>>> >>>> Thanks and Regards, >>>> >>>> Kathleen and Dan >>> >>> Apologies for taking so long to get back to everyone on this. >>> I've been trying to piece together my thoughts on this charter >>> coupled with a lot of input I've gathered or that was >>> unsolicited. >>> >>> >>> >>> These are for background so no need to reply to these. I think >>> these can all be addressed by charter text: >>> >>> 1. The comment I've received most often when discussing this >>> charter is "what are they going to do that's not already being >>> done in nea or mile." We need to make that clear. I'm sure >>> we'll get dinged by somebody about mentioning other WGs in the >>> charter because they might close/etc but I think explicitly >>> explaining how the work done elsewhere in the IETF relates to >>> this possible work is warranted in this case because I've been >>> asked about this so many times. I think it can be said that sacm >>> is about using mile, nea, and likely other to do more and we >>> should say that somewhere. >>> >>> 2. 2nd most asked question "what exactly are they going to do?" >>> This, I think, is easily addressed by including more about what >>> exactly is entailed in "enabling endpoint assessment." >>> >>> 3. The next I've been struggling with. The 2nd paragraph about >>> reusing existing "stuff" and the paragraph about doing a survey >>> to determine which "stuff" could meet our needs are intertwined. >>> I think the phrase "whenever possible" might address my concern >>> about adopting other's work because the WG can't just >>> take "stuff" developed elsewhere; those that developed the >>> "thing" may need give it to us to adopt. Because as everybody >>> should be well aware of: nothing you submit to an SDO will emerge >>> unchanged when it gets published by the SDO. >>> >>> 4. This is a rubberstamping exercise. We're going to work from >>> requirements, then folks will champion solutions, and then the wg >>> will pick from those solutions. >>> >>> >>> >>> Now on to the charter itself. I split it up into sections. >>> Sections start with and end with . >>> "spt:" is before points I'd like to make. >>> >>> >>> >>> >>> >>> spt: chairs, ADs, mailing list looks fine so I took it out for >>> brevity. >>> >>> spt: BTW - I've recruited more than a few possible chairs. >>> If you're interested in becoming a WG chair, the first step is to >>> ask. Note: if you're planning on authoring some of the drafts, >>> you might be out of the running because we normally try to avoid >>> author/chair conflicts as much as possible. >>> >>> >>> >>> >> of work we're going to do, c) what we're not going to do, >>> d) deliverables, and e) misc> >>> >>> >>> >>> 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 (wg) will define security automation protocols and data >>> format standards in support of information security processes >>> and practices. These standards will help security practitioners >>> 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 wg is to address enterprise >>> use cases pertaining to the assessment of endpoint posture >>> (using the definitions of Endpoint and Posture from RFC 5209). >>> >>> spt: I think the intro is good, what I'd like to see next is some >>> text about what "assesment of endpoint posture" entails but >>> that'll go in the section. >>> Few folks are going to take the time to read all the documents >>> and putting it in the charter will end this line of questioning. >>> This discussion continues in the >> do> section. >>> >>> >>> >>> >>> >>> The working group will, whenever reasonable and possible, reuse >>> existing protocols, mechanisms, information and data models. Of >>> particular interest to this working group are the security >>> automation specifications supporting asset, change, >>> configuration, and vulnerability management. >>> >>> spt: This needs to be merged with the last paragraph in the >>> section. >>> >>> >>> >>> >>> >>> 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. >>> >>> spt: Instead of this numbered list I'd like as much text as it >>> takes to explain what is entailed in the assessment of endpoint >>> posture and why we need repository protocols. This is what >>> people are going to want to know when reading this charter. I >>> think this is the important part of the pact you're making with >>> the IESG. What ought these next two paragraph say: >>> >>> Assessment of endpoint posture entails ... >>> >>> Repository protocols are needed to ... >>> >>> >>> >>> >>> >>> spt: Here's where I'd like some discussion about the NEA-based >>> protocols and how they can and can't be used, whether they are >>> "the" protocols and if not why not. >>> >>> NEA-based protocols provide ... but we're doing ... >>> >>> spt: I'd also like to give some lip service to the MILE-based >>> protocols and how they'll fit in. Even if it's that's for a >>> later stage I'd argue we need to include it now so that it's >>> clear we're not trying to overlap. >>> >>> MILE-based/like protocols/formats provide ... and will fit in >>> the overall SACM architecture ... >>> >>> spt: Is there anything we can say about the existing management >>> protocols such as SNMP/NETCONF? >>> >>> spt: We'll have a motherhood and apple pie statement later about >>> reuse so no need to put it in this section. >>> >>> >>> >>> >>> >>> sacm will achieve the following deliverables: >>> >>> - An Informational document on Use Cases >>> >>> - An Informational document on Requirements >>> >>> spt: Are the use cases and deliverables about sacm or just the >>> endpoint assessment bit? >>> >>> - An Informational document on SACM Architecture >>> >>> spt: The architecture document is where you can go nuts and >>> explain the grand vision. >>> >>> - A standards-track document specifying a protocol and data >>> format for retrieving configuration and policy information for >>> driving data collection and analysis >>> >>> spt: Yeah so the above bullet needs to be introduced in the >>> section. >>> >>> spt: Are you sure the data format and protocol will be in one >>> draft? >>> >>> spt: Is it really "a protocol" or is it "protocols"? >>> >>> - A standards-track document specifying a protocol and data >>> format for collecting actual endpoint posture >>> >>> spt: strike "actual" >>> >>> spt: Is it really "a protocol" or is it "protocols"? Is it nea? >>> >>> spt: Are you sure the data format and protocol will be in one >>> draft? >>> >>> 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. >>> >>> spt: Funny I would have liked to have had this survey draft long >>> ago ;) >>> >>> spt: I'm trying to see how this optional deliverable relates to >>> the requirements draft and the mandate to reuse whenever >>> protocols possible. What I've seen happen: WG documents >>> requirements, solutions are documented (disclose IPR step here), >>> authors of those solutions make their case to the WG as to why >>> their solution is the best, wg then decides which to choose. >>> >>> spt: I don't want to limit this to SDO-developed work. First I >>> don't want to get in to defining an SDO and second there might >>> exist a non-SDO that has done great work and that is willing to >>> further develop their work in the IETF. >>> >>> spt: Normally, I'd not impose this restriction but based on the >>> number of "rubberstamp" questions I think the requirements draft >>> is pretty darn important; seems like it needs to be done first or >>> shortly after the use cases and architecture. I made that point >>> in the provided text and moved the milestones around. >>> >>> spt: This is slightly tweaking the two paragraphs you had: >>> >>> There already exist protocols and data formats (i.e., >>> solutions) at various levels of maturity and industry adoption >>> that might be embraced to solve aspects of the SACM charter >>> beyond those NEA-based protocols and MILE-based >>> protocols/formats. To assist the wg when its comparing >>> possible solutions against the wg-defined requirements, a draft >>> will be produced that documents sacm-related IETF-developed >>> (e.g., NEA and MILE) and non-IETF-developed solutions. This >>> draft may or may not progress out of the wg but it will >>> complete and the wg will progress the use cases, requirements >>> and architecture drafts to the IESG prior to shifting its focus >>> to protocol work. >>> >>> >>> >>> >>> >>> 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. >>> >>> I know we discussed wgs previously, but here I think we can leave >>> them out: >>> >>> Close coordination with other WGs in the IETF is needed to >>> avoid duplicative and overlapping solutions (e.g., management >>> and repository protocols). >>> >>> spt: Hopefully with the earlier additions to the >> going to do> section this paragraph won't come so quite out of >>> the blue. >>> >>> 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. >>> >>> spt: IAB alert! What regulatory organizations are we talking >>> about here? You don't have to burn this list in the charter, but >>> you'd better give me a preliminary list so that I can pre-grease >>> the IAB's wheels on this issue. >>> >>> After the work items in the current charter have been submitted >>> to and approved by the IESG, the WG will recharter or close. >>> >>> spt: Because I don't want this to go on forever, I'd like to do >>> something a little more radical: let's put a 2 year limit on the >>> charter. The milestones seem to think we'll be done by then so >>> let's burn it in the charter: >>> >>> After the work items in the current charter have been submitted >>> to and approved by the IESG or after two years from the date of >>> approval of this charter, the WG will recharter or close. >>> >>> >>> >>> >>> >>> >>> >>> spt: some minor tweaks: >>> >>> Goals and Milestones >>> >>> Sep 2013 - Adopt Use Case draft (informational) >>> >>> Oct 2013 - Adopt Requirements draft (informational) >>> >>> Oct 2013 - Adopt SACM Architecture draft (informational) >>> >>> Nov 2013 - Adopt overview of sacm-related work draft >>> (informational) >>> >>> spt: To line up with the earlier comment I want at least want a >>> WGLC of the use cases, requirements, and architecture to do out >>> before protocol data formats. >>> >>> Apr 2014 - Submit Use Cases for consideration as Informational >>> RFC >>> >>> Apr 2014 - Submit Requirements for consideration as >>> Informational RFC >>> >>> Apr 2014 - Submit SACM Architecture for consideration as >>> Informational RFC >>> >>> May 2014 - Adopt protocol and data format draft for retrieving >>> configuration and policy information for driving data >>> collection and analysis (standards track) >>> >>> May 2014 - Adopt a protocol and data format for collecting >>> endpoint posture >>> >>> Oct 2014 - Submit 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 - Submit a protocol and data format for collecting >>> actual endpoint posture for consideration as standards-track >>> RFC >>> >>> >>> >>> >>> >>> 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 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From shanna@juniper.net Fri May 3 03:50: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 09C1421F93FC for ; Fri, 3 May 2013 03:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.722 X-Spam-Level: X-Spam-Status: No, score=-102.722 tagged_above=-999 required=5 tests=[AWL=0.745, 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 xUnqUeGkBk6d for ; Fri, 3 May 2013 03:50:20 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id D6F5B21F93B6 for ; Fri, 3 May 2013 03:50:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUYOWa0f+8Wyh8h3ze0YjpnwcN4Si3oYE@postini.com; Fri, 03 May 2013 03:50:19 PDT 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; Fri, 3 May 2013 03:50:02 -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; Fri, 3 May 2013 03:50:01 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 May 2013 03:53:26 -0700 Received: from mail85-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 May 2013 10:50:00 +0000 Received: from mail85-va3 (localhost [127.0.0.1]) by mail85-va3-R.bigfish.com (Postfix) with ESMTP id 48A36320A68 for ; Fri, 3 May 2013 10:50:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI98dI9371IfecI9feI542I1432I4015Idb82hzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275dh8275ch1033ILz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail85-va3 (localhost.localdomain [127.0.0.1]) by mail85-va3 (MessageSwitch) id 1367578197449885_32303; Fri, 3 May 2013 10:49:57 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.254]) by mail85-va3.bigfish.com (Postfix) with ESMTP id 5F973220101; Fri, 3 May 2013 10:49:57 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 May 2013 10:49:57 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.43]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0305.001; Fri, 3 May 2013 10:49:56 +0000 From: Stephen Hanna To: Sean Turner , ietfdbh Thread-Topic: [sacm] Proposed text for the SACM WG charter Thread-Index: Ac40XoQq+XliguO6Trm+y2ynAw9zFAS+ImoAAAA8j/AAAVEngAAKM7oAAAVjQAAAE9oi4A== Date: Fri, 3 May 2013 10:49:55 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> <5182A6F3.5040808@ieca.com> <03e501ce4786$1417fff0$3c47ffd0$@comcast.net> <51830F92.7090505@ieca.com> In-Reply-To: <51830F92.7090505@ieca.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%IECA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%COMCAST.NET$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 Cc: "sacm@ietf.org" Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 03 May 2013 10:50:28 -0000 Sean, I completely agree with what you wrote. We should agree on requirements based on our use cases then select the best proposal among the several we'll probably receive. We may choose to combine two proposals and we'll definitely end up changing whatever we choose. However, I have often found that there needs to be some interplay between requirements definition and designing the solution. A strictly sequential approach often leads to a suboptimal design. We may find that a particular requirement just can't be met or that a new one is needed. I'm not suggesting that we make the requirements limp as a noodle or that we design them to favor one solution. I'm just suggesting that we should not send the requirements to the IESG before we have decided on a solution. I'd like to see the milestone for sending the requirements to the IESG come AFTER the adoption of the protocols and formats. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Thursday, May 02, 2013 9:15 PM > To: ietfdbh > Cc: Stephen Hanna; sacm@ietf.org > Subject: Re: [sacm] Proposed text for the SACM WG charter >=20 > On 5/2/13 6:40 PM, ietfdbh wrote: > > Hi, > > > > I think it makes sense to consider requirements first. > > However, I think you need to be careful that the requirements don't > imply a > > particular solution. > > It is common practice to write RFP specs to favor a particular > vendor's > > solution, and eliminating all others. > > Requirements can lead to a rubber-stamping approach. > > > > Requirements for a greenfield solution might differ from requirements > that > > permit use of existing technologies. > > I would hate to see SACM "require" a new protocol be designed for > their > > "special case" requirements. > > (I've seen this a few times in twenty years of IETF work ;-) > > Often thinking about the problem a little differently can make > existing > > technologies a viable solution. > > > > SNMPv3 invented their own security protocol because the protocol > designers > > (incl. me) "required" no 3rd-party dependencies. > > And SNMPv3 designers "required" the ability to support multiple > messaging > > models, security models, user-based access controls, and other > options. > > But operators preferred SSH- and TLS-based solutions so they didn't > have to > > maintain yet another security infrastructure. > > And there have been no other optional messaging models to date, and > many of > > the other "required" features are never used. > > So we need to make sure the requirements are real and not unnecessary > > nice-to-haves. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 >=20 > Dave, >=20 > Because this is not an entirely greenfield design I so absolutely want > to make it clear now to everybody that we're going to have to do some > kind of beauty contest. And, I really want to make sure that we don't > end up writing the requirements in such a way as to pigeonhole us into > a > solution. You, others, and myself will need to make sure we don't > stray > from that goal. Obviously, I'd like to ensure reality is injected in > the process. >=20 > If we get to a place where there's one unopposed solution and there's a > couple of tweaks required to meet the wg requirements, I hope the > proponents of the solution will see the benefit in making those tweaks. > I'd fully expect the proponent to fight (possibly a lot) on making > willy-nilly changes, but if the wg consensus is to make a change then > the authors of the wg draft really need to make that change - that's > just how we do it. >=20 > If we get to a place where there's more than one solution that > seemingly > meets the requirement, then I truly hope that the proponents won't take > their marbles and go home and will work together to bring something > kind > of merged/compromised solution forward. >=20 > spt >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of Sean > > Turner > > Sent: Thursday, May 02, 2013 1:49 PM > > To: Stephen Hanna > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Proposed text for the SACM WG charter > > > > On 5/2/13 1:21 PM, Stephen Hanna wrote: > >> Sean, > >> > >> Thanks for your helpful comments. One quick question. > >> > >> You wrote: > >>> 4. This is a rubberstamping exercise. We're going to work from > >>> requirements, then folks will champion solutions, and then the wg > >>> will pick from those solutions. > >> > >> Did you mean that this SHOULD NOT be a rubberstamping exercise or it > >> SHOULD be one? Please clarify. > > > > Some people think it is going to be one. It SHOULD NOT be one and I > think > > forcing the requirements to get done first SHOULD make others feel > more > > comfortable that it won't be. > > > > spt > > > >> Given the preceding sentences, which explain that "nothing you > submit > >> to an SDO will emerge unchanged when it gets published by the SDO", > I > >> assume that you mean SACM SHOULD NOT be a rubberstamping exercise > and > >> the charter SHOULD say so. I agree with that view. > >> > >> I have a bunch of other questions or comments related to your other > >> comments below but I figured I'd get this quick question answered > >> first. > >> > >> Thanks, > >> > >> Steve > >> > >>> -----Original Message----- > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > >>> Of Sean Turner > >>> Sent: Thursday, May 02, 2013 1:04 PM > >>> To: sacm@ietf.org > >>> Subject: Re: [sacm] Proposed text for the SACM WG charter > >>> > >>> On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: > >>>> > >>>> Hi Sean, > >>>> > >>>> Following the second BOF in Orlando and your instructions, we have > >>> reached consensus on the mailing list on requesting the formation > of > >>> a SACM Working Group, as well as on the proposed text for the > future > >>> Working Group charter as listed below. Please forward this to the > >>> IESG for approval and let us know what are the next steps. > >>>> > >>>> Thanks and Regards, > >>>> > >>>> Kathleen and Dan > >>> > >>> Apologies for taking so long to get back to everyone on this. > >>> I've been trying to piece together my thoughts on this charter > >>> coupled with a lot of input I've gathered or that was unsolicited. > >>> > >>> > >>> > >>> These are for background so no need to reply to these. I think > these > >>> can all be addressed by charter text: > >>> > >>> 1. The comment I've received most often when discussing this > charter > >>> is "what are they going to do that's not already being done in nea > or > >>> mile." We need to make that clear. I'm sure we'll get dinged by > >>> somebody about mentioning other WGs in the charter because they > might > >>> close/etc but I think explicitly explaining how the work done > >>> elsewhere in the IETF relates to this possible work is warranted in > >>> this case because I've been asked about this so many times. I > think > >>> it can be said that sacm is about using mile, nea, and likely other > >>> to do more and we should say that somewhere. > >>> > >>> 2. 2nd most asked question "what exactly are they going to do?" > >>> This, I think, is easily addressed by including more about what > >>> exactly is entailed in "enabling endpoint assessment." > >>> > >>> 3. The next I've been struggling with. The 2nd paragraph about > >>> reusing existing "stuff" and the paragraph about doing a survey to > >>> determine which "stuff" could meet our needs are intertwined. > >>> I think the phrase "whenever possible" might address my concern > about > >>> adopting other's work because the WG can't just take "stuff" > >>> developed elsewhere; those that developed the "thing" may need give > >>> it to us to adopt. Because as everybody should be well aware of: > >>> nothing you submit to an SDO will emerge unchanged when it gets > >>> published by the SDO. > >>> > >>> 4. This is a rubberstamping exercise. We're going to work from > >>> requirements, then folks will champion solutions, and then the wg > >>> will pick from those solutions. > >>> > >>> > >>> > >>> Now on to the charter itself. I split it up into sections. > >>> Sections start with and end with . > >>> "spt:" is before points I'd like to make. > >>> > >>> > >>> > >>> > >>> > >>> spt: chairs, ADs, mailing list looks fine so I took it out for > >>> brevity. > >>> > >>> spt: BTW - I've recruited more than a few possible chairs. > >>> If you're interested in becoming a WG chair, the first step is to > >>> ask. Note: if you're planning on authoring some of the drafts, you > >>> might be out of the running because we normally try to avoid > >>> author/chair conflicts as much as possible. > >>> > >>> > >>> > >>> we're > >>> going to do, c) what we're not going to do, > >>> d) deliverables, and e) misc> > >>> > >>> > >>> > >>> 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 (wg) will define security automation protocols and data > >>> format standards in support of information security processes > >>> and practices. These standards will help security > practitioners > >>> 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 wg is to address enterprise > >>> use cases pertaining to the assessment of endpoint posture > >>> (using the definitions of Endpoint and Posture from RFC 5209). > >>> > >>> spt: I think the intro is good, what I'd like to see next is some > >>> text about what "assesment of endpoint posture" entails but that'll > >>> go in the section. > >>> Few folks are going to take the time to read all the documents and > >>> putting it in the charter will end this line of questioning. > >>> This discussion continues in the >>> do> section. > >>> > >>> > >>> > >>> > >>> > >>> The working group will, whenever reasonable and possible, > reuse > >>> existing protocols, mechanisms, information and data models. > Of > >>> particular interest to this working group are the security > >>> automation specifications supporting asset, change, > >>> configuration, and vulnerability management. > >>> > >>> spt: This needs to be merged with the last paragraph in the > >>> section. > >>> > >>> > >>> > >>> > >>> > >>> 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. > >>> > >>> spt: Instead of this numbered list I'd like as much text as it > takes > >>> to explain what is entailed in the assessment of endpoint posture > and > >>> why we need repository protocols. This is what people are going to > >>> want to know when reading this charter. I think this is the > >>> important part of the pact you're making with the IESG. What ought > >>> these next two paragraph say: > >>> > >>> Assessment of endpoint posture entails ... > >>> > >>> Repository protocols are needed to ... > >>> > >>> > >>> > >>> > >>> > >>> spt: Here's where I'd like some discussion about the NEA-based > >>> protocols and how they can and can't be used, whether they are > "the" > >>> protocols and if not why not. > >>> > >>> NEA-based protocols provide ... but we're doing ... > >>> > >>> spt: I'd also like to give some lip service to the MILE-based > >>> protocols and how they'll fit in. Even if it's that's for a later > >>> stage I'd argue we need to include it now so that it's clear we're > >>> not trying to overlap. > >>> > >>> MILE-based/like protocols/formats provide ... and will fit in > >>> the overall SACM architecture ... > >>> > >>> spt: Is there anything we can say about the existing management > >>> protocols such as SNMP/NETCONF? > >>> > >>> spt: We'll have a motherhood and apple pie statement later about > >>> reuse so no need to put it in this section. > >>> > >>> > >>> > >>> > >>> > >>> sacm will achieve the following deliverables: > >>> > >>> - An Informational document on Use Cases > >>> > >>> - An Informational document on Requirements > >>> > >>> spt: Are the use cases and deliverables about sacm or just the > >>> endpoint assessment bit? > >>> > >>> - An Informational document on SACM Architecture > >>> > >>> spt: The architecture document is where you can go nuts and explain > >>> the grand vision. > >>> > >>> - A standards-track document specifying a protocol and data > >>> format for retrieving configuration and policy information for > >>> driving data collection and analysis > >>> > >>> spt: Yeah so the above bullet needs to be introduced in the > >>> of work we're going to do> section. > >>> > >>> spt: Are you sure the data format and protocol will be in one > draft? > >>> > >>> spt: Is it really "a protocol" or is it "protocols"? > >>> > >>> - A standards-track document specifying a protocol and data > >>> format for collecting actual endpoint posture > >>> > >>> spt: strike "actual" > >>> > >>> spt: Is it really "a protocol" or is it "protocols"? Is it nea? > >>> > >>> spt: Are you sure the data format and protocol will be in one > draft? > >>> > >>> 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. > >>> > >>> spt: Funny I would have liked to have had this survey draft long > ago > >>> ;) > >>> > >>> spt: I'm trying to see how this optional deliverable relates to the > >>> requirements draft and the mandate to reuse whenever protocols > >>> possible. What I've seen happen: WG documents requirements, > >>> solutions are documented (disclose IPR step here), authors of those > >>> solutions make their case to the WG as to why their solution is the > >>> best, wg then decides which to choose. > >>> > >>> spt: I don't want to limit this to SDO-developed work. First I > don't > >>> want to get in to defining an SDO and second there might exist a > >>> non-SDO that has done great work and that is willing to further > >>> develop their work in the IETF. > >>> > >>> spt: Normally, I'd not impose this restriction but based on the > >>> number of "rubberstamp" questions I think the requirements draft is > >>> pretty darn important; seems like it needs to be done first or > >>> shortly after the use cases and architecture. I made that point in > >>> the provided text and moved the milestones around. > >>> > >>> spt: This is slightly tweaking the two paragraphs you had: > >>> > >>> There already exist protocols and data formats (i.e., > >>> solutions) at various levels of maturity and industry adoption > >>> that might be embraced to solve aspects of the SACM charter > >>> beyond those NEA-based protocols and MILE-based > >>> protocols/formats. To assist the wg when its comparing > >>> possible solutions against the wg-defined requirements, a > draft > >>> will be produced that documents sacm-related IETF-developed > >>> (e.g., NEA and MILE) and non-IETF-developed solutions. This > >>> draft may or may not progress out of the wg but it will > >>> complete and the wg will progress the use cases, requirements > >>> and architecture drafts to the IESG prior to shifting its > focus > >>> to protocol work. > >>> > >>> > >>> > >>> > >>> > >>> 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. > >>> > >>> I know we discussed wgs previously, but here I think we can leave > >>> them out: > >>> > >>> Close coordination with other WGs in the IETF is needed to > >>> avoid duplicative and overlapping solutions (e.g., management > >>> and repository protocols). > >>> > >>> spt: Hopefully with the earlier additions to the to > >>> do> section this paragraph won't come so quite out of the blue. > >>> > >>> 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. > >>> > >>> spt: IAB alert! What regulatory organizations are we talking about > >>> here? You don't have to burn this list in the charter, but you'd > >>> better give me a preliminary list so that I can pre-grease the > IAB's > >>> wheels on this issue. > >>> > >>> After the work items in the current charter have been > submitted > >>> to and approved by the IESG, the WG will recharter or close. > >>> > >>> spt: Because I don't want this to go on forever, I'd like to do > >>> something a little more radical: let's put a 2 year limit on the > >>> charter. The milestones seem to think we'll be done by then so > let's > >>> burn it in the charter: > >>> > >>> After the work items in the current charter have been > submitted > >>> to and approved by the IESG or after two years from the date > of > >>> approval of this charter, the WG will recharter or close. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> spt: some minor tweaks: > >>> > >>> Goals and Milestones > >>> > >>> Sep 2013 - Adopt Use Case draft (informational) > >>> > >>> Oct 2013 - Adopt Requirements draft (informational) > >>> > >>> Oct 2013 - Adopt SACM Architecture draft (informational) > >>> > >>> Nov 2013 - Adopt overview of sacm-related work draft > >>> (informational) > >>> > >>> spt: To line up with the earlier comment I want at least want a > WGLC > >>> of the use cases, requirements, and architecture to do out before > >>> protocol data formats. > >>> > >>> Apr 2014 - Submit Use Cases for consideration as Informational > >>> RFC > >>> > >>> Apr 2014 - Submit Requirements for consideration as > >>> Informational RFC > >>> > >>> Apr 2014 - Submit SACM Architecture for consideration as > >>> Informational RFC > >>> > >>> May 2014 - Adopt protocol and data format draft for retrieving > >>> configuration and policy information for driving data > >>> collection and analysis (standards track) > >>> > >>> May 2014 - Adopt a protocol and data format for collecting > >>> endpoint posture > >>> > >>> Oct 2014 - Submit 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 - Submit a protocol and data format for collecting > >>> actual endpoint posture for consideration as standards-track > >>> RFC > >>> > >>> > >>> > >>> > >>> > >>> 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 > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dromasca@avaya.com Wed May 8 06:11:05 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 ABDFF21F85D6 for ; Wed, 8 May 2013 06:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 IWjIiCvuuHLN for ; Wed, 8 May 2013 06:10:59 -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 DD61821F85D7 for ; Wed, 8 May 2013 06:10:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAIpNilGHCzI1/2dsb2JhbABRgmYhv0p6FnSCHwEBAQEDEig4AhEEAgEIDQUDDRQJBzIUAw4CBAESCBqHagGlTZt2jnc4gnRhA51jinyDDoIn X-IronPort-AV: E=Sophos;i="4.87,634,1363147200"; d="scan'208";a="8445804" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 May 2013 09:10:56 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 May 2013 09:07:19 -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, 8 May 2013 09:10:54 -0400 From: "Romascanu, Dan (Dan)" To: Sean Turner , "sacm@ietf.org" Thread-Topic: [sacm] Proposed text for the SACM WG charter Thread-Index: AQHOR1cWdVZhUdzpA0CHGhO1+zpaEJj7SwLg Date: Wed, 8 May 2013 13:10:53 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA16746B@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> In-Reply-To: <51829C86.7010407@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 Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 08 May 2013 13:11:05 -0000 Hi,=20 I am trying to decompose Sean's input and his requests for clarification in= to smaller pieces, so that we can deliver a charter text that is more clear= on the scope and goals and the relations with other work.=20 The two toughest issues, key to making clear the scope is, and how the work= relates to other work in the IETF or out of it seem to be the following:=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Sean Turner >=20 > >=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 > spt: Instead of this numbered list I'd like as much text as it takes to > explain what is entailed in the assessment of endpoint posture and why > we need repository protocols. This is what people are going to want to > know when reading this charter. I think this is the important part of > the pact you're making with the IESG. What ought these next two > paragraph say: >=20 > Assessment of endpoint posture entails ... >=20 > Repository protocols are needed to ... >=20 > >=20 > >=20 > spt: Here's where I'd like some discussion about the NEA-based protocols > and how they can and can't be used, whether they are "the" protocols and > if not why not. >=20 > NEA-based protocols provide ... but we're doing ... >=20 > spt: I'd also like to give some lip service to the MILE-based protocols > and how they'll fit in. Even if it's that's for a later stage I'd argue > we need to include it now so that it's clear we're not trying to > overlap. >=20 > MILE-based/like protocols/formats provide ... and will fit in > the overall SACM architecture ... >=20 > spt: Is there anything we can say about the existing management > protocols such as SNMP/NETCONF? >=20 > spt: We'll have a motherhood and apple pie statement later about reuse > so no need to put it in this section. >=20 Can Steve or somebody else try to draft the details required by Sean and se= e if we can get consensus around them?=20 Thanks and Regards, Dan From rturner@amalfisystems.com Tue May 14 10:55: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 31E2321F8F09 for ; Tue, 14 May 2013 10:55:50 -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 4J5hrI-Hoz7c for ; Tue, 14 May 2013 10:55:42 -0700 (PDT) Received: from atl4mhfb03.myregisteredsite.com (atl4mhfb03.myregisteredsite.com [209.17.115.61]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8811E80F8 for ; Tue, 14 May 2013 10:54:27 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by atl4mhfb03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4EHraWD009358 for ; Tue, 14 May 2013 13:53:36 -0400 Received: from mail.hostingplatform.com ([10.30.71.209]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4EHqnJY014307 for ; Tue, 14 May 2013 13:52:49 -0400 Received: (qmail 1823 invoked by uid 0); 14 May 2013 17:52:49 -0000 Received: from unknown (HELO ?17.244.171.79?) (rturner@amalfisystems.com@17.244.171.79) by 0 with ESMTPA; 14 May 2013 17:52:49 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Randy Turner In-Reply-To: Date: Tue, 14 May 2013 10:52:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A6CB8FC-CD4F-467B-8340-254EB4BC0281@amalfisystems.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0C424B@AZ-FFEXMB04.global.avaya.com> <51829C86.7010407@ieca.com> <5182A6F3.5040808@ieca.com> <03e501ce4786$1417fff0$3c47ffd0$@comcast.net> <51830F92.7090505@ieca.com> To: sacm@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [sacm] Proposed text for the SACM WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 14 May 2013 17:55:55 -0000 I would paraphrase Steve's comment by saying that requirements should = not be stipulated if they are not technically feasible. Therefore, when = a requirement is proposed, there should be (preferably) a few = alternatives (not just one) about how this requirement could be realized = in a reasonable/sensible fashion. Or it could be that the requirement = is "self-evident" as far as engineering a solution, which would require = much less discussion about the "how". Randy On May 3, 2013, at 3:49 AM, Stephen Hanna wrote: > Sean, >=20 > I completely agree with what you wrote. We should agree > on requirements based on our use cases then select the > best proposal among the several we'll probably receive. > We may choose to combine two proposals and we'll definitely > end up changing whatever we choose. >=20 > However, I have often found that there needs to be some > interplay between requirements definition and designing > the solution. A strictly sequential approach often leads > to a suboptimal design. We may find that a particular > requirement just can't be met or that a new one is needed. > I'm not suggesting that we make the requirements limp as > a noodle or that we design them to favor one solution. > I'm just suggesting that we should not send the requirements > to the IESG before we have decided on a solution. I'd like > to see the milestone for sending the requirements to the > IESG come AFTER the adoption of the protocols and formats. >=20 > Thanks, >=20 > Steve >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of >> Sean Turner >> Sent: Thursday, May 02, 2013 9:15 PM >> To: ietfdbh >> Cc: Stephen Hanna; sacm@ietf.org >> Subject: Re: [sacm] Proposed text for the SACM WG charter >>=20 >> On 5/2/13 6:40 PM, ietfdbh wrote: >>> Hi, >>>=20 >>> I think it makes sense to consider requirements first. >>> However, I think you need to be careful that the requirements don't >> imply a >>> particular solution. >>> It is common practice to write RFP specs to favor a particular >> vendor's >>> solution, and eliminating all others. >>> Requirements can lead to a rubber-stamping approach. >>>=20 >>> Requirements for a greenfield solution might differ from = requirements >> that >>> permit use of existing technologies. >>> I would hate to see SACM "require" a new protocol be designed for >> their >>> "special case" requirements. >>> (I've seen this a few times in twenty years of IETF work ;-) >>> Often thinking about the problem a little differently can make >> existing >>> technologies a viable solution. >>>=20 >>> SNMPv3 invented their own security protocol because the protocol >> designers >>> (incl. me) "required" no 3rd-party dependencies. >>> And SNMPv3 designers "required" the ability to support multiple >> messaging >>> models, security models, user-based access controls, and other >> options. >>> But operators preferred SSH- and TLS-based solutions so they didn't >> have to >>> maintain yet another security infrastructure. >>> And there have been no other optional messaging models to date, and >> many of >>> the other "required" features are never used. >>> So we need to make sure the requirements are real and not = unnecessary >>> nice-to-haves. >>>=20 >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>=20 >> Dave, >>=20 >> Because this is not an entirely greenfield design I so absolutely = want >> to make it clear now to everybody that we're going to have to do some >> kind of beauty contest. And, I really want to make sure that we = don't >> end up writing the requirements in such a way as to pigeonhole us = into >> a >> solution. You, others, and myself will need to make sure we don't >> stray >> from that goal. Obviously, I'd like to ensure reality is injected in >> the process. >>=20 >> If we get to a place where there's one unopposed solution and there's = a >> couple of tweaks required to meet the wg requirements, I hope the >> proponents of the solution will see the benefit in making those = tweaks. >> I'd fully expect the proponent to fight (possibly a lot) on making >> willy-nilly changes, but if the wg consensus is to make a change then >> the authors of the wg draft really need to make that change - that's >> just how we do it. >>=20 >> If we get to a place where there's more than one solution that >> seemingly >> meets the requirement, then I truly hope that the proponents won't = take >> their marbles and go home and will work together to bring something >> kind >> of merged/compromised solution forward. >>=20 >> spt >>=20 >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> Of Sean >>> Turner >>> Sent: Thursday, May 02, 2013 1:49 PM >>> To: Stephen Hanna >>> Cc: sacm@ietf.org >>> Subject: Re: [sacm] Proposed text for the SACM WG charter >>>=20 >>> On 5/2/13 1:21 PM, Stephen Hanna wrote: >>>> Sean, >>>>=20 >>>> Thanks for your helpful comments. One quick question. >>>>=20 >>>> You wrote: >>>>> 4. This is a rubberstamping exercise. We're going to work from >>>>> requirements, then folks will champion solutions, and then the wg >>>>> will pick from those solutions. >>>>=20 >>>> Did you mean that this SHOULD NOT be a rubberstamping exercise or = it >>>> SHOULD be one? Please clarify. >>>=20 >>> Some people think it is going to be one. It SHOULD NOT be one and I >> think >>> forcing the requirements to get done first SHOULD make others feel >> more >>> comfortable that it won't be. >>>=20 >>> spt >>>=20 >>>> Given the preceding sentences, which explain that "nothing you >> submit >>>> to an SDO will emerge unchanged when it gets published by the SDO", >> I >>>> assume that you mean SACM SHOULD NOT be a rubberstamping exercise >> and >>>> the charter SHOULD say so. I agree with that view. >>>>=20 >>>> I have a bunch of other questions or comments related to your other >>>> comments below but I figured I'd get this quick question answered >>>> first. >>>>=20 >>>> Thanks, >>>>=20 >>>> Steve >>>>=20 >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf >>>>> Of Sean Turner >>>>> Sent: Thursday, May 02, 2013 1:04 PM >>>>> To: sacm@ietf.org >>>>> Subject: Re: [sacm] Proposed text for the SACM WG charter >>>>>=20 >>>>> On 4/8/13 9:39 AM, Romascanu, Dan (Dan) wrote: >>>>>>=20 >>>>>> Hi Sean, >>>>>>=20 >>>>>> Following the second BOF in Orlando and your instructions, we = have >>>>> reached consensus on the mailing list on requesting the formation >> of >>>>> a SACM Working Group, as well as on the proposed text for the >> future >>>>> Working Group charter as listed below. Please forward this to the >>>>> IESG for approval and let us know what are the next steps. >>>>>>=20 >>>>>> Thanks and Regards, >>>>>>=20 >>>>>> Kathleen and Dan >>>>>=20 >>>>> Apologies for taking so long to get back to everyone on this. >>>>> I've been trying to piece together my thoughts on this charter >>>>> coupled with a lot of input I've gathered or that was unsolicited. >>>>>=20 >>>>> >>>>>=20 >>>>> These are for background so no need to reply to these. I think >> these >>>>> can all be addressed by charter text: >>>>>=20 >>>>> 1. The comment I've received most often when discussing this >> charter >>>>> is "what are they going to do that's not already being done in nea >> or >>>>> mile." We need to make that clear. I'm sure we'll get dinged by >>>>> somebody about mentioning other WGs in the charter because they >> might >>>>> close/etc but I think explicitly explaining how the work done >>>>> elsewhere in the IETF relates to this possible work is warranted = in >>>>> this case because I've been asked about this so many times. I >> think >>>>> it can be said that sacm is about using mile, nea, and likely = other >>>>> to do more and we should say that somewhere. >>>>>=20 >>>>> 2. 2nd most asked question "what exactly are they going to do?" >>>>> This, I think, is easily addressed by including more about what >>>>> exactly is entailed in "enabling endpoint assessment." >>>>>=20 >>>>> 3. The next I've been struggling with. The 2nd paragraph about >>>>> reusing existing "stuff" and the paragraph about doing a survey to >>>>> determine which "stuff" could meet our needs are intertwined. >>>>> I think the phrase "whenever possible" might address my concern >> about >>>>> adopting other's work because the WG can't just take "stuff" >>>>> developed elsewhere; those that developed the "thing" may need = give >>>>> it to us to adopt. Because as everybody should be well aware of: >>>>> nothing you submit to an SDO will emerge unchanged when it gets >>>>> published by the SDO. >>>>>=20 >>>>> 4. This is a rubberstamping exercise. We're going to work from >>>>> requirements, then folks will champion solutions, and then the wg >>>>> will pick from those solutions. >>>>>=20 >>>>> >>>>>=20 >>>>> Now on to the charter itself. I split it up into sections. >>>>> Sections start with and end with . >>>>> "spt:" is before points I'd like to make. >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=20 >>>>> spt: chairs, ADs, mailing list looks fine so I took it out for >>>>> brevity. >>>>>=20 >>>>> spt: BTW - I've recruited more than a few possible chairs. >>>>> If you're interested in becoming a WG chair, the first step is to >>>>> ask. Note: if you're planning on authoring some of the drafts, = you >>>>> might be out of the running because we normally try to avoid >>>>> author/chair conflicts as much as possible. >>>>>=20 >>>>> >>>>>=20 >>>>> > we're >>>>> going to do, c) what we're not going to do, >>>>> d) deliverables, and e) misc> >>>>>=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 (wg) will define security automation protocols and data >>>>> format standards in support of information security processes >>>>> and practices. These standards will help security >> practitioners >>>>> 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 wg is to address enterprise >>>>> use cases pertaining to the assessment of endpoint posture >>>>> (using the definitions of Endpoint and Posture from RFC 5209). >>>>>=20 >>>>> spt: I think the intro is good, what I'd like to see next is some >>>>> text about what "assesment of endpoint posture" entails but = that'll >>>>> go in the section. >>>>> Few folks are going to take the time to read all the documents and >>>>> putting it in the charter will end this line of questioning. >>>>> This discussion continues in the >>>> do> section. >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=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 the security >>>>> automation specifications supporting asset, change, >>>>> configuration, and vulnerability management. >>>>>=20 >>>>> spt: This needs to be merged with the last paragraph in the >>>>> section. >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=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 >>>>> spt: Instead of this numbered list I'd like as much text as it >> takes >>>>> to explain what is entailed in the assessment of endpoint posture >> and >>>>> why we need repository protocols. This is what people are going = to >>>>> want to know when reading this charter. I think this is the >>>>> important part of the pact you're making with the IESG. What = ought >>>>> these next two paragraph say: >>>>>=20 >>>>> Assessment of endpoint posture entails ... >>>>>=20 >>>>> Repository protocols are needed to ... >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=20 >>>>> spt: Here's where I'd like some discussion about the NEA-based >>>>> protocols and how they can and can't be used, whether they are >> "the" >>>>> protocols and if not why not. >>>>>=20 >>>>> NEA-based protocols provide ... but we're doing ... >>>>>=20 >>>>> spt: I'd also like to give some lip service to the MILE-based >>>>> protocols and how they'll fit in. Even if it's that's for a later >>>>> stage I'd argue we need to include it now so that it's clear we're >>>>> not trying to overlap. >>>>>=20 >>>>> MILE-based/like protocols/formats provide ... and will fit in >>>>> the overall SACM architecture ... >>>>>=20 >>>>> spt: Is there anything we can say about the existing management >>>>> protocols such as SNMP/NETCONF? >>>>>=20 >>>>> spt: We'll have a motherhood and apple pie statement later about >>>>> reuse so no need to put it in this section. >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=20 >>>>> sacm will achieve the following deliverables: >>>>>=20 >>>>> - An Informational document on Use Cases >>>>>=20 >>>>> - An Informational document on Requirements >>>>>=20 >>>>> spt: Are the use cases and deliverables about sacm or just the >>>>> endpoint assessment bit? >>>>>=20 >>>>> - An Informational document on SACM Architecture >>>>>=20 >>>>> spt: The architecture document is where you can go nuts and = explain >>>>> the grand vision. >>>>>=20 >>>>> - A standards-track document specifying a protocol and data >>>>> format for retrieving configuration and policy information for >>>>> driving data collection and analysis >>>>>=20 >>>>> spt: Yeah so the above bullet needs to be introduced in the >> >>>> of work we're going to do> section. >>>>>=20 >>>>> spt: Are you sure the data format and protocol will be in one >> draft? >>>>>=20 >>>>> spt: Is it really "a protocol" or is it "protocols"? >>>>>=20 >>>>> - A standards-track document specifying a protocol and data >>>>> format for collecting actual endpoint posture >>>>>=20 >>>>> spt: strike "actual" >>>>>=20 >>>>> spt: Is it really "a protocol" or is it "protocols"? Is it nea? >>>>>=20 >>>>> spt: Are you sure the data format and protocol will be in one >> draft? >>>>>=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 >>>>> spt: Funny I would have liked to have had this survey draft long >> ago >>>>> ;) >>>>>=20 >>>>> spt: I'm trying to see how this optional deliverable relates to = the >>>>> requirements draft and the mandate to reuse whenever protocols >>>>> possible. What I've seen happen: WG documents requirements, >>>>> solutions are documented (disclose IPR step here), authors of = those >>>>> solutions make their case to the WG as to why their solution is = the >>>>> best, wg then decides which to choose. >>>>>=20 >>>>> spt: I don't want to limit this to SDO-developed work. First I >> don't >>>>> want to get in to defining an SDO and second there might exist a >>>>> non-SDO that has done great work and that is willing to further >>>>> develop their work in the IETF. >>>>>=20 >>>>> spt: Normally, I'd not impose this restriction but based on the >>>>> number of "rubberstamp" questions I think the requirements draft = is >>>>> pretty darn important; seems like it needs to be done first or >>>>> shortly after the use cases and architecture. I made that point = in >>>>> the provided text and moved the milestones around. >>>>>=20 >>>>> spt: This is slightly tweaking the two paragraphs you had: >>>>>=20 >>>>> There already exist protocols and data formats (i.e., >>>>> solutions) at various levels of maturity and industry adoption >>>>> that might be embraced to solve aspects of the SACM charter >>>>> beyond those NEA-based protocols and MILE-based >>>>> protocols/formats. To assist the wg when its comparing >>>>> possible solutions against the wg-defined requirements, a >> draft >>>>> will be produced that documents sacm-related IETF-developed >>>>> (e.g., NEA and MILE) and non-IETF-developed solutions. This >>>>> draft may or may not progress out of the wg but it will >>>>> complete and the wg will progress the use cases, requirements >>>>> and architecture drafts to the IESG prior to shifting its >> focus >>>>> to protocol work. >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=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 >>>>> I know we discussed wgs previously, but here I think we can leave >>>>> them out: >>>>>=20 >>>>> Close coordination with other WGs in the IETF is needed to >>>>> avoid duplicative and overlapping solutions (e.g., management >>>>> and repository protocols). >>>>>=20 >>>>> spt: Hopefully with the earlier additions to the > to >>>>> do> section this paragraph won't come so quite out of the blue. >>>>>=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 >>>>> spt: IAB alert! What regulatory organizations are we talking = about >>>>> here? You don't have to burn this list in the charter, but you'd >>>>> better give me a preliminary list so that I can pre-grease the >> IAB's >>>>> wheels on this issue. >>>>>=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 >>>>> spt: Because I don't want this to go on forever, I'd like to do >>>>> something a little more radical: let's put a 2 year limit on the >>>>> charter. The milestones seem to think we'll be done by then so >> let's >>>>> burn it in the charter: >>>>>=20 >>>>> After the work items in the current charter have been >> submitted >>>>> to and approved by the IESG or after two years from the date >> of >>>>> approval of this charter, the WG will recharter or close. >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=20 >>>>> spt: some minor tweaks: >>>>>=20 >>>>> Goals and Milestones >>>>>=20 >>>>> Sep 2013 - Adopt Use Case draft (informational) >>>>>=20 >>>>> Oct 2013 - Adopt Requirements draft (informational) >>>>>=20 >>>>> Oct 2013 - Adopt SACM Architecture draft (informational) >>>>>=20 >>>>> Nov 2013 - Adopt overview of sacm-related work draft >>>>> (informational) >>>>>=20 >>>>> spt: To line up with the earlier comment I want at least want a >> WGLC >>>>> of the use cases, requirements, and architecture to do out before >>>>> protocol data formats. >>>>>=20 >>>>> Apr 2014 - Submit Use Cases for consideration as Informational >>>>> RFC >>>>>=20 >>>>> Apr 2014 - Submit Requirements for consideration as >>>>> Informational RFC >>>>>=20 >>>>> Apr 2014 - Submit SACM Architecture for consideration as >>>>> Informational RFC >>>>>=20 >>>>> May 2014 - Adopt protocol and data format draft for retrieving >>>>> configuration and policy information for driving data >>>>> collection and analysis (standards track) >>>>>=20 >>>>> May 2014 - Adopt a protocol and data format for collecting >>>>> endpoint posture >>>>>=20 >>>>> Oct 2014 - Submit 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 - Submit a protocol and data format for collecting >>>>> actual endpoint posture for consideration as standards-track >>>>> RFC >>>>>=20 >>>>> >>>>>=20 >>>>> >>>>>=20 >>>>> spt >>>>> _______________________________________________ >>>>> 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 >>>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From rturner@amalfisystems.com Tue May 14 11:13: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 92D3F21F8E75 for ; Tue, 14 May 2013 11:13: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 akd7mMXBBoLj for ; Tue, 14 May 2013 11:13:50 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2121F8EAD for ; Tue, 14 May 2013 11:13:43 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.208]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4EIDaXw008168 for ; Tue, 14 May 2013 14:13:36 -0400 Received: (qmail 2348 invoked by uid 0); 14 May 2013 18:13:36 -0000 Received: from unknown (HELO ?17.244.171.79?) (rturner@amalfisystems.com@17.244.171.79) by 0 with ESMTPA; 14 May 2013 18:13:36 -0000 From: Randy Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <46835355-FFAC-4235-89C0-3B301164876F@amalfisystems.com> Date: Tue, 14 May 2013 11:13:41 -0700 To: "sacm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [sacm] WG charter X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 14 May 2013 18:13:56 -0000 After reading the current version of the charter, I don't see anything = related to the topic of "remediation" The real exciting part of the "Automation" part of the WG name would be = to remediate an issue that was found on a particular endpoint. Systems = can isolate non-compliant (non-compliant with a site security policy) = endpoints today, but, ideally, if it's an endpoint that "should" be on = the network and is under the administrative control of the site, then it = would be nice if we could "fix" the problem, automatically. Randy From adam@stoicsecurity.com Mon May 20 09:46: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 E48D321F95FC for ; Mon, 20 May 2013 09:46:04 -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 C84zs989bt-V for ; Mon, 20 May 2013 09:45:59 -0700 (PDT) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) by ietfa.amsl.com (Postfix) with ESMTP id 091A521F95FF for ; Mon, 20 May 2013 09:45:58 -0700 (PDT) Received: from [192.168.1.4] ([71.59.203.52]) by p3plsmtpa07-08.prod.phx3.secureserver.net with id eGlx1l00P18LdGv01Gly5K; Mon, 20 May 2013 09:45:58 -0700 From: "Adam W. Montville" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 20 May 2013 09:45:56 -0700 To: "sacm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 20 May 2013 16:46:05 -0000 In response to Dan's request for something we can throw against the = wall... Assessment of endpoint posture assessment entails... the following general steps: 1. Identify and classify the asset to assess 2. Identify and/or retrieve configuration checks specific to the asset = and enterprise policy. A configuration check consists of the particular = element to examine and the expected value of that element 3. Harvest the actual values of configuration elements as specified in = the content identified and/or retrieved in step 2. 4. Compare the actual values of configuration elements against expected = values After this point, decisions can be made based on the "pass/fail" state = of the configuration checks that have been made. 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. Hopefully this stokes some conversation on the list. Adam From dromasca@avaya.com Thu May 23 04:02: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 A55C321F9633 for ; Thu, 23 May 2013 04:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.422 X-Spam-Level: X-Spam-Status: No, score=-103.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 cQD4Q1tneSnH for ; Thu, 23 May 2013 04:02:37 -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 F352121F9676 for ; Thu, 23 May 2013 04:02:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwFALT1nVGHCzI1/2dsb2JhbABQCoJnITDCK4EKFnSCIwEBAQECAQEBAQ8oNAQCCgcEAgEIDQQBAwEBCxQJBycLFAMGCAIEARIIGodlBgELnhicCRMEjWGBCzgGgm1hA515in+DD4Im X-IronPort-AV: E=Sophos;i="4.87,727,1363147200"; d="scan'208";a="10375590" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 May 2013 07:02:35 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 May 2013 06:58:26 -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; Thu, 23 May 2013 13:02:33 +0200 From: "Romascanu, Dan (Dan)" To: "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: AQHOVXmGV5K3UMJjZk6trXLNupMjz5kSnT9g Date: Thu, 23 May 2013 11:02:33 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@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] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 11:02:43 -0000 Hi, Any comments, questions, concerns about Adam's proposal?=20 Just to remind - this was one of the clarification requests made by Sean ('= explain what is entailed in the assessment of endpoint posture and why we = need repository protocols.') The second set of clarifications asked by Sean were about the relation with= other work in the IETF=20 > spt: Here's where I'd like some discussion about the NEA-based=20 > protocols and how they can and can't be used, whether they are "the"=20 > protocols and if not why not. >=20 > NEA-based protocols provide ... but we're doing ... >=20 > spt: I'd also like to give some lip service to the MILE-based=20 > protocols and how they'll fit in. Even if it's that's for a later=20 > stage I'd argue we need to include it now so that it's clear we're not=20 > trying to overlap. >=20 > MILE-based/like protocols/formats provide ... and will fit in > the overall SACM architecture ... >=20 > spt: Is there anything we can say about the existing management=20 > protocols such as SNMP/NETCONF? > We need to answer these two issues. I am surprised with the lack of activit= y on the list. We will soon be losing any window of opportunity to charter = the WG before Berlin. And we cannot ask for another BOF, we already had two= ! Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam W. Montville > Sent: Monday, May 20, 2013 7:46 PM > To: sacm@ietf.org > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols >=20 > In response to Dan's request for something we can throw against the > wall... >=20 > Assessment of endpoint posture assessment entails... > the following general steps: >=20 > 1. Identify and classify the asset to assess 2. Identify and/or retrieve > configuration checks specific to the asset and enterprise policy. A > configuration check consists of the particular element to examine and > the expected value of that element 3. Harvest the actual values of > configuration elements as specified in the content identified and/or > retrieved in step 2. > 4. Compare the actual values of configuration elements against expected > values >=20 > After this point, decisions can be made based on the "pass/fail" state > of the configuration checks that have been made. >=20 >=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 >=20 > Hopefully this stokes some conversation on the list. >=20 > Adam >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Thu May 23 05: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 E5C8221F91B2 for ; Thu, 23 May 2013 05:02: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 BWwHCEU5PUDj for ; Thu, 23 May 2013 05:02: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 C1ABE21F91C4 for ; Thu, 23 May 2013 05:02:13 -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 r4NC1sUi025912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 08:02:09 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 23 May 2013 08:01:42 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4NC1gU5011808; Thu, 23 May 2013 08:01:42 -0400 Received: from mx15a.corp.emc.com ([169.254.1.105]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Thu, 23 May 2013 08:01:41 -0400 From: "Moriarty, Kathleen" To: "Romascanu, Dan (Dan)" , "Adam W. Montville" , "sacm@ietf.org" Date: Thu, 23 May 2013 08:01:41 -0400 Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: AQHOVXmGV5K3UMJjZk6trXLNupMjz5kSnT9ggAAN6UA= Message-ID: References: , <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 12:02:19 -0000 Hi, Adam's suggestions look good to me. I'll help on the complementary aspects= of MILE formats and protocols. I'll try to shorten this description or oth= ers can chime in: The MILE data formats provide a format to describe incident and threat rela= ted incident and indicator information. SACM data formats provide ways to = understand what assets are in your environment, do they meet policy require= ments, and to understand the current configuration state. The data exchang= ed in MILE, supplements the SACM data, to create situational awareness to b= etter understand current threats and mitigation measures to those prioritiz= ed threats. The combined data sets become a powerful tool to automate secu= rity with descriptions of assets and known vulnerabilities to those assets = and configurations with an understanding of layered defenses. Then injecti= ng known threat information with mitigation options assists the organizatio= n in turing detailed security decisions into business level 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, quer= y, 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. Thank you, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Romascanu,= Dan (Dan) [dromasca@avaya.com] Sent: Thursday, May 23, 2013 7:02 AM To: Adam W. Montville; sacm@ietf.org Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols Hi, Any comments, questions, concerns about Adam's proposal? Just to remind - this was one of the clarification requests made by Sean ('= explain what is entailed in the assessment of endpoint posture and why we = need repository protocols.') The second set of clarifications asked by Sean were about the relation with= other work in the IETF > spt: Here's where I'd like some discussion about the NEA-based > protocols and how they can and can't be used, whether they are "the" > protocols and if not why not. > > NEA-based protocols provide ... but we're doing ... > > spt: I'd also like to give some lip service to the MILE-based > protocols and how they'll fit in. Even if it's that's for a later > stage I'd argue we need to include it now so that it's clear we're not > trying to overlap. > > MILE-based/like protocols/formats provide ... and will fit in > the overall SACM architecture ... > > spt: Is there anything we can say about the existing management > protocols such as SNMP/NETCONF? > We need to answer these two issues. I am surprised with the lack of activit= y on the list. We will soon be losing any window of opportunity to charter = the WG before Berlin. And we cannot ask for another BOF, we already had two= ! Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam W. Montville > Sent: Monday, May 20, 2013 7:46 PM > To: sacm@ietf.org > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > In response to Dan's request for something we can throw against the > wall... > > Assessment of endpoint posture assessment entails... > the following general steps: > > 1. Identify and classify the asset to assess 2. Identify and/or retrieve > configuration checks specific to the asset and enterprise policy. A > configuration check consists of the particular element to examine and > the expected value of that element 3. Harvest the actual values of > configuration elements as specified in the content identified and/or > retrieved in step 2. > 4. Compare the actual values of configuration elements against expected > values > > After this point, decisions can be made based on the "pass/fail" state > of the configuration checks that have been made. > > > 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. > > > Hopefully this stokes some conversation on the list. > > Adam > > _______________________________________________ > 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 ietfdbh@comcast.net Thu May 23 05:05:39 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 90E4B21F9330 for ; Thu, 23 May 2013 05:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 gJSSYeizwA6O for ; Thu, 23 May 2013 05:05:35 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5821F8F00 for ; Thu, 23 May 2013 05:05:34 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id fNhe1l0030vyq2s53Q5anE; Thu, 23 May 2013 12:05:34 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta05.westchester.pa.mail.comcast.net with comcast id fQ5Z1l00r2yZEBF3RQ5ZBd; Thu, 23 May 2013 12:05:34 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , , "Sean Turner" References: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> Date: Thu, 23 May 2013 08:05:21 -0400 Message-ID: <003101ce57ad$cccabb00$66603100$@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: AQJxxrpVuw5MGxTKHsQshcafRNQt+AGoDk2Ql76I8LA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369310734; bh=4a6VAllMalax0deUsxgKeKBYEPo/O26pcmNT9kOLl2A=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=KHg1xc4i0JxwXkYyVM6s+qdJiwx664iURv8omzT4vW3FHlI6BUb/0QuHYREfirNlb bV5BUfbXo0i1a4UA7M+cCRCgkTkAF6TaKbCdeL6hAKlgqjJwT4zmc5jA7sEJ0DBAqi y+N6COKQxcs2HxmBuIBpFRwxkN7Ln7fgx0dP0eBx2//lLGOwbsuKhd2ynYo3Rqr7+1 jqoRR2mgnT9CxwPFG3d99ifKYAaWzJEcGqVlVhoCCk7UEinUs8AItJbn6bCadI554I 8ATvgDw0rMyjuvFSGasqQGKnaUb/Fgbs6TtYBLfryHC59weIC3jqM61egEO9xH+qc8 Txo6xnwlNq6NQ== Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 12:05:39 -0000 Hi, It's a little bit difficult to piece together where we are on the charter by reading the archive. The datatracker (datatracker.ietf.org) has a link for BOFs in the left menu, and sacm is listed on their BOFs page. The linked-to sacm page (http://datatracker.ietf.org/wg/sacm/charter/) is titled the charter page, but there is no charter in the title bar. Can we put a link to the current charter proposal, a link to the archive on this page, and subscribe guidance on this page. This might prompt wider participation and discussion. If having it in the datatracker page makes it hard to update, can the datatracker page provide a link to another website/wiki that is easier to update, such as http://trac.tools.ietf.org/bof/trac/wiki/BofIETF86# ? Is the charter included there the most current version? Thanks, David Harrington ietfdbh@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: Thursday, May 23, 2013 7:03 AM To: Adam W. Montville; sacm@ietf.org Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols Hi, Any comments, questions, concerns about Adam's proposal? Just to remind - this was one of the clarification requests made by Sean (' explain what is entailed in the assessment of endpoint posture and why we need repository protocols.') The second set of clarifications asked by Sean were about the relation with other work in the IETF > spt: Here's where I'd like some discussion about the NEA-based > protocols and how they can and can't be used, whether they are "the" > protocols and if not why not. > > NEA-based protocols provide ... but we're doing ... > > spt: I'd also like to give some lip service to the MILE-based > protocols and how they'll fit in. Even if it's that's for a later > stage I'd argue we need to include it now so that it's clear we're not > trying to overlap. > > MILE-based/like protocols/formats provide ... and will fit in > the overall SACM architecture ... > > spt: Is there anything we can say about the existing management > protocols such as SNMP/NETCONF? > We need to answer these two issues. I am surprised with the lack of activity on the list. We will soon be losing any window of opportunity to charter the WG before Berlin. And we cannot ask for another BOF, we already had two! Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of Adam W. Montville > Sent: Monday, May 20, 2013 7:46 PM > To: sacm@ietf.org > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > In response to Dan's request for something we can throw against the > wall... > > Assessment of endpoint posture assessment entails... > the following general steps: > > 1. Identify and classify the asset to assess 2. Identify and/or > retrieve configuration checks specific to the asset and enterprise > policy. A configuration check consists of the particular element to > examine and the expected value of that element 3. Harvest the actual > values of configuration elements as specified in the content > identified and/or retrieved in step 2. > 4. Compare the actual values of configuration elements against > expected values > > After this point, decisions can be made based on the "pass/fail" state > of the configuration checks that have been made. > > > 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. > > > Hopefully this stokes some conversation on the list. > > Adam > > _______________________________________________ > 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 May 23 05:16: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 895B421F93D1 for ; Thu, 23 May 2013 05:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 JofP3Hakwwci for ; Thu, 23 May 2013 05:16:52 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57721F9289 for ; Thu, 23 May 2013 05:16:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlGHCzI1/2dsb2JhbABGBwOCZSE2wUiBBxZ0gh8BAQEBAwEBAQ8oNAQCEQQCAQgNBAEDAQELAhIJBycLFAMGCAIEARIIARmHYAMPAQugPJM5CIlLF41aCoEBIQUNBQYLgk9hA5gjhQaKaIMLgXM1 X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="12492698" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 May 2013 08:16:47 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 May 2013 08:12:39 -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; Thu, 23 May 2013 08:16:46 -0400 From: "Romascanu, Dan (Dan)" To: ietfdbh , "sacm@ietf.org" , "Sean Turner" Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: AQHOVXmGV5K3UMJjZk6trXLNupMjz5kSnT9g///x34CAACPZkA== Date: Thu, 23 May 2013 12:16:45 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA175881@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> <003101ce57ad$cccabb00$66603100$@comcast.net> In-Reply-To: <003101ce57ad$cccabb00$66603100$@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] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 12:16:57 -0000 Hi,=20 I will ask the secretariat to do all these.=20 The latest charter proposal us AFAIK the one submitted in http://www.ietf.o= rg/mail-archive/web/sacm/current/msg01080.html.=20 Thanks and Regards, Dan > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Thursday, May 23, 2013 3:05 PM > To: Romascanu, Dan (Dan); sacm@ietf.org; Sean Turner > Subject: RE: [sacm] Endpoint Posture Assessment and Repository Protocols >=20 > Hi, >=20 > It's a little bit difficult to piece together where we are on the > charter by reading the archive. > The datatracker (datatracker.ietf.org) has a link for BOFs in the left > menu, and sacm is listed on their BOFs page. > The linked-to sacm page (http://datatracker.ietf.org/wg/sacm/charter/) > is titled the charter page, but there is no charter in the title bar. > Can we put a link to the current charter proposal, a link to the archive > on this page, and subscribe guidance on this page. > This might prompt wider participation and discussion. >=20 > If having it in the datatracker page makes it hard to update, can the > datatracker page provide a link to another website/wiki that is easier > to update, such as http://trac.tools.ietf.org/bof/trac/wiki/BofIETF86# ? > Is the charter included there the most current version? >=20 > Thanks, >=20 > David Harrington > ietfdbh@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: Thursday, May 23, 2013 7:03 AM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols >=20 > Hi, >=20 > Any comments, questions, concerns about Adam's proposal? >=20 > Just to remind - this was one of the clarification requests made by Sean > (' > explain what is entailed in the assessment of endpoint posture and why > we need repository protocols.') >=20 > The second set of clarifications asked by Sean were about the relation > with other work in the IETF >=20 > > spt: Here's where I'd like some discussion about the NEA-based > > protocols and how they can and can't be used, whether they are "the" > > protocols and if not why not. > > > > NEA-based protocols provide ... but we're doing ... > > > > spt: I'd also like to give some lip service to the MILE-based > > protocols and how they'll fit in. Even if it's that's for a later > > stage I'd argue we need to include it now so that it's clear we're not > > trying to overlap. > > > > MILE-based/like protocols/formats provide ... and will fit in > > the overall SACM architecture ... > > > > spt: Is there anything we can say about the existing management > > protocols such as SNMP/NETCONF? > > >=20 > We need to answer these two issues. I am surprised with the lack of > activity on the list. We will soon be losing any window of opportunity > to charter the WG before Berlin. And we cannot ask for another BOF, we > already had two! >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam W. Montville > > Sent: Monday, May 20, 2013 7:46 PM > > To: sacm@ietf.org > > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > > > In response to Dan's request for something we can throw against the > > wall... > > > > Assessment of endpoint posture assessment entails... > > the following general steps: > > > > 1. Identify and classify the asset to assess 2. Identify and/or > > retrieve configuration checks specific to the asset and enterprise > > policy. A configuration check consists of the particular element to > > examine and the expected value of that element 3. Harvest the actual > > values of configuration elements as specified in the content > > identified and/or retrieved in step 2. > > 4. Compare the actual values of configuration elements against > > expected values > > > > After this point, decisions can be made based on the "pass/fail" state > > of the configuration checks that have been made. > > > > > > 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. > > > > > > Hopefully this stokes some conversation on the list. > > > > Adam > > > > _______________________________________________ > > 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 Thu May 23 07:53: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 7EBF721F96CA for ; Thu, 23 May 2013 07:53:43 -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 y4SOmsytvD2X for ; Thu, 23 May 2013 07:53:37 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id F030221F96B1 for ; Thu, 23 May 2013 07:53:35 -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; Thu, 23 May 2013 10:53:40 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 23 May 2013 10:53:33 -0400 From: "Waltermire, David A." To: "Adam W. Montville" , "sacm@ietf.org" Date: Thu, 23 May 2013 10:53:32 -0400 Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: Ac5VeYdYlTQOq7ScTrKGaeGqt22eYQCSfp6w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 14:53:51 -0000 Adam, this is a great start! A few points of feedback: 1) It is not clear if retrieving the asset's (endpoint's) software inventory is included in this description. It should be. If this is considered to be configuration state then it is, but this should be made more clear. 2) There is no mention of method for the endpoint to self-publish its configuration state without the use of a checking language per se (e.g., SNMP, NETConf/YANG). I think we need a layered approach that enables state values to be reported regardless of the technical mechanism used and underlying checking mechanisms to be used to describe specific checking languages and results if needed or used. 3) Use of content in data collection should be an optional thing. If content is needed to support underlying data collection, then it should be referenced and retrieved. If the data collection engine is expressing state values using SWID, SNMP, or YANG, then content retrieval might not be needed. 4) Decisions may be made based on pass/fail evaluations or based on the actual state values that are collected. Either approach should be allowed. Thoughts? Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam W. Montville > Sent: Monday, May 20, 2013 12:46 PM > To: sacm@ietf.org > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > In response to Dan's request for something we can throw against the wall... > > Assessment of endpoint posture assessment entails... > the following general steps: > > 1. Identify and classify the asset to assess 2. Identify and/or retrieve > configuration checks specific to the asset and enterprise policy. A > configuration check consists of the particular element to examine and the > expected value of that element 3. Harvest the actual values of configuration > elements as specified in the content identified and/or retrieved in step 2. > 4. Compare the actual values of configuration elements against expected > values > > After this point, decisions can be made based on the "pass/fail" state of the > configuration checks that have been made. > > > 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. > > > Hopefully this stokes some conversation on the list. > > Adam > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Thu May 23 07:58:55 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 2531B21F9727 for ; Thu, 23 May 2013 07:58:55 -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 nsRYDQP3PEYZ for ; Thu, 23 May 2013 07:58:50 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 26DC821F9713 for ; Thu, 23 May 2013 07:58:50 -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; Thu, 23 May 2013 10:58:39 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 23 May 2013 10:58:46 -0400 From: "Waltermire, David A." To: "Moriarty, Kathleen" , "Romascanu, Dan (Dan)" , "Adam W. Montville" , "sacm@ietf.org" Date: Thu, 23 May 2013 10:58:45 -0400 Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: AQHOVXmGV5K3UMJjZk6trXLNupMjz5kSnT9ggAAN6UCAADTH0A== Message-ID: References: , <9904FB1B0159DA42B0B887B7FA8119CA1757E0@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] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 14:58:55 -0000 I think we need to include text that speaks to using SACM to collect indicator information in support of MILE/IODEF exchanges. We should also discuss the opposite side of the coin, using SACM as a way to check if some indicators (e.g. file hashes) are present on existing endpoints based on information received by an organizations RID service. IMHO, these are the killer applications for the combo in the near future. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Thursday, May 23, 2013 8:02 AM > To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols > > Hi, > > Adam's suggestions look good to me. I'll help on the complementary aspects > of MILE formats and protocols. I'll try to shorten this description or others can > chime in: > > The MILE data formats provide a format to describe incident and threat > related incident and indicator information. SACM data formats provide ways > to understand what assets are in your environment, do they meet policy > requirements, and to understand the current configuration state. The data > exchanged in MILE, supplements the SACM data, to create situational > awareness to better understand current threats and mitigation measures to > those prioritized threats. The combined data sets become a powerful tool to > automate security with descriptions of assets and known vulnerabilities to > those assets and configurations with an understanding of layered defenses. > Then injecting known threat information with mitigation options assists the > organization in turing detailed security decisions into business level 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 mo dels 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. > > > > > Thank you, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Thursday, May 23, 2013 7:02 AM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols > > Hi, > > Any comments, questions, concerns about Adam's proposal? > > Just to remind - this was one of the clarification requests made by Sean (' > explain what is entailed in the assessment of endpoint posture and why we > need repository protocols.') > > The second set of clarifications asked by Sean were about the relation with > other work in the IETF > > > spt: Here's where I'd like some discussion about the NEA-based > > protocols and how they can and can't be used, whether they are "the" > > protocols and if not why not. > > > > NEA-based protocols provide ... but we're doing ... > > > > spt: I'd also like to give some lip service to the MILE-based > > protocols and how they'll fit in. Even if it's that's for a later > > stage I'd argue we need to include it now so that it's clear we're not > > trying to overlap. > > > > MILE-based/like protocols/formats provide ... and will fit in > > the overall SACM architecture ... > > > > spt: Is there anything we can say about the existing management > > protocols such as SNMP/NETCONF? > > > > We need to answer these two issues. I am surprised with the lack of activity > on the list. We will soon be losing any window of opportunity to charter the > WG before Berlin. And we cannot ask for another BOF, we already had two! > > Regards, > > Dan > > > > > > > > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam W. Montville > > Sent: Monday, May 20, 2013 7:46 PM > > To: sacm@ietf.org > > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > > > In response to Dan's request for something we can throw against the > > wall... > > > > Assessment of endpoint posture assessment entails... > > the following general steps: > > > > 1. Identify and classify the asset to assess 2. Identify and/or > > retrieve configuration checks specific to the asset and enterprise > > policy. A configuration check consists of the particular element to > > examine and the expected value of that element 3. Harvest the actual > > values of configuration elements as specified in the content > > identified and/or retrieved in step 2. > > 4. Compare the actual values of configuration elements against > > expected values > > > > After this point, decisions can be made based on the "pass/fail" state > > of the configuration checks that have been made. > > > > > > 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. > > > > > > Hopefully this stokes some conversation on the list. > > > > Adam > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Thu May 23 08:03: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 0278821F9631 for ; Thu, 23 May 2013 08:03:19 -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 Z0SUXktq+KVM for ; Thu, 23 May 2013 08:03:14 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 040AA21F962E for ; Thu, 23 May 2013 08:03:14 -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; Thu, 23 May 2013 11:03:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 23 May 2013 11:03:12 -0400 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , "Adam W. Montville" , "sacm@ietf.org" Date: Thu, 23 May 2013 11:03:11 -0400 Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: AQHOVXmGV5K3UMJjZk6trXLNupMjz5kSnT9ggABD79A= Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@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 Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 15:03:19 -0000 One way the NEA protocols can be used is as the transport for data collected on the endpoint to enable it to be moved off the endpoint and to some external service or data repository for further analysis and action. It may also serve the purpose of carrying instructions to the endpoint for what data should be collected. Thoughts? Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Thursday, May 23, 2013 7:03 AM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols > > Hi, > > Any comments, questions, concerns about Adam's proposal? > > Just to remind - this was one of the clarification requests made by Sean (' > explain what is entailed in the assessment of endpoint posture and why we > need repository protocols.') > > The second set of clarifications asked by Sean were about the relation with > other work in the IETF > > > spt: Here's where I'd like some discussion about the NEA-based > > protocols and how they can and can't be used, whether they are "the" > > protocols and if not why not. > > > > NEA-based protocols provide ... but we're doing ... > > > > spt: I'd also like to give some lip service to the MILE-based > > protocols and how they'll fit in. Even if it's that's for a later > > stage I'd argue we need to include it now so that it's clear we're not > > trying to overlap. > > > > MILE-based/like protocols/formats provide ... and will fit in > > the overall SACM architecture ... > > > > spt: Is there anything we can say about the existing management > > protocols such as SNMP/NETCONF? > > > > We need to answer these two issues. I am surprised with the lack of activity > on the list. We will soon be losing any window of opportunity to charter the > WG before Berlin. And we cannot ask for another BOF, we already had two! > > Regards, > > Dan > > > > > > > > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam W. Montville > > Sent: Monday, May 20, 2013 7:46 PM > > To: sacm@ietf.org > > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > > > In response to Dan's request for something we can throw against the > > wall... > > > > Assessment of endpoint posture assessment entails... > > the following general steps: > > > > 1. Identify and classify the asset to assess 2. Identify and/or > > retrieve configuration checks specific to the asset and enterprise > > policy. A configuration check consists of the particular element to > > examine and the expected value of that element 3. Harvest the actual > > values of configuration elements as specified in the content > > identified and/or retrieved in step 2. > > 4. Compare the actual values of configuration elements against > > expected values > > > > After this point, decisions can be made based on the "pass/fail" state > > of the configuration checks that have been made. > > > > > > 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. > > > > > > Hopefully this stokes some conversation on the list. > > > > Adam > > > > _______________________________________________ > > 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@stoicsecurity.com Thu May 23 08:32: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 D91DC21F96A1 for ; Thu, 23 May 2013 08:32:21 -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 oPLZOU5ExGMJ for ; Thu, 23 May 2013 08:32:17 -0700 (PDT) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) by ietfa.amsl.com (Postfix) with ESMTP id D522221F9682 for ; Thu, 23 May 2013 08:32:16 -0700 (PDT) Received: from [192.168.1.4] ([71.59.203.52]) by p3plsmtpa07-02.prod.phx3.secureserver.net with id fTYD1l00L18LdGv01TYELq; Thu, 23 May 2013 08:32:14 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Adam W. Montville" In-Reply-To: Date: Thu, 23 May 2013 08:32:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1503) Cc: "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 15:32:22 -0000 On May 23, 2013, at 7:53 AM, "Waltermire, David A." = wrote: > Adam, this is a great start! A few points of feedback: >=20 > 1) It is not clear if retrieving the asset's (endpoint's) software = inventory is included in this description. It should be. If this is = considered to be configuration state then it is, but this should be made = more clear. It is. The composite nature of "asset" is such that one asset can be = installed on another and then becomes part of the "host" asset's = configuration. We can certainly update the language to make this = clearer. > 2) There is no mention of method for the endpoint to self-publish its = configuration state without the use of a checking language per se (e.g., = SNMP, NETConf/YANG). I think we need a layered approach that enables = state values to be reported regardless of the technical mechanism used = and underlying checking mechanisms to be used to describe specific = checking languages and results if needed or used. To me, this is leaning toward a "how" things are going to be done rather = than a description of what assessment means. But, we can certainly = update the language to reflect something like this. This can be done by = simply changing "retrieve" to "retrieve/receive" in the sentence in = question (I think). > 3) Use of content in data collection should be an optional thing. If = content is needed to support underlying data collection, then it should = be referenced and retrieved. If the data collection engine is = expressing state values using SWID, SNMP, or YANG, then content = retrieval might not be needed. I used the term "content" to represent the machine readable expression = of assessment criteria. Content is, in that light, always required = (even in the self-reporting case the configuration information needs to = be formatted in some way). This is a point where we should probably = become clearer on terminology. > 4) Decisions may be made based on pass/fail evaluations or based on = the actual state values that are collected. Either approach should be = allowed. I'm not sure I understand the point that's being made here. If I'm = making a decision based on actual state values, I've passed some = judgement on that value which either meets my criteria or does not meet = my criteria. >=20 > Thoughts? >=20 > Sincerely, > Dave >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of >> Adam W. Montville >> Sent: Monday, May 20, 2013 12:46 PM >> To: sacm@ietf.org >> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols >>=20 >> In response to Dan's request for something we can throw against the = wall... >>=20 >> Assessment of endpoint posture assessment entails... >> the following general steps: >>=20 >> 1. Identify and classify the asset to assess 2. Identify and/or = retrieve >> configuration checks specific to the asset and enterprise policy. A >> configuration check consists of the particular element to examine and = the >> expected value of that element 3. Harvest the actual values of = configuration >> elements as specified in the content identified and/or retrieved in = step 2. >> 4. Compare the actual values of configuration elements against = expected >> values >>=20 >> After this point, decisions can be made based on the "pass/fail" = state of the >> configuration checks that have been made. >>=20 >>=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 >>=20 >> Hopefully this stokes some conversation on the list. >>=20 >> Adam >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From adam@stoicsecurity.com Thu May 23 08:36:05 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 89F5E21F96C1 for ; Thu, 23 May 2013 08:36:05 -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 mhF0X8lvZfqs for ; Thu, 23 May 2013 08:36:00 -0700 (PDT) Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) by ietfa.amsl.com (Postfix) with ESMTP id CFA2221F96EF for ; Thu, 23 May 2013 08:35:58 -0700 (PDT) Received: from [192.168.1.4] ([71.59.203.52]) by p3plsmtpa09-05.prod.phx3.secureserver.net with id fTbw1l00118LdGv01TbwV1; Thu, 23 May 2013 08:35:57 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Adam W. Montville" In-Reply-To: Date: Thu, 23 May 2013 08:35:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> To: "Waltermire, David A." X-Mailer: Apple Mail (2.1503) Cc: "Romascanu, Dan \(Dan\)" , "Moriarty, Kathleen" , "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 15:36:05 -0000 Is this really needed? The mechanisms in SACM will be able to collect = state information from an identified asset or class of assets. Maybe = it's obvious to me that the capability to collect asset state = information could be used for a broader set of use cases than those = defined in SACM (i.e. to support indicator information gathering). =20 Given that abstract view, we could then simply state that any capability = having a need to harvest state information from a given asset could = benefit from using SACM formats/message exchanges and that this goes = both ways. On May 23, 2013, at 7:58 AM, "Waltermire, David A." = wrote: > I think we need to include text that speaks to using SACM to collect = indicator information in support of MILE/IODEF exchanges. We should also = discuss the opposite side of the coin, using SACM as a way to check if = some indicators (e.g. file hashes) are present on existing endpoints = based on information received by an organizations RID service. IMHO, = these are the killer applications for the combo in the near future. >=20 > Sincerely, > Dave >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of >> Moriarty, Kathleen >> Sent: Thursday, May 23, 2013 8:02 AM >> To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository = Protocols >>=20 >> Hi, >>=20 >> Adam's suggestions look good to me. I'll help on the complementary = aspects >> of MILE formats and protocols. I'll try to shorten this description = or others can >> chime in: >>=20 >> The MILE data formats provide a format to describe incident and = threat >> related incident and indicator information. SACM data formats = provide ways >> to understand what assets are in your environment, do they meet = policy >> requirements, and to understand the current configuration state. The = data >> exchanged in MILE, supplements the SACM data, to create situational >> awareness to better understand current threats and mitigation = measures to >> those prioritized threats. The combined data sets become a powerful = tool to >> automate security with descriptions of assets and known = vulnerabilities to >> those assets and configurations with an understanding of layered = defenses. >> Then injecting known threat information with mitigation options = assists the >> organization in turing detailed security decisions into business = level 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 mo dels 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 >>=20 >>=20 >>=20 >> Thank you, >> Kathleen >> ________________________________________ >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of >> Romascanu, Dan (Dan) [dromasca@avaya.com] >> Sent: Thursday, May 23, 2013 7:02 AM >> To: Adam W. Montville; sacm@ietf.org >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository = Protocols >>=20 >> Hi, >>=20 >> Any comments, questions, concerns about Adam's proposal? >>=20 >> Just to remind - this was one of the clarification requests made by = Sean (' >> explain what is entailed in the assessment of endpoint posture and = why we >> need repository protocols.') >>=20 >> The second set of clarifications asked by Sean were about the = relation with >> other work in the IETF >>=20 >>> spt: Here's where I'd like some discussion about the NEA-based >>> protocols and how they can and can't be used, whether they are "the" >>> protocols and if not why not. >>>=20 >>> NEA-based protocols provide ... but we're doing ... >>>=20 >>> spt: I'd also like to give some lip service to the MILE-based >>> protocols and how they'll fit in. Even if it's that's for a later >>> stage I'd argue we need to include it now so that it's clear we're = not >>> trying to overlap. >>>=20 >>> MILE-based/like protocols/formats provide ... and will fit in >>> the overall SACM architecture ... >>>=20 >>> spt: Is there anything we can say about the existing management >>> protocols such as SNMP/NETCONF? >>>=20 >>=20 >> We need to answer these two issues. I am surprised with the lack of = activity >> on the list. We will soon be losing any window of opportunity to = charter the >> WG before Berlin. And we cannot ask for another BOF, we already had = two! >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>> Of Adam W. Montville >>> Sent: Monday, May 20, 2013 7:46 PM >>> To: sacm@ietf.org >>> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols >>>=20 >>> In response to Dan's request for something we can throw against the >>> wall... >>>=20 >>> Assessment of endpoint posture assessment entails... >>> the following general steps: >>>=20 >>> 1. Identify and classify the asset to assess 2. Identify and/or >>> retrieve configuration checks specific to the asset and enterprise >>> policy. A configuration check consists of the particular element to >>> examine and the expected value of that element 3. Harvest the actual >>> values of configuration elements as specified in the content >>> identified and/or retrieved in step 2. >>> 4. Compare the actual values of configuration elements against >>> expected values >>>=20 >>> After this point, decisions can be made based on the "pass/fail" = state >>> of the configuration checks that have been made. >>>=20 >>>=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 >>>=20 >>> Hopefully this stokes some conversation on the list. >>>=20 >>> Adam >>>=20 >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From adam@stoicsecurity.com Thu May 23 09:12: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 429C621F9745 for ; Thu, 23 May 2013 09:12:19 -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 QJYlzwafruoq for ; Thu, 23 May 2013 09:12:14 -0700 (PDT) Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6891B21F9742 for ; Thu, 23 May 2013 09:12:14 -0700 (PDT) Received: from [192.168.1.4] ([71.59.203.52]) by p3plsmtpa06-08.prod.phx3.secureserver.net with id fUCB1l00h18LdGv01UCCeE; Thu, 23 May 2013 09:12:12 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Adam W. Montville" In-Reply-To: Date: Thu, 23 May 2013 09:12:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1503) Cc: "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 23 May 2013 16:12:19 -0000 To re-write the requirements taking the feedback David has provided. I = have to say that this feels much clunkier and less clear to me than it = did before. Perhaps because I would prefer to see the steps presented = in an "ideal case" or "exemplary case" scenario. Rewriting based on the = available feedback seems more like writing a spec than a charter. =20 To address the "content" issue, I've removed the term. Hopefully, this is going down the right path. =20 Step 1: [UNCHANGED] Identify and classify the asset to assess Step 2: [NEW] Identify and/or retrieve configuration checks specific to the asset and = enterprise policy. A configuration check consists of the particular = element, or configuration item, and the expected value of that element. = In some cases, the element may be an identified asset class, such as = software, in which case the expected value may be "installed" or "not = installed." [OLD] Identify and/or retrieve configuration checks specific to the asset and = enterprise policy. A configuration check consists of the particular = element to examine and the expected value of that element Step 3: [NEW] Harvest the actual values of configuration elements as specified in the = expression identified and/or retrieved in step 2. At times, assets may = self-report their configuration without a request for such reporting. [OLD] Harvest the actual values of configuration elements as specified = in the content identified and/or retrieved in step 2. Step 4: [NEW] Compare the actual values of configuration elements against = decision-making criteria. Examples of such criteria might be = "pass/fail," "installed/not installed," or something else. [OLD] Compare the actual values of configuration elements against expected = values On May 23, 2013, at 8:32 AM, "Adam W. Montville" = wrote: >=20 > On May 23, 2013, at 7:53 AM, "Waltermire, David A." = wrote: >=20 >> Adam, this is a great start! A few points of feedback: >>=20 >> 1) It is not clear if retrieving the asset's (endpoint's) software = inventory is included in this description. It should be. If this is = considered to be configuration state then it is, but this should be made = more clear. >=20 > It is. The composite nature of "asset" is such that one asset can be = installed on another and then becomes part of the "host" asset's = configuration. We can certainly update the language to make this = clearer. >=20 >=20 >> 2) There is no mention of method for the endpoint to self-publish its = configuration state without the use of a checking language per se (e.g., = SNMP, NETConf/YANG). I think we need a layered approach that enables = state values to be reported regardless of the technical mechanism used = and underlying checking mechanisms to be used to describe specific = checking languages and results if needed or used. >=20 > To me, this is leaning toward a "how" things are going to be done = rather than a description of what assessment means. But, we can = certainly update the language to reflect something like this. This can = be done by simply changing "retrieve" to "retrieve/receive" in the = sentence in question (I think). >=20 >=20 >> 3) Use of content in data collection should be an optional thing. If = content is needed to support underlying data collection, then it should = be referenced and retrieved. If the data collection engine is = expressing state values using SWID, SNMP, or YANG, then content = retrieval might not be needed. >=20 > I used the term "content" to represent the machine readable expression = of assessment criteria. Content is, in that light, always required = (even in the self-reporting case the configuration information needs to = be formatted in some way). This is a point where we should probably = become clearer on terminology. >=20 >> 4) Decisions may be made based on pass/fail evaluations or based on = the actual state values that are collected. Either approach should be = allowed. >=20 > I'm not sure I understand the point that's being made here. If I'm = making a decision based on actual state values, I've passed some = judgement on that value which either meets my criteria or does not meet = my criteria. >=20 >>=20 >> Thoughts? >>=20 >> Sincerely, >> Dave >>=20 >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of >>> Adam W. Montville >>> Sent: Monday, May 20, 2013 12:46 PM >>> To: sacm@ietf.org >>> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols >>>=20 >>> In response to Dan's request for something we can throw against the = wall... >>>=20 >>> Assessment of endpoint posture assessment entails... >>> the following general steps: >>>=20 >>> 1. Identify and classify the asset to assess 2. Identify and/or = retrieve >>> configuration checks specific to the asset and enterprise policy. A >>> configuration check consists of the particular element to examine = and the >>> expected value of that element 3. Harvest the actual values of = configuration >>> elements as specified in the content identified and/or retrieved in = step 2. >>> 4. Compare the actual values of configuration elements against = expected >>> values >>>=20 >>> After this point, decisions can be made based on the "pass/fail" = state of the >>> configuration checks that have been made. >>>=20 >>>=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 >>>=20 >>> Hopefully this stokes some conversation on the list. >>>=20 >>> Adam >>>=20 >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dromasca@avaya.com Fri May 24 02:09: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 3ABD521F96C7 for ; Fri, 24 May 2013 02:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=-0.340, 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 thLRTVzNbA01 for ; Fri, 24 May 2013 02:09:06 -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 622DC21F9690 for ; Fri, 24 May 2013 02:09:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYGAOYsn1GHCzI1/2dsb2JhbABPCoJnITDCIoEBFnSCIwEBAQEDAQEBDyg0BAEBBQwEAgEIDQQBAwEBAQoUCQcnCxQDBggCBA4FCBMHh2sBC509nCgTBI1hgQsxBwaCbWEDnXyKf4MPgiY X-IronPort-AV: E=Sophos;i="4.87,734,1363147200"; d="scan'208";a="13076504" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 May 2013 05:08:59 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 May 2013 05:04:49 -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; Fri, 24 May 2013 05:08:57 -0400 From: "Romascanu, Dan (Dan)" To: "Adam W. Montville" , "Waltermire, David A." Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: AQHOVXmGV5K3UMJjZk6trXLNupMjz5kSnT9ggAAN6UCAADTH0P//6ggAgAFHJPA= Date: Fri, 24 May 2013 09:08:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA176698@AZ-FFEXMB04.global.avaya.com> References: , <9904FB1B0159DA42B0B887B7FA8119CA1757E0@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 Cc: "Moriarty, Kathleen" , "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 09:09:12 -0000 Yes, I would go with the formulation suggested by Adam. The idea is that we= design or pick the mechanisms that meets the requirements for SACM, but th= e applicability can be broader, and if we can re-use pieces of solutions de= fined elsewhere (that meet the SACM needs) even better.=20 Regards, Dan > -----Original Message----- > From: Adam W. Montville [mailto:adam@stoicsecurity.com] > Sent: Thursday, May 23, 2013 6:36 PM > To: Waltermire, David A. > Cc: Moriarty, Kathleen; Romascanu, Dan (Dan); sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols >=20 > Is this really needed? The mechanisms in SACM will be able to collect > state information from an identified asset or class of assets. Maybe > it's obvious to me that the capability to collect asset state > information could be used for a broader set of use cases than those > defined in SACM (i.e. to support indicator information gathering). >=20 > Given that abstract view, we could then simply state that any capability > having a need to harvest state information from a given asset could > benefit from using SACM formats/message exchanges and that this goes > both ways. >=20 >=20 > On May 23, 2013, at 7:58 AM, "Waltermire, David A." > wrote: >=20 > > I think we need to include text that speaks to using SACM to collect > indicator information in support of MILE/IODEF exchanges. We should also > discuss the opposite side of the coin, using SACM as a way to check if > some indicators (e.g. file hashes) are present on existing endpoints > based on information received by an organizations RID service. IMHO, > these are the killer applications for the combo in the near future. > > > > Sincerely, > > Dave > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of Moriarty, Kathleen > >> Sent: Thursday, May 23, 2013 8:02 AM > >> To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > >> Protocols > >> > >> Hi, > >> > >> Adam's suggestions look good to me. I'll help on the complementary > >> aspects of MILE formats and protocols. I'll try to shorten this > >> description or others can chime in: > >> > >> The MILE data formats provide a format to describe incident and > >> threat related incident and indicator information. SACM data formats > >> provide ways to understand what assets are in your environment, do > >> they meet policy requirements, and to understand the current > >> configuration state. The data exchanged in MILE, supplements the > >> SACM data, to create situational awareness to better understand > >> current threats and mitigation measures to those prioritized threats. > >> The combined data sets become a powerful tool to automate security > >> with descriptions of assets and known vulnerabilities to those assets > and configurations with an understanding of layered defenses. > >> Then injecting known threat information with mitigation options > >> assists the organization in turing detailed security decisions into > business level 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 mo dels 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. > >> > >> > >> > >> > >> Thank you, > >> Kathleen > >> ________________________________________ > >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of > >> Romascanu, Dan (Dan) [dromasca@avaya.com] > >> Sent: Thursday, May 23, 2013 7:02 AM > >> To: Adam W. Montville; sacm@ietf.org > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > >> Protocols > >> > >> Hi, > >> > >> Any comments, questions, concerns about Adam's proposal? > >> > >> Just to remind - this was one of the clarification requests made by > Sean (' > >> explain what is entailed in the assessment of endpoint posture and > >> why we need repository protocols.') > >> > >> The second set of clarifications asked by Sean were about the > >> relation with other work in the IETF > >> > >>> spt: Here's where I'd like some discussion about the NEA-based > >>> protocols and how they can and can't be used, whether they are "the" > >>> protocols and if not why not. > >>> > >>> NEA-based protocols provide ... but we're doing ... > >>> > >>> spt: I'd also like to give some lip service to the MILE-based > >>> protocols and how they'll fit in. Even if it's that's for a later > >>> stage I'd argue we need to include it now so that it's clear we're > >>> not trying to overlap. > >>> > >>> MILE-based/like protocols/formats provide ... and will fit in > >>> the overall SACM architecture ... > >>> > >>> spt: Is there anything we can say about the existing management > >>> protocols such as SNMP/NETCONF? > >>> > >> > >> We need to answer these two issues. I am surprised with the lack of > >> activity on the list. We will soon be losing any window of > >> opportunity to charter the WG before Berlin. And we cannot ask for > another BOF, we already had two! > >> > >> Regards, > >> > >> Dan > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >>> Of Adam W. Montville > >>> Sent: Monday, May 20, 2013 7:46 PM > >>> To: sacm@ietf.org > >>> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > >>> > >>> In response to Dan's request for something we can throw against the > >>> wall... > >>> > >>> Assessment of endpoint posture assessment entails... > >>> the following general steps: > >>> > >>> 1. Identify and classify the asset to assess 2. Identify and/or > >>> retrieve configuration checks specific to the asset and enterprise > >>> policy. A configuration check consists of the particular element to > >>> examine and the expected value of that element 3. Harvest the actual > >>> values of configuration elements as specified in the content > >>> identified and/or retrieved in step 2. > >>> 4. Compare the actual values of configuration elements against > >>> expected values > >>> > >>> After this point, decisions can be made based on the "pass/fail" > >>> state of the configuration checks that have been made. > >>> > >>> > >>> 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. > >>> > >>> > >>> Hopefully this stokes some conversation on the list. > >>> > >>> Adam > >>> > >>> _______________________________________________ > >>> sacm mailing list > >>> sacm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sacm > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Fri May 24 12:48: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 56D4921E8099 for ; Fri, 24 May 2013 12:48:16 -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 Ofi96d8ygPvJ for ; Fri, 24 May 2013 12:48:11 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A2EF521E80A8 for ; Fri, 24 May 2013 12:48:10 -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; Fri, 24 May 2013 15:47:56 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 24 May 2013 15:48:05 -0400 From: "Waltermire, David A." To: "Adam W. Montville" Date: Fri, 24 May 2013 15:48:04 -0400 Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: Ac5XyrVxVAREDGAhTbibRbUT89fJeQA6NYcQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 19:48:16 -0000 Adam, Comments are inline. Thanks, Dave > -----Original Message----- > From: Adam W. Montville [mailto:adam@stoicsecurity.com] > Sent: Thursday, May 23, 2013 11:32 AM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols > > > On May 23, 2013, at 7:53 AM, "Waltermire, David A." > wrote: > > > Adam, this is a great start! A few points of feedback: > > > > 1) It is not clear if retrieving the asset's (endpoint's) software inventory is > included in this description. It should be. If this is considered to be > configuration state then it is, but this should be made more clear. > > It is. The composite nature of "asset" is such that one asset can be installed > on another and then becomes part of the "host" asset's configuration. We > can certainly update the language to make this clearer. While assets are compositional as you have stated, for management purposes it is often necessary to draw a box around collections of assets. The term "endpoint" has been used in some of the drafts considered as part of this work as a term that provides such a grouping. My concern with using the term asset in the charter is that it means many different things to many different people. I like the use of endpoint since we can point to the RFC 5209 for a definition. We had some discussion about using the terms "endpoint" and "posture" in the past. I think we should stick with these terms for consistency and clarity. > > 2) There is no mention of method for the endpoint to self-publish its > configuration state without the use of a checking language per se (e.g., > SNMP, NETConf/YANG). I think we need a layered approach that enables > state values to be reported regardless of the technical mechanism used and > underlying checking mechanisms to be used to describe specific checking > languages and results if needed or used. > > To me, this is leaning toward a "how" things are going to be done rather than > a description of what assessment means. But, we can certainly update the > language to reflect something like this. This can be done by simply changing > "retrieve" to "retrieve/receive" in the sentence in question (I think). Step #2 from your original proposed text discusses identification and/or retrieval of configuration checks specific to the asset and enterprise policy. The term "check" is what I was most concerned about here as check to me has inherent meaning as a declaration of how to gather an aspect of device state (or endpoint posture). To me this also sounds like a "how" to perform data collection. What I am advocating for is separating the method of collecting the state from the method used to express and exchange the collected state. My concern is that your proposed wording for charter indicates that a check is "identified and/or retrieved" as part of endpoint posture assessment. If a check is not required or needed to perform this, such as in a SNMP or YANG scenario where the assessment engine has some built-in understanding of how to get the information, then the check will not be need to be identified and/or retrieved making step #2 optional. > > 3) Use of content in data collection should be an optional thing. If content > is needed to support underlying data collection, then it should be referenced > and retrieved. If the data collection engine is expressing state values using > SWID, SNMP, or YANG, then content retrieval might not be needed. > > I used the term "content" to represent the machine readable expression of > assessment criteria. Content is, in that light, always required (even in the > self-reporting case the configuration information needs to be formatted in > some way). This is a point where we should probably become clearer on > terminology. Same comments as above. I guess a schema (or similar concept) may be needed to verify/validate the produced collected results, but it may not be necessary to retrieve content that drives the data collection (steps #2 and #3). Where content will likely be needed is in step #4 to support evaluation of the actual and expected values. This content would define the expected values and any logic for evaluation pertaining to pass/fail or scoring methods. > > 4) Decisions may be made based on pass/fail evaluations or based on the > actual state values that are collected. Either approach should be allowed. > > I'm not sure I understand the point that's being made here. If I'm making a > decision based on actual state values, I've passed some judgement on that > value which either meets my criteria or does not meet my criteria. This is a good point; it all roughly the same kinds of decision logic. What I was highlighting is that decisions may be made based on the raw collected data (if x setting = y value do z) or based on some derived information (if x asset/endpoint is not compliant with y policy do z). Both levels of decision logic are desirable, but to support both we need both raw data and derived information to be made available for analysis outside the endpoint. This is the important distinction. > > > > > Thoughts? > > > > Sincerely, > > Dave > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of Adam W. Montville > >> Sent: Monday, May 20, 2013 12:46 PM > >> To: sacm@ietf.org > >> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > >> > >> In response to Dan's request for something we can throw against the > wall... > >> > >> Assessment of endpoint posture assessment entails... > >> the following general steps: > >> > >> 1. Identify and classify the asset to assess 2. Identify and/or > >> retrieve configuration checks specific to the asset and enterprise > >> policy. A configuration check consists of the particular element to > >> examine and the expected value of that element 3. Harvest the actual > >> values of configuration elements as specified in the content identified > and/or retrieved in step 2. > >> 4. Compare the actual values of configuration elements against > >> expected values > >> > >> After this point, decisions can be made based on the "pass/fail" > >> state of the configuration checks that have been made. > >> > >> > >> 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. > >> > >> > >> Hopefully this stokes some conversation on the list. > >> > >> Adam > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Fri May 24 13: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 C1EAA21F854D for ; Fri, 24 May 2013 13:00:06 -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 q7yrox4rHlta for ; Fri, 24 May 2013 13:00:02 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE3021F8532 for ; Fri, 24 May 2013 13:00:01 -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; Fri, 24 May 2013 16:00:02 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 24 May 2013 15:59:58 -0400 From: "Waltermire, David A." To: "Adam W. Montville" Date: Fri, 24 May 2013 15:59:56 -0400 Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: Ac5XyznJ0dDeO531Q8GUN7zlHRjMNwA7HgQw Message-ID: References: , <9904FB1B0159DA42B0B887B7FA8119CA1757E0@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 Cc: "Romascanu, Dan \(Dan\)" , "turners@ieca.com" , "Moriarty, Kathleen" , "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 20:00:06 -0000 I couldn't agree more that the "plumbing" provided by SACM is useful in a variety of contexts, including but not limited to incident handling. From reading Sean's comments, my interpretation was that he was looking for more specifics about how MILE and SACM support each other from an architectural perspective. While Kathleen's text is well written and speaks from a high-level about the synergy between the two efforts, it doesn't speak to how technologically the two efforts are related. I believe a few specific examples would help to clarify the relationship between the two efforts. Sincerely, Dave > -----Original Message----- > From: Adam W. Montville [mailto:adam@stoicsecurity.com] > Sent: Thursday, May 23, 2013 11:36 AM > To: Waltermire, David A. > Cc: Moriarty, Kathleen; Romascanu, Dan (Dan); sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols > > Is this really needed? The mechanisms in SACM will be able to collect state > information from an identified asset or class of assets. Maybe it's obvious to > me that the capability to collect asset state information could be used for a > broader set of use cases than those defined in SACM (i.e. to support > indicator information gathering). > > Given that abstract view, we could then simply state that any capability > having a need to harvest state information from a given asset could benefit > from using SACM formats/message exchanges and that this goes both ways. > > > On May 23, 2013, at 7:58 AM, "Waltermire, David A." > wrote: > > > I think we need to include text that speaks to using SACM to collect > indicator information in support of MILE/IODEF exchanges. We should also > discuss the opposite side of the coin, using SACM as a way to check if some > indicators (e.g. file hashes) are present on existing endpoints based on > information received by an organizations RID service. IMHO, these are the > killer applications for the combo in the near future. > > > > Sincerely, > > Dave > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of Moriarty, Kathleen > >> Sent: Thursday, May 23, 2013 8:02 AM > >> To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > >> Protocols > >> > >> Hi, > >> > >> Adam's suggestions look good to me. I'll help on the complementary > >> aspects of MILE formats and protocols. I'll try to shorten this > >> description or others can chime in: > >> > >> The MILE data formats provide a format to describe incident and > >> threat related incident and indicator information. SACM data formats > >> provide ways to understand what assets are in your environment, do > >> they meet policy requirements, and to understand the current > >> configuration state. The data exchanged in MILE, supplements the > >> SACM data, to create situational awareness to better understand > >> current threats and mitigation measures to those prioritized threats. > >> The combined data sets become a powerful tool to automate security > >> with descriptions of assets and known vulnerabilities to those assets and > configurations with an understanding of layered defenses. > >> Then injecting known threat information with mitigation options > >> assists the organization in turing detailed security decisions into business > level 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 mo dels 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. > >> > >> > >> > >> > >> Thank you, > >> Kathleen > >> ________________________________________ > >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of > >> Romascanu, Dan (Dan) [dromasca@avaya.com] > >> Sent: Thursday, May 23, 2013 7:02 AM > >> To: Adam W. Montville; sacm@ietf.org > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > >> Protocols > >> > >> Hi, > >> > >> Any comments, questions, concerns about Adam's proposal? > >> > >> Just to remind - this was one of the clarification requests made by Sean (' > >> explain what is entailed in the assessment of endpoint posture and > >> why we need repository protocols.') > >> > >> The second set of clarifications asked by Sean were about the > >> relation with other work in the IETF > >> > >>> spt: Here's where I'd like some discussion about the NEA-based > >>> protocols and how they can and can't be used, whether they are "the" > >>> protocols and if not why not. > >>> > >>> NEA-based protocols provide ... but we're doing ... > >>> > >>> spt: I'd also like to give some lip service to the MILE-based > >>> protocols and how they'll fit in. Even if it's that's for a later > >>> stage I'd argue we need to include it now so that it's clear we're > >>> not trying to overlap. > >>> > >>> MILE-based/like protocols/formats provide ... and will fit in > >>> the overall SACM architecture ... > >>> > >>> spt: Is there anything we can say about the existing management > >>> protocols such as SNMP/NETCONF? > >>> > >> > >> We need to answer these two issues. I am surprised with the lack of > >> activity on the list. We will soon be losing any window of > >> opportunity to charter the WG before Berlin. And we cannot ask for > another BOF, we already had two! > >> > >> Regards, > >> > >> Dan > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > >>> Of Adam W. Montville > >>> Sent: Monday, May 20, 2013 7:46 PM > >>> To: sacm@ietf.org > >>> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > >>> > >>> In response to Dan's request for something we can throw against the > >>> wall... > >>> > >>> Assessment of endpoint posture assessment entails... > >>> the following general steps: > >>> > >>> 1. Identify and classify the asset to assess 2. Identify and/or > >>> retrieve configuration checks specific to the asset and enterprise > >>> policy. A configuration check consists of the particular element to > >>> examine and the expected value of that element 3. Harvest the actual > >>> values of configuration elements as specified in the content > >>> identified and/or retrieved in step 2. > >>> 4. Compare the actual values of configuration elements against > >>> expected values > >>> > >>> After this point, decisions can be made based on the "pass/fail" > >>> state of the configuration checks that have been made. > >>> > >>> > >>> 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. > >>> > >>> > >>> Hopefully this stokes some conversation on the list. > >>> > >>> Adam > >>> > >>> _______________________________________________ > >>> sacm mailing list > >>> sacm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sacm > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Fri May 24 13:53: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 B28CC11E8132 for ; Fri, 24 May 2013 13:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 smpVvkVbFok3 for ; Fri, 24 May 2013 13:53:24 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE7E11E8135 for ; Fri, 24 May 2013 13:53:19 -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; Fri, 24 May 2013 16:53:17 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 24 May 2013 16:53:13 -0400 From: "Waltermire, David A." To: "Adam W. Montville" Date: Fri, 24 May 2013 16:53:12 -0400 Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: Ac5X0EojIZK+AKeKQ42sJ26zoTGwEQA6QpGg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 20:53:28 -0000 How about this? Endpoint Posture Assessment involves four distinct but related activities: 1) identification of the policies that need to be evaluated, 2) retrieval of policy content, 3) retrieval of existing or collection of current endpoint posture data that is relevant to the policies, and 4) evaluation of policies based on available endpoint posture data. The policies to be evaluated are identified and retrieved based on the evaluation context (e.g., compliance reporting, access control decision, indicator gathering). Endpoint posture is gathered from existing stores of data and/or by directly collecting posture data from the endpoint as needed. Policies are then evaluated based on available data supporting human- and machine-oriented decision making as appropriate to the evaluation context. Endpoint posture is collected using the following method: 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 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. Some points may need additional clarification. Thoughts? Dave > -----Original Message----- > From: Adam W. Montville [mailto:adam@stoicsecurity.com] > Sent: Thursday, May 23, 2013 12:12 PM > To: Waltermire, David A. > Cc: sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols > > To re-write the requirements taking the feedback David has provided. I have > to say that this feels much clunkier and less clear to me than it did before. > Perhaps because I would prefer to see the steps presented in an "ideal case" > or "exemplary case" scenario. Rewriting based on the available feedback > seems more like writing a spec than a charter. > > To address the "content" issue, I've removed the term. > > Hopefully, this is going down the right path. > > Step 1: > [UNCHANGED] Identify and classify the asset to assess > > Step 2: > [NEW] > Identify and/or retrieve configuration checks specific to the asset and > enterprise policy. A configuration check consists of the particular element, or > configuration item, and the expected value of that element. In some cases, > the element may be an identified asset class, such as software, in which case > the expected value may be "installed" or "not installed." Why is the expected value relevant here if the goal is to collect the current state? > > [OLD] > Identify and/or retrieve configuration checks specific to the asset and > enterprise policy. A configuration check consists of the particular element to > examine and the expected value of that element > > Step 3: > [NEW] > Harvest the actual values of configuration elements as specified in the > expression identified and/or retrieved in step 2. At times, assets may self- > report their configuration without a request for such reporting. > > [OLD] Harvest the actual values of configuration elements as specified in the > content identified and/or retrieved in step 2. > > Step 4: > [NEW] > Compare the actual values of configuration elements against decision-making > criteria. Examples of such criteria might be "pass/fail," "installed/not > installed," or something else. > > [OLD] > Compare the actual values of configuration elements against expected > values > > > > > On May 23, 2013, at 8:32 AM, "Adam W. Montville" > wrote: > > > > > On May 23, 2013, at 7:53 AM, "Waltermire, David A." > wrote: > > > >> Adam, this is a great start! A few points of feedback: > >> > >> 1) It is not clear if retrieving the asset's (endpoint's) software inventory is > included in this description. It should be. If this is considered to be > configuration state then it is, but this should be made more clear. > > > > It is. The composite nature of "asset" is such that one asset can be installed > on another and then becomes part of the "host" asset's configuration. We > can certainly update the language to make this clearer. > > > > > >> 2) There is no mention of method for the endpoint to self-publish its > configuration state without the use of a checking language per se (e.g., > SNMP, NETConf/YANG). I think we need a layered approach that enables > state values to be reported regardless of the technical mechanism used and > underlying checking mechanisms to be used to describe specific checking > languages and results if needed or used. > > > > To me, this is leaning toward a "how" things are going to be done rather > than a description of what assessment means. But, we can certainly update > the language to reflect something like this. This can be done by simply > changing "retrieve" to "retrieve/receive" in the sentence in question (I > think). > > > > > >> 3) Use of content in data collection should be an optional thing. If content > is needed to support underlying data collection, then it should be referenced > and retrieved. If the data collection engine is expressing state values using > SWID, SNMP, or YANG, then content retrieval might not be needed. > > > > I used the term "content" to represent the machine readable expression of > assessment criteria. Content is, in that light, always required (even in the > self-reporting case the configuration information needs to be formatted in > some way). This is a point where we should probably become clearer on > terminology. > > > >> 4) Decisions may be made based on pass/fail evaluations or based on the > actual state values that are collected. Either approach should be allowed. > > > > I'm not sure I understand the point that's being made here. If I'm making a > decision based on actual state values, I've passed some judgement on that > value which either meets my criteria or does not meet my criteria. > > > >> > >> Thoughts? > >> > >> Sincerely, > >> Dave > >> > >>> -----Original Message----- > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > >>> Of Adam W. Montville > >>> Sent: Monday, May 20, 2013 12:46 PM > >>> To: sacm@ietf.org > >>> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > >>> > >>> In response to Dan's request for something we can throw against the > wall... > >>> > >>> Assessment of endpoint posture assessment entails... > >>> the following general steps: > >>> > >>> 1. Identify and classify the asset to assess 2. Identify and/or > >>> retrieve configuration checks specific to the asset and enterprise > >>> policy. A configuration check consists of the particular element to > >>> examine and the expected value of that element 3. Harvest the actual > >>> values of configuration elements as specified in the content identified > and/or retrieved in step 2. > >>> 4. Compare the actual values of configuration elements against > >>> expected values > >>> > >>> After this point, decisions can be made based on the "pass/fail" > >>> state of the configuration checks that have been made. > >>> > >>> > >>> 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. > >>> > >>> > >>> Hopefully this stokes some conversation on the list. > >>> > >>> Adam > >>> > >>> _______________________________________________ > >>> 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 ietf-secretariat-reply@ietf.org Thu May 23 09:32: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 79EF021F9709 for ; Thu, 23 May 2013 09:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 83P4PSj0MK3P for ; Thu, 23 May 2013 09:32:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4B321F9713 for ; Thu, 23 May 2013 09:32:04 -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: <20130523163204.24035.37597.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 09:32:04 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 24 May 2013 14:00:17 -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, 23 May 2013 16:32:51 -0000 Added milestone "Initial submission of an Internet-Draft on Use Cases", due September 2013. Added milestone "Initial submission of an Internet-Draft on Requirements", due October 2013. Added milestone "Initial submission of an Internet-Draft on SACM Architecture", due October 2013. Added milestone "Initial submission of an Internet-Draft on overview of related standards work", due November 2013. Added milestone "Initial submission of an Internet-Draft for a protocol and data format for retrieving configuration and policy information for driving data collection and analysis", due January 2014. Added milestone "Initial submission of an Internet-Draft for a protocol and data format for collecting actual endpoint posture", due January 2014. Added milestone "Submission to the IESG of the Internet-Draft on Use Cases for consideration as Informational RFC", due April 2014. Added milestone "Submission to the IESG of the Internet-Draft on Requirements for consideration as Informational RFC", due April 2014. Added milestone "Submission to the IESG of the Internet-Draft on SACM Architecture for consideration as Informational RFC", due April 2014. Added 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", due October 2014. Added 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", due October 2014. URL: http://datatracker.ietf.org/wg/sacm/charter/ From jfield@gopivotal.com Fri May 24 13:44: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 73DCB11E8126 for ; Fri, 24 May 2013 13:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W71Y4mhDBWSt for ; Fri, 24 May 2013 13:44:04 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4842111E811F for ; Fri, 24 May 2013 13:44:04 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id f4so6761636oah.10 for ; Fri, 24 May 2013 13:44:03 -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=ZQZa/3HiBi5DNbQuUXR3zwBBXlbO1htovccbYaMXQgA=; b=YFZDzCpmXdmbhQxld54Kmm7j1lcSGTr0/pWhNCdE03p7M6RLSiMc75wtu98Zm52KxM ZhfwGZ7y4fs8TuL5i3wEFMnmILmTHpEu0RsYwtKFU8JscCatNVEoQKT74OGmPgDjKYA4 dtbYAsM2j74PSdp5uO75M1aW0QTyupMsAxMHbvN9ZRjrcLfRI/nhLLZTaPsB/SMsDYpw iz+l3tuCl9yP4+tzR6w1USvkMD9LW7uecDmvzz5cYG5uY+OuL7N61GtbvXerS/vZq0Nx gnuJ9d9UOCYcBAWnKA41E4LrXrjpg3DvuIU2j2L05ErgxGls/hLZjTGfR9HrtHmSIIgg UFqQ== MIME-Version: 1.0 X-Received: by 10.60.47.81 with SMTP id b17mr12989371oen.63.1369428243768; Fri, 24 May 2013 13:44:03 -0700 (PDT) Received: by 10.76.84.104 with HTTP; Fri, 24 May 2013 13:44:03 -0700 (PDT) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> Date: Fri, 24 May 2013 16:44:03 -0400 Message-ID: From: John Field To: "Waltermire, David A." Content-Type: multipart/related; boundary=001a11c1fffe03fa5604dd7cdcad X-Gm-Message-State: ALoCoQnOFecNJc6I12+AK4RcYwkCQ0EWCKHyptAEJsf6XhvkxVtIO6v9gJTIoVP2d9m8ciM7mXsV X-Mailman-Approved-At: Fri, 24 May 2013 14:00:17 -0700 Cc: "Romascanu, Dan \(Dan\)" , "turners@ieca.com" , "Adam W. Montville" , "sacm@ietf.org" , "Moriarty, Kathleen" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 20:45:22 -0000 --001a11c1fffe03fa5604dd7cdcad Content-Type: multipart/alternative; boundary=001a11c1fffe03fa5304dd7cdcac --001a11c1fffe03fa5304dd7cdcac Content-Type: text/plain; charset=ISO-8859-1 Had a busy week, and I'm just catching up on this thread... I can't claim to have a comprehensive grasp of all the issues around formulating the WG charter(s), but to Dave's previous point concerning the architectural connection between MILE and SACM.... would it be helpful to provide an illustrative use case of, say, SACM and MILE using ROLIE as a way to traverse from an incident or indicator report, to a corresponding benchmark? Is that the sort of thing that would be helpful? If so, I can pull together some words/example showing that use case. Let me know if that would be useful. Thanks, John On Fri, May 24, 2013 at 3:59 PM, Waltermire, David A. < david.waltermire@nist.gov> wrote: > I couldn't agree more that the "plumbing" provided by SACM is useful in a > variety of contexts, including but not limited to incident handling. From > reading Sean's comments, my interpretation was that he was looking for more > specifics about how MILE and SACM support each other from an architectural > perspective. While Kathleen's text is well written and speaks from a > high-level about the synergy between the two efforts, it doesn't speak to > how technologically the two efforts are related. I believe a few specific > examples would help to clarify the relationship between the two efforts. > > Sincerely, > Dave > > > -----Original Message----- > > From: Adam W. Montville [mailto:adam@stoicsecurity.com] > > Sent: Thursday, May 23, 2013 11:36 AM > > To: Waltermire, David A. > > Cc: Moriarty, Kathleen; Romascanu, Dan (Dan); sacm@ietf.org > > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols > > > > Is this really needed? The mechanisms in SACM will be able to collect > state > > information from an identified asset or class of assets. Maybe it's > obvious to > > me that the capability to collect asset state information could be used > for a > > broader set of use cases than those defined in SACM (i.e. to support > > indicator information gathering). > > > > Given that abstract view, we could then simply state that any capability > > having a need to harvest state information from a given asset could > benefit > > from using SACM formats/message exchanges and that this goes both ways. > > > > > > On May 23, 2013, at 7:58 AM, "Waltermire, David A." > > wrote: > > > > > I think we need to include text that speaks to using SACM to collect > > indicator information in support of MILE/IODEF exchanges. We should also > > discuss the opposite side of the coin, using SACM as a way to check if > some > > indicators (e.g. file hashes) are present on existing endpoints based on > > information received by an organizations RID service. IMHO, these are > the > > killer applications for the combo in the near future. > > > > > > Sincerely, > > > Dave > > > > > >> -----Original Message----- > > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > >> Of Moriarty, Kathleen > > >> Sent: Thursday, May 23, 2013 8:02 AM > > >> To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org > > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > > >> Protocols > > >> > > >> Hi, > > >> > > >> Adam's suggestions look good to me. I'll help on the complementary > > >> aspects of MILE formats and protocols. I'll try to shorten this > > >> description or others can chime in: > > >> > > >> The MILE data formats provide a format to describe incident and > > >> threat related incident and indicator information. SACM data formats > > >> provide ways to understand what assets are in your environment, do > > >> they meet policy requirements, and to understand the current > > >> configuration state. The data exchanged in MILE, supplements the > > >> SACM data, to create situational awareness to better understand > > >> current threats and mitigation measures to those prioritized threats. > > >> The combined data sets become a powerful tool to automate security > > >> with descriptions of assets and known vulnerabilities to those assets > and > > configurations with an understanding of layered defenses. > > >> Then injecting known threat information with mitigation options > > >> assists the organization in turing detailed security decisions into > business > > level 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 mo dels 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. > > >> > > >> > > >> > > >> > > >> Thank you, > > >> Kathleen > > >> ________________________________________ > > >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of > > >> Romascanu, Dan (Dan) [dromasca@avaya.com] > > >> Sent: Thursday, May 23, 2013 7:02 AM > > >> To: Adam W. Montville; sacm@ietf.org > > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > > >> Protocols > > >> > > >> Hi, > > >> > > >> Any comments, questions, concerns about Adam's proposal? > > >> > > >> Just to remind - this was one of the clarification requests made by > Sean (' > > >> explain what is entailed in the assessment of endpoint posture and > > >> why we need repository protocols.') > > >> > > >> The second set of clarifications asked by Sean were about the > > >> relation with other work in the IETF > > >> > > >>> spt: Here's where I'd like some discussion about the NEA-based > > >>> protocols and how they can and can't be used, whether they are "the" > > >>> protocols and if not why not. > > >>> > > >>> NEA-based protocols provide ... but we're doing ... > > >>> > > >>> spt: I'd also like to give some lip service to the MILE-based > > >>> protocols and how they'll fit in. Even if it's that's for a later > > >>> stage I'd argue we need to include it now so that it's clear we're > > >>> not trying to overlap. > > >>> > > >>> MILE-based/like protocols/formats provide ... and will fit in > > >>> the overall SACM architecture ... > > >>> > > >>> spt: Is there anything we can say about the existing management > > >>> protocols such as SNMP/NETCONF? > > >>> > > >> > > >> We need to answer these two issues. I am surprised with the lack of > > >> activity on the list. We will soon be losing any window of > > >> opportunity to charter the WG before Berlin. And we cannot ask for > > another BOF, we already had two! > > >> > > >> Regards, > > >> > > >> Dan > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > > Behalf > > >>> Of Adam W. Montville > > >>> Sent: Monday, May 20, 2013 7:46 PM > > >>> To: sacm@ietf.org > > >>> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > >>> > > >>> In response to Dan's request for something we can throw against the > > >>> wall... > > >>> > > >>> Assessment of endpoint posture assessment entails... > > >>> the following general steps: > > >>> > > >>> 1. Identify and classify the asset to assess 2. Identify and/or > > >>> retrieve configuration checks specific to the asset and enterprise > > >>> policy. A configuration check consists of the particular element to > > >>> examine and the expected value of that element 3. Harvest the actual > > >>> values of configuration elements as specified in the content > > >>> identified and/or retrieved in step 2. > > >>> 4. Compare the actual values of configuration elements against > > >>> expected values > > >>> > > >>> After this point, decisions can be made based on the "pass/fail" > > >>> state of the configuration checks that have been made. > > >>> > > >>> > > >>> 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. > > >>> > > >>> > > >>> Hopefully this stokes some conversation on the list. > > >>> > > >>> Adam > > >>> > > >>> _______________________________________________ > > >>> 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 > > _______________________________________________ > 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 * --001a11c1fffe03fa5304dd7cdcac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Had a busy week, and I'm just catching up on this thre= ad...

I can't claim to have a comprehensive grasp of= all the issues around formulating the WG charter(s), but to Dave's pre= vious point concerning the architectural connection between MILE and SACM..= .. would it be helpful to provide an illustrative use case of, say, SACM an= d MILE using ROLIE as a way to traverse from an incident or indicator repor= t, to a corresponding benchmark? =A0Is that the sort of thing that would be= helpful? If so, I can pull together some words/example showing that use ca= se.

Let me know if that would be useful.

Thanks,
John


On Fri, May 24, 2013 at 3:59 PM, Wa= ltermire, David A. <david.waltermire@nist.gov> wrote= :
I couldn't agree more that the "plu= mbing" provided by SACM is useful in a variety of contexts, including = but not limited to incident handling. From reading Sean's comments, my = interpretation was that he was looking for more specifics about how MILE an= d SACM support each other from an architectural perspective. =A0While Kathl= een's text is well written and speaks from a high-level about the syner= gy between the two efforts, it doesn't speak to how technologically the= two efforts are related. I believe a few specific examples would help to c= larify the relationship between the two efforts.

Sincerely,
Dave

> -----Original Message-----
> From: Adam W. Montville [mailto:adam@stoicsecurity.com]
> Sent: Thursday, May 23, 2013 11:36 AM > To: Waltermire, David A.
> Cc: Moriarty, Kathleen; = Romascanu, Dan (Dan); sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protoco= ls
>
> Is this really needed? =A0The mechanisms in SACM will be able to colle= ct state
> information from an identified asset or class of assets. =A0Maybe it&#= 39;s obvious to
> me that the capability to collect asset state information could be use= d for a
> broader set of use cases than those defined in SACM (i.e. to support > indicator information gathering).
>
> Given that abstract view, we could then simply state that any capabili= ty
> having a need to harvest state information from a given asset could be= nefit
> from using SACM formats/message exchanges and that this goes both ways= .
>
>
> On May 23, 2013, at 7:58 AM, "Waltermire, David A."
> <david.waltermire@nist= .gov> wrote:
>
> > I think we need to include text that speaks to using SACM to coll= ect
> indicator information in support of MILE/IODEF exchanges. We should al= so
> discuss the opposite side of the coin, using SACM as a way to check if= some
> indicators (e.g. file hashes) are present on existing endpoints based = on
> information received by an organizations RID service. =A0IMHO, these a= re the
> killer applications for the combo in the near future.
> >
> > Sincerely,
> > Dave
> >
> >> -----Original Message-----
> >> From: sacm-bounces@i= etf.org [mailto:sacm-bounces@i= etf.org] On Behalf
> >> Of Moriarty, Kathleen
> >> Sent: Thursday, May 23, 2013 8:02 AM
> >> To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org
> >> Subject: Re: [sacm] Endpoint Posture Assessment and Repositor= y
> >> Protocols
> >>
> >> Hi,
> >>
> >> Adam's suggestions look good to me. =A0I'll help on t= he complementary
> >> aspects of MILE formats and protocols. I'll try to shorte= n this
> >> description or others can chime in:
> >>
> >> The MILE data formats provide a format to describe incident a= nd
> >> threat related incident and indicator information. =A0SACM da= ta formats
> >> provide ways to understand what assets are in your environmen= t, do
> >> they meet policy requirements, and to understand the current<= br> > >> configuration state. =A0The data exchanged in MILE, supplemen= ts the
> >> SACM data, to create situational awareness to better understa= nd
> >> current threats and mitigation measures to those prioritized = threats.
> >> The combined data sets become a powerful tool to automate sec= urity
> >> with descriptions of assets and known vulnerabilities to thos= e assets and
> configurations with an understanding of layered defenses.
> >> Then injecting known threat information with mitigation optio= ns
> >> assists the organization in turing detailed security decision= s into business
> level decisions.
> >> The MILE protocols, RID and ROLIE, enable the exchange of str= uctured
> >> data and are designed to carry any structured format. =A0Whil= e RID may
> >> be used in multiple sharing mo =A0dels and provides multiple<= br> > >> communication flows (report, query, etc.) with the ability to= enable
> >> peer-to-peer object level security, ROLIE provides a RESTful<= br> > >> repository transport option with only the need for a browser = on the client
> end, removing deployment barriers.
> >>
> >>
> >>
> >>
> >> Thank you,
> >> Kathleen
> >> ________________________________________
> >> From: sacm-bounces@i= etf.org [sacm-bounces@ietf.org= ] On Behalf Of
> >> Romascanu, Dan (Dan) [d= romasca@avaya.com]
> >> Sent: Thursday, May 23, 2013 7:02 AM
> >> To: Adam W. Montville; sacm@= ietf.org
> >> Subject: Re: [sacm] Endpoint Posture Assessment and Repositor= y
> >> Protocols
> >>
> >> Hi,
> >>
> >> Any comments, questions, concerns about Adam's proposal?<= br> > >>
> >> Just to remind - this was one of the clarification requests m= ade by Sean ('
> >> explain what is entailed in the assessment of endpoint postur= e and
> >> why we need repository protocols.')
> >>
> >> The second set of clarifications asked by Sean were about the=
> >> relation with other work in the IETF
> >>
> >>> spt: Here's where I'd like some discussion about = the NEA-based
> >>> protocols and how they can and can't be used, whether= they are "the"
> >>> protocols and if not why not.
> >>>
> >>> =A0 NEA-based protocols provide ... but we're doing .= ..
> >>>
> >>> spt: I'd also like to give some lip service to the MI= LE-based
> >>> protocols and how they'll fit in. =A0Even if it's= that's for a later
> >>> stage I'd argue we need to include it now so that it&= #39;s clear we're
> >>> not trying to overlap.
> >>>
> >>> =A0 MILE-based/like protocols/formats provide ... and wil= l fit in
> >>> =A0 the overall SACM architecture ...
> >>>
> >>> spt: Is there anything we can say about the existing mana= gement
> >>> protocols such as SNMP/NETCONF?
> >>>
> >>
> >> We need to answer these two issues. I am surprised with the l= ack of
> >> activity on the list. We will soon be losing any window of > >> opportunity to charter the WG before Berlin. And we cannot as= k for
> another BOF, we already had two!
> >>
> >> Regards,
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: sacm-bounc= es@ietf.org [mailto:sacm-bounc= es@ietf.org] On
> Behalf
> >>> Of Adam W. Montville
> >>> Sent: Monday, May 20, 2013 7:46 PM
> >>> To: sacm@ietf.org > >>> Subject: [sacm] Endpoint Posture Assessment and Repositor= y Protocols
> >>>
> >>> In response to Dan's request for something we can thr= ow against the
> >>> wall...
> >>>
> >>> Assessment of endpoint posture assessment entails...
> >>> the following general steps:
> >>>
> >>> 1. Identify and classify the asset to assess 2. Identify = and/or
> >>> retrieve configuration checks specific to the asset and e= nterprise
> >>> policy. =A0A configuration check consists of the particul= ar element to
> >>> examine and the expected value of that element 3. Harvest= the actual
> >>> values of configuration elements as specified in the cont= ent
> >>> identified and/or retrieved in step 2.
> >>> 4. Compare the actual values of configuration elements ag= ainst
> >>> expected values
> >>>
> >>> After this point, decisions can be made based on the &quo= t;pass/fail"
> >>> state of the configuration checks that have been made. > >>>
> >>>
> >>> Repository protocols are needed to...
> >>> store, update, and retrieve configuration checks and othe= r types of
> >>> content required for posture assessment (see step 2 above= ). =A0A
> >>> content repository is expected to house specific versions= of checklists
> (i.e.
> >>> benchmarks) may be required to satisfy different use case= s (i.e. a
> >>> NEA- specific use vs. a generally applicable assessment u= sed during
> >>> continuous monitoring). =A0In addition, content repositor= ies are
> >>> expected to store up-to-date dictionary of specific enume= rations,
> >>> such as those used for configuration element identifiers,= asset
> >>> classifications, vulnerability identifiers, and so on. > >>>
> >>>
> >>> Hopefully this stokes some conversation on the list.
> >>>
> >>> Adam
> >>>
> >>> _______________________________________________
> >>> 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

_______________________________________________
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
--001a11c1fffe03fa5304dd7cdcac-- --001a11c1fffe03fa5604dd7cdcad 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== --001a11c1fffe03fa5604dd7cdcad-- From david.waltermire@nist.gov Fri May 24 14:04: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 6A19321F9310 for ; Fri, 24 May 2013 14:04:45 -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, 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 m0pYXczNJQg9 for ; Fri, 24 May 2013 14:04:40 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id F113D21F930A for ; Fri, 24 May 2013 14:04:39 -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; Fri, 24 May 2013 17:04:41 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 24 May 2013 17:04:37 -0400 From: "Waltermire, David A." To: "sacm@ietf.org" Date: Fri, 24 May 2013 17:04:37 -0400 Thread-Topic: New Info Page Thread-Index: Ac5Ywfr4pvT6o6HoSQ6csTBa+lFGMw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930C03B26088MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sacm] New Info Page X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 21:04:45 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930C03B26088MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" It looks like we have a new WG info page for SACM indicating that we are in BOF status. http://datatracker.ietf.org/wg/sacm/charter/ It also looks like our charter draft is in datatracker. Cool. Does this mean we can use datatracker to update draft revisions of the charter? That would be very useful to help people follow along. Have a great weekend everyone! Dave --_000_D7A0423E5E193F40BE6E94126930C4930C03B26088MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1j b21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5 IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9u MT48cCBjbGFzcz1Nc29Ob3JtYWw+SXQgbG9va3MgbGlrZSB3ZSBoYXZlIGEgbmV3IFdHIGluZm8g cGFnZSBmb3IgU0FDTSBpbmRpY2F0aW5nIHRoYXQgd2UgYXJlIGluIEJPRiBzdGF0dXMuIDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NhY20v Y2hhcnRlci8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zYWNtL2NoYXJ0ZXIvPC9h PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+SXQgYWxzbyBsb29rcyBsaWtlIG91ciBjaGFydGVyIGRyYWZ0IGlz IGluIGRhdGF0cmFja2VyLiZuYnNwOyBDb29sLiZuYnNwOyBEb2VzIHRoaXMgbWVhbiB3ZSBjYW4g dXNlIGRhdGF0cmFja2VyIHRvIHVwZGF0ZSBkcmFmdCByZXZpc2lvbnMgb2YgdGhlIGNoYXJ0ZXI/ Jm5ic3A7IFRoYXQgd291bGQgYmUgdmVyeSB1c2VmdWwgdG8gaGVscCBwZW9wbGUgZm9sbG93IGFs b25nLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+SGF2ZSBhIGdyZWF0IHdlZWtlbmQgZXZlcnlvbmUhPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkRhdmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_D7A0423E5E193F40BE6E94126930C4930C03B26088MBCLUSTERxcha_-- From adam@stoicsecurity.com Fri May 24 14:08: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 E8A5F21F91B2 for ; Fri, 24 May 2013 14:08:58 -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 jDgQDbDe1Vr4 for ; Fri, 24 May 2013 14:08:54 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) by ietfa.amsl.com (Postfix) with ESMTP id 17A4421F85DC for ; Fri, 24 May 2013 14:08:54 -0700 (PDT) Received: from [172.17.4.111] ([174.47.84.222]) by p3plsmtpa06-09.prod.phx3.secureserver.net with id fx8s1l0024nonZ201x8teY; Fri, 24 May 2013 14:08:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Adam W. Montville" In-Reply-To: Date: Fri, 24 May 2013 14:08:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <08AD5360-2198-45AC-A672-3FDB16797A99@stoicsecurity.com> References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1503) Cc: "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 21:08:59 -0000 David, this seems reasonable. I have no objection to "endpoint" as a = term here, and the steps look good. Again, for a charter, I'm not sure = that we need to go far beyond this level of detail, if at all. Adam On May 24, 2013, at 1:53 PM, "Waltermire, David A." = wrote: > How about this? >=20 > Endpoint Posture Assessment involves four distinct but related = activities: 1) identification of the policies that need to be evaluated, = 2) retrieval of policy content, 3) retrieval of existing or collection = of current endpoint posture data that is relevant to the policies, and = 4) evaluation of policies based on available endpoint posture data. The = policies to be evaluated are identified and retrieved based on the = evaluation context (e.g., compliance reporting, access control decision, = indicator gathering). Endpoint posture is gathered from existing stores = of data and/or by directly collecting posture data from the endpoint as = needed. Policies are then evaluated based on available data supporting = human- and machine-oriented decision making as appropriate to the = evaluation context. >=20 > Endpoint posture is collected using the following method: >=20 > 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 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. >=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 > Some points may need additional clarification. Thoughts? >=20 > Dave >=20 >> -----Original Message----- >> From: Adam W. Montville [mailto:adam@stoicsecurity.com] >> Sent: Thursday, May 23, 2013 12:12 PM >> To: Waltermire, David A. >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository = Protocols >>=20 >> To re-write the requirements taking the feedback David has provided. = I have >> to say that this feels much clunkier and less clear to me than it did = before. >> Perhaps because I would prefer to see the steps presented in an = "ideal case" >> or "exemplary case" scenario. Rewriting based on the available = feedback >> seems more like writing a spec than a charter. >>=20 >> To address the "content" issue, I've removed the term. >>=20 >> Hopefully, this is going down the right path. >>=20 >> Step 1: >> [UNCHANGED] Identify and classify the asset to assess >>=20 >> Step 2: >> [NEW] >> Identify and/or retrieve configuration checks specific to the asset = and >> enterprise policy. A configuration check consists of the particular = element, or >> configuration item, and the expected value of that element. In some = cases, >> the element may be an identified asset class, such as software, in = which case >> the expected value may be "installed" or "not installed." >=20 > Why is the expected value relevant here if the goal is to collect the = current state? >=20 >>=20 >> [OLD] >> Identify and/or retrieve configuration checks specific to the asset = and >> enterprise policy. A configuration check consists of the particular = element to >> examine and the expected value of that element >>=20 >> Step 3: >> [NEW] >> Harvest the actual values of configuration elements as specified in = the >> expression identified and/or retrieved in step 2. At times, assets = may self- >> report their configuration without a request for such reporting. >>=20 >> [OLD] Harvest the actual values of configuration elements as = specified in the >> content identified and/or retrieved in step 2. >>=20 >> Step 4: >> [NEW] >> Compare the actual values of configuration elements against = decision-making >> criteria. Examples of such criteria might be "pass/fail," = "installed/not >> installed," or something else. >>=20 >> [OLD] >> Compare the actual values of configuration elements against expected >> values >>=20 >>=20 >>=20 >>=20 >> On May 23, 2013, at 8:32 AM, "Adam W. Montville" >> wrote: >>=20 >>>=20 >>> On May 23, 2013, at 7:53 AM, "Waltermire, David A." >> wrote: >>>=20 >>>> Adam, this is a great start! A few points of feedback: >>>>=20 >>>> 1) It is not clear if retrieving the asset's (endpoint's) software = inventory is >> included in this description. It should be. If this is considered to = be >> configuration state then it is, but this should be made more clear. >>>=20 >>> It is. The composite nature of "asset" is such that one asset can = be installed >> on another and then becomes part of the "host" asset's configuration. = We >> can certainly update the language to make this clearer. >>>=20 >>>=20 >>>> 2) There is no mention of method for the endpoint to self-publish = its >> configuration state without the use of a checking language per se = (e.g., >> SNMP, NETConf/YANG). I think we need a layered approach that enables >> state values to be reported regardless of the technical mechanism = used and >> underlying checking mechanisms to be used to describe specific = checking >> languages and results if needed or used. >>>=20 >>> To me, this is leaning toward a "how" things are going to be done = rather >> than a description of what assessment means. But, we can certainly = update >> the language to reflect something like this. This can be done by = simply >> changing "retrieve" to "retrieve/receive" in the sentence in question = (I >> think). >>>=20 >>>=20 >>>> 3) Use of content in data collection should be an optional thing. = If content >> is needed to support underlying data collection, then it should be = referenced >> and retrieved. If the data collection engine is expressing state = values using >> SWID, SNMP, or YANG, then content retrieval might not be needed. >>>=20 >>> I used the term "content" to represent the machine readable = expression of >> assessment criteria. Content is, in that light, always required = (even in the >> self-reporting case the configuration information needs to be = formatted in >> some way). This is a point where we should probably become clearer = on >> terminology. >>>=20 >>>> 4) Decisions may be made based on pass/fail evaluations or based on = the >> actual state values that are collected. Either approach should be = allowed. >>>=20 >>> I'm not sure I understand the point that's being made here. If I'm = making a >> decision based on actual state values, I've passed some judgement on = that >> value which either meets my criteria or does not meet my criteria. >>>=20 >>>>=20 >>>> Thoughts? >>>>=20 >>>> Sincerely, >>>> Dave >>>>=20 >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf >>>>> Of Adam W. Montville >>>>> Sent: Monday, May 20, 2013 12:46 PM >>>>> To: sacm@ietf.org >>>>> Subject: [sacm] Endpoint Posture Assessment and Repository = Protocols >>>>>=20 >>>>> In response to Dan's request for something we can throw against = the >> wall... >>>>>=20 >>>>> Assessment of endpoint posture assessment entails... >>>>> the following general steps: >>>>>=20 >>>>> 1. Identify and classify the asset to assess 2. Identify and/or >>>>> retrieve configuration checks specific to the asset and enterprise >>>>> policy. A configuration check consists of the particular element = to >>>>> examine and the expected value of that element 3. Harvest the = actual >>>>> values of configuration elements as specified in the content = identified >> and/or retrieved in step 2. >>>>> 4. Compare the actual values of configuration elements against >>>>> expected values >>>>>=20 >>>>> After this point, decisions can be made based on the "pass/fail" >>>>> state of the configuration checks that have been made. >>>>>=20 >>>>>=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 >>>>>=20 >>>>> Hopefully this stokes some conversation on the list. >>>>>=20 >>>>> Adam >>>>>=20 >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>=20 >>> _______________________________________________ >>> 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 From adam@stoicsecurity.com Fri May 24 14:11:49 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 18FBE11E80F6 for ; Fri, 24 May 2013 14:11:49 -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 6BBwSOkn0kQw for ; Fri, 24 May 2013 14:11:44 -0700 (PDT) Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) by ietfa.amsl.com (Postfix) with ESMTP id 971B411E80AD for ; Fri, 24 May 2013 14:11:44 -0700 (PDT) Received: from [172.17.4.111] ([174.47.84.222]) by p3plsmtpa09-09.prod.phx3.secureserver.net with id fxBh1l00d4nonZ201xBiUG; Fri, 24 May 2013 14:11:43 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Adam W. Montville" In-Reply-To: Date: Fri, 24 May 2013 14:11:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F2858D9-91E8-457B-8C8A-E8CBF46C8547@stoicsecurity.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> To: John Field X-Mailer: Apple Mail (2.1503) Cc: "Romascanu, Dan \(Dan\)" , "turners@ieca.com" , "Moriarty, Kathleen" , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 24 May 2013 21:11:49 -0000 I'm not opposed to putting some architecturally related information in = the charter, but I would not want to see the charter bloated with = information that would otherwise be explained in the October 2013 and = November 2013 milestones (initial submissions of SACM Architecture and = an overview of related standards work, respectively). John, I don't think anyone would object to your pulling some words = together and sharing with the group. That may well help determine where = that information would belong. Hope you all have a good weekend (Memorial Day for the USA-based folks = on the list). Adam On May 24, 2013, at 1:44 PM, John Field wrote: > Had a busy week, and I'm just catching up on this thread... >=20 > I can't claim to have a comprehensive grasp of all the issues around = formulating the WG charter(s), but to Dave's previous point concerning = the architectural connection between MILE and SACM.... would it be = helpful to provide an illustrative use case of, say, SACM and MILE using = ROLIE as a way to traverse from an incident or indicator report, to a = corresponding benchmark? Is that the sort of thing that would be = helpful? If so, I can pull together some words/example showing that use = case. >=20 > Let me know if that would be useful. >=20 > Thanks, > John >=20 >=20 > On Fri, May 24, 2013 at 3:59 PM, Waltermire, David A. = wrote: > I couldn't agree more that the "plumbing" provided by SACM is useful = in a variety of contexts, including but not limited to incident = handling. =46rom reading Sean's comments, my interpretation was that he = was looking for more specifics about how MILE and SACM support each = other from an architectural perspective. While Kathleen's text is well = written and speaks from a high-level about the synergy between the two = efforts, it doesn't speak to how technologically the two efforts are = related. I believe a few specific examples would help to clarify the = relationship between the two efforts. >=20 > Sincerely, > Dave >=20 > > -----Original Message----- > > From: Adam W. Montville [mailto:adam@stoicsecurity.com] > > Sent: Thursday, May 23, 2013 11:36 AM > > To: Waltermire, David A. > > Cc: Moriarty, Kathleen; Romascanu, Dan (Dan); sacm@ietf.org > > Subject: Re: [sacm] Endpoint Posture Assessment and Repository = Protocols > > > > Is this really needed? The mechanisms in SACM will be able to = collect state > > information from an identified asset or class of assets. Maybe it's = obvious to > > me that the capability to collect asset state information could be = used for a > > broader set of use cases than those defined in SACM (i.e. to support > > indicator information gathering). > > > > Given that abstract view, we could then simply state that any = capability > > having a need to harvest state information from a given asset could = benefit > > from using SACM formats/message exchanges and that this goes both = ways. > > > > > > On May 23, 2013, at 7:58 AM, "Waltermire, David A." > > wrote: > > > > > I think we need to include text that speaks to using SACM to = collect > > indicator information in support of MILE/IODEF exchanges. We should = also > > discuss the opposite side of the coin, using SACM as a way to check = if some > > indicators (e.g. file hashes) are present on existing endpoints = based on > > information received by an organizations RID service. IMHO, these = are the > > killer applications for the combo in the near future. > > > > > > Sincerely, > > > Dave > > > > > >> -----Original Message----- > > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On = Behalf > > >> Of Moriarty, Kathleen > > >> Sent: Thursday, May 23, 2013 8:02 AM > > >> To: Romascanu, Dan (Dan); Adam W. Montville; sacm@ietf.org > > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > > >> Protocols > > >> > > >> Hi, > > >> > > >> Adam's suggestions look good to me. I'll help on the = complementary > > >> aspects of MILE formats and protocols. I'll try to shorten this > > >> description or others can chime in: > > >> > > >> The MILE data formats provide a format to describe incident and > > >> threat related incident and indicator information. SACM data = formats > > >> provide ways to understand what assets are in your environment, = do > > >> they meet policy requirements, and to understand the current > > >> configuration state. The data exchanged in MILE, supplements the > > >> SACM data, to create situational awareness to better understand > > >> current threats and mitigation measures to those prioritized = threats. > > >> The combined data sets become a powerful tool to automate = security > > >> with descriptions of assets and known vulnerabilities to those = assets and > > configurations with an understanding of layered defenses. > > >> Then injecting known threat information with mitigation options > > >> assists the organization in turing detailed security decisions = into business > > level 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 mo dels 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. > > >> > > >> > > >> > > >> > > >> Thank you, > > >> Kathleen > > >> ________________________________________ > > >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of > > >> Romascanu, Dan (Dan) [dromasca@avaya.com] > > >> Sent: Thursday, May 23, 2013 7:02 AM > > >> To: Adam W. Montville; sacm@ietf.org > > >> Subject: Re: [sacm] Endpoint Posture Assessment and Repository > > >> Protocols > > >> > > >> Hi, > > >> > > >> Any comments, questions, concerns about Adam's proposal? > > >> > > >> Just to remind - this was one of the clarification requests made = by Sean (' > > >> explain what is entailed in the assessment of endpoint posture = and > > >> why we need repository protocols.') > > >> > > >> The second set of clarifications asked by Sean were about the > > >> relation with other work in the IETF > > >> > > >>> spt: Here's where I'd like some discussion about the NEA-based > > >>> protocols and how they can and can't be used, whether they are = "the" > > >>> protocols and if not why not. > > >>> > > >>> NEA-based protocols provide ... but we're doing ... > > >>> > > >>> spt: I'd also like to give some lip service to the MILE-based > > >>> protocols and how they'll fit in. Even if it's that's for a = later > > >>> stage I'd argue we need to include it now so that it's clear = we're > > >>> not trying to overlap. > > >>> > > >>> MILE-based/like protocols/formats provide ... and will fit in > > >>> the overall SACM architecture ... > > >>> > > >>> spt: Is there anything we can say about the existing management > > >>> protocols such as SNMP/NETCONF? > > >>> > > >> > > >> We need to answer these two issues. I am surprised with the lack = of > > >> activity on the list. We will soon be losing any window of > > >> opportunity to charter the WG before Berlin. And we cannot ask = for > > another BOF, we already had two! > > >> > > >> Regards, > > >> > > >> Dan > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > > Behalf > > >>> Of Adam W. Montville > > >>> Sent: Monday, May 20, 2013 7:46 PM > > >>> To: sacm@ietf.org > > >>> Subject: [sacm] Endpoint Posture Assessment and Repository = Protocols > > >>> > > >>> In response to Dan's request for something we can throw against = the > > >>> wall... > > >>> > > >>> Assessment of endpoint posture assessment entails... > > >>> the following general steps: > > >>> > > >>> 1. Identify and classify the asset to assess 2. Identify and/or > > >>> retrieve configuration checks specific to the asset and = enterprise > > >>> policy. A configuration check consists of the particular = element to > > >>> examine and the expected value of that element 3. Harvest the = actual > > >>> values of configuration elements as specified in the content > > >>> identified and/or retrieved in step 2. > > >>> 4. Compare the actual values of configuration elements against > > >>> expected values > > >>> > > >>> After this point, decisions can be made based on the "pass/fail" > > >>> state of the configuration checks that have been made. > > >>> > > >>> > > >>> 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. > > >>> > > >>> > > >>> Hopefully this stokes some conversation on the list. > > >>> > > >>> Adam > > >>> > > >>> _______________________________________________ > > >>> 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 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 >=20 >=20 > --=20 > John P. Field | Security Architect | Pivotal >=20 > Direct: (908) 962-3394 | jfield@gopivotal.com=20 >=20 > >=20 > goPivotal.com > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From ietfdbh@comcast.net Sat May 25 09:37: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 D439B21F88FB for ; Sat, 25 May 2013 09:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 INlXb2L6KGIN for ; Sat, 25 May 2013 09:36:56 -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 F39BB21F88D8 for ; Sat, 25 May 2013 09:36:55 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id gFkn1l0011vXlb85CGcv8b; Sat, 25 May 2013 16:36:55 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta17.westchester.pa.mail.comcast.net with comcast id gGcu1l0092yZEBF3dGcutM; Sat, 25 May 2013 16:36:55 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , , "'Sean Turner'" References: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> <003101ce57ad$cccabb00$66603100$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA175881@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA175881@AZ-FFEXMB04.global.avaya.com> Date: Sat, 25 May 2013 12:36:39 -0400 Message-ID: <004001ce5966$0842b9d0$18c82d70$@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: AQJxxrpVuw5MGxTKHsQshcafRNQt+AGoDk2QAg5cEgwCePUgKZeaYO0Q Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369499815; bh=vorTuvFG2OIZYA8GHHzqY3JJVaraTcu2cxAbUdUt7yM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=fIxDb76rkKsB4RnTDyN4vunnTvUDlUbf86wjv6Nfa+VipzVKAhAihnO357FfUGuwN Rdry/zOmVpZLElU/QHc/77LMIWF7GWrlDOxRfjPED7Y64As/i1upqm1u8jW6LZAzhs 0PTksbJot+citRl9BqzY+lxhtqPE7lPEIsMXG222Uhsy9Finpq8PsDjY36QelXHI0V I9keA+E6Cu+HLqHwSNMKE0IP73ZnuOh9PkG0s+onBdETUnaq/zkpaw3nNSrjkoPyRg kreag4rnO4VdiN1t08e6F18QuiJDPZl9mDg+7gEQdgX7nUaYiOcULRN5XQS7cnUqgC r8ncxo+8SDaXg== Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 16:37:01 -0000 Hi, I have a few comments regarding the charter proposed in http://www.ietf.org/mail-archive/web/sacm/current/msg01080.html. 1) "The working group will, whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management." The IETF doesn't currently have much in the way of "security automation specifications"; that's why we're starting sacm. I think our interest would be better worded as " 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." 2) "There are multiple categories of problems in the security automation realm:" This feels like it is saying the listed problems are specific to security automation. They are not. " enabling interoperable data exchanges through standardized protocols, defining expressions for particular domain concepts (i.e. data formats), establishing a standards-based foundation supporting the [...] exchange of [...] content collections in content repositories, and enabling interoperability through the development and use of standard interfaces and communication protocols. Content based on rich and extensible data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection of configuration and [state] data pertaining to enterprise assets. Information produced by these tools will provide accurate and timely situational awareness in support of organizational decision making. " These "problems" are common to all network management, not just security management. These describe the same problems addressed by SNMP, IPFIX, NETCONF, SYSLOG, NEA, MILE, and others. " - A standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis" Operators are likely to not want a whole new management infrastructure just for security management. We shouldn't try to reinvent solutions to these generic problems; we already have multiple protocols capable of retrieving configuration and policy information for driving data collection and analysis. We should focus on security automation problems. We could use an overall information model [rfc3444] to identify those security aspects that CAN be standardized. We should provide advice on how to use existing protocols to address known use-cases, and develop some data models related to automating security assessments/configurations using existing management protocols. If, after we figure out what CAN be standardized, and how to utilize the existing tools to execute such standardization, there are still problems that existing tools cannot address, then we should consider developing new protocols, languages, and data models. 3) I couldn't find a consistent definition for "curation" so maybe we need to better specify what this means in the sacm context. 4) we should make sure relevant content from RFC3535 (IAB workshop on management) gets considered in the requirements. 5) we should make sure the relevant content from rfc5706 gets considered in the requirements. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, May 23, 2013 8:17 AM To: ietfdbh; sacm@ietf.org; Sean Turner Subject: RE: [sacm] Endpoint Posture Assessment and Repository Protocols Hi, I will ask the secretariat to do all these. The latest charter proposal us AFAIK the one submitted in http://www.ietf.org/mail-archive/web/sacm/current/msg01080.html. Thanks and Regards, Dan > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Thursday, May 23, 2013 3:05 PM > To: Romascanu, Dan (Dan); sacm@ietf.org; Sean Turner > Subject: RE: [sacm] Endpoint Posture Assessment and Repository > Protocols > > Hi, > > It's a little bit difficult to piece together where we are on the > charter by reading the archive. > The datatracker (datatracker.ietf.org) has a link for BOFs in the left > menu, and sacm is listed on their BOFs page. > The linked-to sacm page (http://datatracker.ietf.org/wg/sacm/charter/) > is titled the charter page, but there is no charter in the title bar. > Can we put a link to the current charter proposal, a link to the > archive on this page, and subscribe guidance on this page. > This might prompt wider participation and discussion. > > If having it in the datatracker page makes it hard to update, can the > datatracker page provide a link to another website/wiki that is easier > to update, such as http://trac.tools.ietf.org/bof/trac/wiki/BofIETF86# ? > Is the charter included there the most current version? > > Thanks, > > David Harrington > ietfdbh@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: Thursday, May 23, 2013 7:03 AM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Endpoint Posture Assessment and Repository > Protocols > > Hi, > > Any comments, questions, concerns about Adam's proposal? > > Just to remind - this was one of the clarification requests made by > Sean (' > explain what is entailed in the assessment of endpoint posture and why > we need repository protocols.') > > The second set of clarifications asked by Sean were about the relation > with other work in the IETF > > > spt: Here's where I'd like some discussion about the NEA-based > > protocols and how they can and can't be used, whether they are "the" > > protocols and if not why not. > > > > NEA-based protocols provide ... but we're doing ... > > > > spt: I'd also like to give some lip service to the MILE-based > > protocols and how they'll fit in. Even if it's that's for a later > > stage I'd argue we need to include it now so that it's clear we're > > not trying to overlap. > > > > MILE-based/like protocols/formats provide ... and will fit in > > the overall SACM architecture ... > > > > spt: Is there anything we can say about the existing management > > protocols such as SNMP/NETCONF? > > > > We need to answer these two issues. I am surprised with the lack of > activity on the list. We will soon be losing any window of opportunity > to charter the WG before Berlin. And we cannot ask for another BOF, we > already had two! > > Regards, > > Dan > > > > > > > > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam W. Montville > > Sent: Monday, May 20, 2013 7:46 PM > > To: sacm@ietf.org > > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > > > In response to Dan's request for something we can throw against the > > wall... > > > > Assessment of endpoint posture assessment entails... > > the following general steps: > > > > 1. Identify and classify the asset to assess 2. Identify and/or > > retrieve configuration checks specific to the asset and enterprise > > policy. A configuration check consists of the particular element to > > examine and the expected value of that element 3. Harvest the actual > > values of configuration elements as specified in the content > > identified and/or retrieved in step 2. > > 4. Compare the actual values of configuration elements against > > expected values > > > > After this point, decisions can be made based on the "pass/fail" > > state of the configuration checks that have been made. > > > > > > 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. > > > > > > Hopefully this stokes some conversation on the list. > > > > Adam > > > > _______________________________________________ > > 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 Sun May 26 02:19:05 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 A2FCA21F8F4D for ; Sun, 26 May 2013 02:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.444 X-Spam-Level: X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 8XL6WGjVafWU for ; Sun, 26 May 2013 02:19:00 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA6821F8F4A for ; Sun, 26 May 2013 02:18:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlHGmAcF/2dsb2JhbABGBwOCZSE2wUiBBxZ0gh8BAQEBAgEBAQEPKDQEAgoHBAIBCA0EAQMBAQsCEgkHJwsUAwYIAgQBEggBEgeHYAMJBgELoDyTOQiJSxeNWgqBASEFDQUGC4JPYQOYI4UGimiDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="12923325" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 May 2013 05:18:58 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 May 2013 05:13:31 -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, 26 May 2013 11:18:56 +0200 From: "Romascanu, Dan (Dan)" To: ietfdbh , "sacm@ietf.org" , "'Sean Turner'" Thread-Topic: [sacm] Endpoint Posture Assessment and Repository Protocols Thread-Index: AQHOVXmGV5K3UMJjZk6trXLNupMjz5kSnT9g///x34CAACPZkIADsTOAgADTX+A= Date: Sun, 26 May 2013 09:18:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA177314@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1757E0@AZ-FFEXMB04.global.avaya.com> <003101ce57ad$cccabb00$66603100$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA175881@AZ-FFEXMB04.global.avaya.com> <004001ce5966$0842b9d0$18c82d70$@comcast.net> In-Reply-To: <004001ce5966$0842b9d0$18c82d70$@comcast.net> 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 Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 26 May 2013 09:19:05 -0000 Hi David, Thanks for the comments.=20 See some responses in-line.=20 Regards, Dan > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Saturday, May 25, 2013 7:37 PM > To: Romascanu, Dan (Dan); sacm@ietf.org; 'Sean Turner' > Subject: RE: [sacm] Endpoint Posture Assessment and Repository Protocols >=20 > Hi, >=20 > I have a few comments regarding the charter proposed in > http://www.ietf.org/mail-archive/web/sacm/current/msg01080.html. >=20 > 1) "The working group will, whenever reasonable and possible, reuse > existing protocols, mechanisms, information and data models. Of > particular interest to this working group are the security automation > specifications supporting asset, change, configuration, and > vulnerability management." >=20 > The IETF doesn't currently have much in the way of "security automation > specifications"; that's why we're starting sacm. >=20 > I think our interest would be better worded as " 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 [[DR]] OK.=20 > 2) "There are multiple categories of problems in the security automation > realm:" > This feels like it is saying the listed problems are specific to > security automation. They are not. >=20 > " enabling interoperable data exchanges through standardized protocols, > defining expressions for particular domain concepts (i.e. data formats), > establishing a standards-based foundation supporting the [...] exchange > of [...] content collections in content repositories, and enabling > interoperability through the development and use of standard interfaces > and communication protocols. Content based on rich and extensible data > standards and protocols will provide the authoritative instructions > needed by data-driven tools to enable the automated collection of > configuration and [state] data pertaining to enterprise assets. > Information produced by these tools will provide accurate and timely > situational awareness in support of organizational decision making. " >=20 > These "problems" are common to all network management, not just security > management. > These describe the same problems addressed by SNMP, IPFIX, NETCONF, > SYSLOG, NEA, MILE, and others. >=20 [[DR]] Yes, but this may not be clear to all participants in this effort, s= ome of them new to the IETF, and less exposed to the discussions around the= management protocols that happened during the last 10-15 years in OPS. Thi= s is why my preference is to be verbose on this issue in the charter. > " - A standards-track document specifying a protocol and data > format for retrieving configuration and policy information for > driving data collection and analysis" >=20 > Operators are likely to not want a whole new management infrastructure > just for security management. > We shouldn't try to reinvent solutions to these generic problems; we > already have multiple protocols capable of retrieving configuration and > policy information for driving data collection and analysis. > We should focus on security automation problems. > We could use an overall information model [rfc3444] to identify those > security aspects that CAN be standardized. > We should provide advice on how to use existing protocols to address > known use-cases, and develop some data models related to automating > security assessments/configurations using existing management protocols. >=20 > If, after we figure out what CAN be standardized, and how to utilize the > existing tools to execute such standardization, there are still problems > that existing tools cannot address, then we should consider developing > new protocols, languages, and data models. >=20 [[DR]] All true but specifying a protocol does not necessarily means 'speci= fying a new protocol' and we have wording about re-using or extending exist= ing solutions whenever possible.=20 > 3) I couldn't find a consistent definition for "curation" so maybe we > need to better specify what this means in the sacm context. > > 4) we should make sure relevant content from RFC3535 (IAB workshop on > management) gets considered in the requirements. >=20 [[DR]] yes, we can add a phrase that points to this, especially for the bro= ader audiences mentioned above.=20 > 5) we should make sure the relevant content from rfc5706 gets considered > in the requirements. >=20 [[DR]] same.=20 >=20 >=20 >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, May 23, 2013 8:17 AM > To: ietfdbh; sacm@ietf.org; Sean Turner > Subject: RE: [sacm] Endpoint Posture Assessment and Repository Protocols >=20 > Hi, >=20 > I will ask the secretariat to do all these. >=20 > The latest charter proposal us AFAIK the one submitted in > http://www.ietf.org/mail-archive/web/sacm/current/msg01080.html. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ietfdbh [mailto:ietfdbh@comcast.net] > > Sent: Thursday, May 23, 2013 3:05 PM > > To: Romascanu, Dan (Dan); sacm@ietf.org; Sean Turner > > Subject: RE: [sacm] Endpoint Posture Assessment and Repository > > Protocols > > > > Hi, > > > > It's a little bit difficult to piece together where we are on the > > charter by reading the archive. > > The datatracker (datatracker.ietf.org) has a link for BOFs in the left > > menu, and sacm is listed on their BOFs page. > > The linked-to sacm page (http://datatracker.ietf.org/wg/sacm/charter/) > > is titled the charter page, but there is no charter in the title bar. > > Can we put a link to the current charter proposal, a link to the > > archive on this page, and subscribe guidance on this page. > > This might prompt wider participation and discussion. > > > > If having it in the datatracker page makes it hard to update, can the > > datatracker page provide a link to another website/wiki that is easier > > to update, such as http://trac.tools.ietf.org/bof/trac/wiki/BofIETF86# > ? > > Is the charter included there the most current version? > > > > Thanks, > > > > David Harrington > > ietfdbh@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: Thursday, May 23, 2013 7:03 AM > > To: Adam W. Montville; sacm@ietf.org > > Subject: Re: [sacm] Endpoint Posture Assessment and Repository > > Protocols > > > > Hi, > > > > Any comments, questions, concerns about Adam's proposal? > > > > Just to remind - this was one of the clarification requests made by > > Sean (' > > explain what is entailed in the assessment of endpoint posture and why > > we need repository protocols.') > > > > The second set of clarifications asked by Sean were about the relation > > with other work in the IETF > > > > > spt: Here's where I'd like some discussion about the NEA-based > > > protocols and how they can and can't be used, whether they are "the" > > > protocols and if not why not. > > > > > > NEA-based protocols provide ... but we're doing ... > > > > > > spt: I'd also like to give some lip service to the MILE-based > > > protocols and how they'll fit in. Even if it's that's for a later > > > stage I'd argue we need to include it now so that it's clear we're > > > not trying to overlap. > > > > > > MILE-based/like protocols/formats provide ... and will fit in > > > the overall SACM architecture ... > > > > > > spt: Is there anything we can say about the existing management > > > protocols such as SNMP/NETCONF? > > > > > > > We need to answer these two issues. I am surprised with the lack of > > activity on the list. We will soon be losing any window of opportunity > > to charter the WG before Berlin. And we cannot ask for another BOF, we > > already had two! > > > > Regards, > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > > Of Adam W. Montville > > > Sent: Monday, May 20, 2013 7:46 PM > > > To: sacm@ietf.org > > > Subject: [sacm] Endpoint Posture Assessment and Repository Protocols > > > > > > In response to Dan's request for something we can throw against the > > > wall... > > > > > > Assessment of endpoint posture assessment entails... > > > the following general steps: > > > > > > 1. Identify and classify the asset to assess 2. Identify and/or > > > retrieve configuration checks specific to the asset and enterprise > > > policy. A configuration check consists of the particular element to > > > examine and the expected value of that element 3. Harvest the actual > > > values of configuration elements as specified in the content > > > identified and/or retrieved in step 2. > > > 4. Compare the actual values of configuration elements against > > > expected values > > > > > > After this point, decisions can be made based on the "pass/fail" > > > state of the configuration checks that have been made. > > > > > > > > > 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. > > > > > > > > > Hopefully this stokes some conversation on the list. > > > > > > Adam > > > > > > _______________________________________________ > > > 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 Sun May 26 03:31:36 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 D8E2421F8FDF for ; Sun, 26 May 2013 03:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.041 X-Spam-Level: X-Spam-Status: No, score=-103.041 tagged_above=-999 required=5 tests=[AWL=-0.443, 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 w1E98dUi3nG7 for ; Sun, 26 May 2013 03:31:31 -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 490F221F84A6 for ; Sun, 26 May 2013 03:31:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEHAEbjoVGHCzI1/2dsb2JhbABagkQjITCwEYk1iDyBBhZ0giMBAQEBAxIbXAIBCA0EBAEBCx0HMhQJCAEBBAESCBqHawELoR6bCheObDcBgnNhA5hkhRiDaIcXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,744,1363147200"; d="scan'208,217";a="13364794" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 May 2013 06:31:30 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 May 2013 06:27:16 -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; Sun, 26 May 2013 06:31:29 -0400 From: "Romascanu, Dan (Dan)" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: New Info Page Thread-Index: Ac5Ywfr4pvT6o6HoSQ6csTBa+lFGMwBOgoJA Date: Sun, 26 May 2013 10:31:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1778F3@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.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1778F3AZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [sacm] New Info Page X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 26 May 2013 10:31:37 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1778F3AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By now, if I try to use the WG tools I get an Error 404 for http://tools.ie= tf.org/wg/sacm/. I do not know if this is a bug or a feature (it's supposed= to work only for approved and active WGs). I will ask the Secretariat. Regards, Dan From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Saturday, May 25, 2013 12:05 AM To: sacm@ietf.org Subject: [sacm] New Info Page It looks like we have a new WG info page for SACM indicating that we are in= BOF status. http://datatracker.ietf.org/wg/sacm/charter/ It also looks like our charter draft is in datatracker. Cool. Does this m= ean we can use datatracker to update draft revisions of the charter? That = would be very useful to help people follow along. Have a great weekend everyone! Dave --_000_9904FB1B0159DA42B0B887B7FA8119CA1778F3AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

By now, if I try to us= e the WG tools I get an Error 404 for http://tools.ietf.org/wg/sacm/. I do not know if this is a bug or a feature (it’s supposed to wor= k only for approved and active WGs). I will ask the Secretariat.

 

Regards,

 

Dan<= /p>

 

 

 

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Saturday, May 25, 2013 12:05 AM
To: sacm@ietf.org
Subject: [sacm] New Info Page

 

It looks like we have a new WG info page for SACM in= dicating that we are in BOF status.

 

http://datatracker.ietf.org/wg/sacm/charter/

 

It also looks like our charter draft is in datatrack= er.  Cool.  Does this mean we can use datatracker to update draft= revisions of the charter?  That would be very useful to help people f= ollow along.

 

Have a great weekend everyone!

Dave

--_000_9904FB1B0159DA42B0B887B7FA8119CA1778F3AZFFEXMB04globala_-- From dromasca@avaya.com Thu May 30 03:27: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 2B05321F962A for ; Thu, 30 May 2013 03:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 JdxyZR3-rPTM for ; Thu, 30 May 2013 03:27:28 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1521F966F for ; Thu, 30 May 2013 03:27:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlHGmAcF/2dsb2JhbABQgmUhwX6BBxZ0gh8BAQEBAxIoLh0GAQgNBAQBAQsUCTkUBwEBBQUEEwgMDodyAZwchCudDBeNVIERJhiCWmEDnSmKaIMLgXM1 X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="13482651" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 May 2013 06:27:25 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 May 2013 06:21:46 -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; Thu, 30 May 2013 06:27:24 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: Nomcom 2013-14 Volunteering - 2nd Call Thread-Index: AQHOXLAohg3/5/hJhka74OTHCGTCZZkdhgpQ Date: Thu, 30 May 2013 10:27:24 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17B87A@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] FW: Nomcom 2013-14 Volunteering - 2nd Call X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List 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, 30 May 2013 10:27:29 -0000 If you are eligible for Nomcom please consider taking part in this importan= t IETF activity.=20 Thanks and Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of Mankin, Allison Sent: Thursday, May 30, 2013 12:05 AM To: ietf-announce@ietf.org Cc: Subject: Nomcom 2013-14 Volunteering - 2nd Call Hi, everyone, Remember that I'm challenging the IETF to come up with 200 volunteers for t= he upcoming nomcom. You can volunteer just by hitting Reply to this email. What are you waiting for?? The more volunteers we get, the better chance w= e have of choosing a random yet representative cross section of the IETF po= pulation. Respond to the 200-volunteer challenge and hit Reply right now.= =20 (Well, much as I want you to do this, please look below at the posts being = filled and be sure you are willing to forgo trying for any of them this yea= r). The official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. Th= e IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, a= nd the IESG. Ten voting members for the nomcom are selected in a verifiably= random way from a pool of volunteers.=20 The details of the selection and operation of the nomcom can be found in RF= Cs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified = in RFC 3777, that means three out of the five past meetings up to the time = this email announcement goes out to start the solicitation of volunteers. T= he five meetings out of which you must have attended three are IETF 82, 83,= 84, 85, 86. If you qualify, reply to this email and volunteer. =20 The list of people and posts whose terms end with the March 2014 IETF meeti= ng, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart B= ryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be = completed in January 2014. Being a nomcom member will require some time co= mmitment - there will be interviews with candidates at meetings, regularly = scheduled conference calls to ensure progress, collection and review of req= uirements from the commitment, review of candidate questionnaires and of co= mmunity feedback. A more detailed timetable for the nomcom tasks will appe= ar soon. Please respond to this email before 11:59 pm EDT (UTC -4 hours) June 16, 20= 13. In the body include:=20 1. your Given Name as you enter it when you register for the IETF 2. your= Family Name as you enter it when you register for the IETF 3. your curren= t primary affilation (the information you enter into the Company field) 4.= any/all email addresses you've used to register for IETF meetings 5. whic= h email address you prefer 6. your phone number (for our use in confirming= you if selected). You should expect an email response from me within 3 business days stating = whether or not you are qualified (and added to the list). If you don't rec= eive this response, please re-send your email adding the tag "RESEND" to th= e subject line. Participating in the IETF nomcom is a meaningful and fun way to contribute = to the IETF. =20 Please help us meet the 200-volunteer challenge by hitting Reply to this me= ssage today. =20 Allison=20 Allison Mankin Nomcom Chair 2013-2014 =20