From dromasca@avaya.com Thu Oct 3 06:00:52 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18D111E80D1 for ; Thu, 3 Oct 2013 06:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.385 X-Spam-Level: X-Spam-Status: No, score=-103.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 E7mlEEphIRwO for ; Thu, 3 Oct 2013 06:00:39 -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 709EB11E80E7 for ; Thu, 3 Oct 2013 05:58:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFALppTVLGmAcV/2dsb2JhbABZgmYhgQrBPoEgFm0HgicBAQMSKFEBFRUUQiYBBBsah2QBmzKER5xzjyCDV4EEA55diyODJIIq X-IronPort-AV: E=Sophos;i="4.90,1026,1371096000"; d="scan'208";a="30471152" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Oct 2013 08:58:10 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Oct 2013 08:54:34 -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.03.0146.000; Thu, 3 Oct 2013 14:58:05 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: IETF 88 - agenda and schedules Thread-Index: Ac7AOB/qnUV9+A0sQLiGwWPW8hzmiA== Date: Thu, 3 Oct 2013 12:58:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128F16A9@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.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] IETF 88 - agenda and schedules X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 13:00:52 -0000 Hi, IETF 88 is just one month away.=20 Please send your requests and proposals for agenda items.=20 Also please note that the 'Important Dates' file includes the following:=20 *2013-10-07 (Monday): Working Group Chair approval for initial document (Ve= rsion -00) submissions appreciated by UTC 24:00. ... *2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, in= cluding -00) by UTC 24:00, upload using IETF ID Submission Tool.=20 There is only one submission cu-off date for all I-Ds, but in case you plan= to submit a -00 draft (initial document) you need to let Adam and/or me be= fore Monday 10/7, so that we can pre-approve it.=20 Thanks and Regards, Dan From shanna@juniper.net Thu Oct 3 12:50: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 0455021E8122 for ; Thu, 3 Oct 2013 12:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IC0zvRpoPpg for ; Thu, 3 Oct 2013 12:50:07 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id D9BAB21F93BA for ; Thu, 3 Oct 2013 12:33:41 -0700 (PDT) Received: from mail103-db9-R.bigfish.com (10.174.16.248) by DB9EHSOBE001.bigfish.com (10.174.14.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 3 Oct 2013 19:33:40 +0000 Received: from mail103-db9 (localhost [127.0.0.1]) by mail103-db9-R.bigfish.com (Postfix) with ESMTP id BDCAEC00ED for ; Thu, 3 Oct 2013 19:33:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zz148cI4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail103-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(52604005)(189002)(199002)(164054003)(50986001)(47976001)(53806001)(54356001)(74366001)(74706001)(54316002)(56776001)(77982001)(51856001)(79102001)(76576001)(83322001)(46102001)(59766001)(65816001)(49866001)(47736001)(74876001)(76482001)(80022001)(76176001)(4396001)(63696002)(81686001)(31966008)(76786001)(80976001)(81342001)(33646001)(56816003)(74502001)(74662001)(74316001)(76796001)(77096001)(69226001)(81816001)(47446002)(81542001)(66066001)(83072001)(85306002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB322; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail103-db9 (localhost.localdomain [127.0.0.1]) by mail103-db9 (MessageSwitch) id 1380828818958719_16166; Thu, 3 Oct 2013 19:33:38 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.252]) by mail103-db9.bigfish.com (Postfix) with ESMTP id DC1E62A026A for ; Thu, 3 Oct 2013 19:33:38 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 3 Oct 2013 19:33:38 +0000 Received: from BLUPR05MB322.namprd05.prod.outlook.com (10.141.24.25) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 3 Oct 2013 19:33:34 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB322.namprd05.prod.outlook.com (10.141.24.25) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 3 Oct 2013 19:33:33 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.5]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.131]) with mapi id 15.00.0775.005; Thu, 3 Oct 2013 19:33:33 +0000 From: Stephen Hanna To: "sacm@ietf.org" Thread-Topic: My Comments on draft-ietf-sacm-use-cases-01.txt Thread-Index: Ac7Ab3GSKjEI/xX3QuWO4d6TzNXudw== Date: Thu, 3 Oct 2013 19:33:33 +0000 Message-ID: <472d40191a3844599aa3995a94a0cb2a@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09888BC01D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [sacm] My Comments on draft-ietf-sacm-use-cases-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:50:21 -0000 I just finished a review of the latest SACM use cases draft. Here are my comments. * I agree with Nancy that Section 4 (Functional Capabilities) does not belong in a Use Case document. We may need to add this back later but I think we should first focus on agreeing on what problems we want to solve (use cases). I suggest that we remove section 4 for now. * I definitely like the new use cases vs. the old ones in the -00 version. The new use cases are specific. I know what they mean. The old ones were too general and lengthy. I was never sure that I understood them and it seemed quite likely that two people reading them would understand them differently. Thanks for making these changes. * All the current use cases seem to be in scope for this group. * At the start of section 3.1, you ask QUESTION: This use case applies equally to vendors representing other endpoint types. Should this be generalized to capture this notion? I suggest that you keep the current text. It's good to have specific use cases that span the problem space. If you want, you can add a sentence at the end that says this use case could apply to other endpoint types just as easily. * At the end of section 3.1, you ask QUESTION: Is providing traceability to functional capabilities useful? If so, we need to replicate this for the other use cases. As I mentioned above, I don't think it's a good idea to add a list of abstract capabilities to this document. Let's agree on the problems that we want to solve. Then we can talk about which concepts to use to solve those problems. So I'd like to delete the list of capabilities at the end of section 3.1. * In section 3.2, the checklists might come from sources other than vendors. For example, the financial services company might get checklists from a financial industry group or develop its own checklists. I'm perfectly happy leaving this use case mainly as it is but adding a sentence at the end saying that the checklists could also come from sources other than the application or OS vendor. Similar text should also go at the end of section 3.1. * Here are a few more use cases: Search for Signs of Infection, Remediation & Mitigation, and Endpoint Information Analysis & Reporting. Do you want me to write a few paragraphs on those? Thanks, Steve From shanna@juniper.net Thu Oct 3 13:03:07 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2E21F8AF4 for ; Thu, 3 Oct 2013 13:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEh+iKohNMAb for ; Thu, 3 Oct 2013 13:02:47 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5F121E8107 for ; Thu, 3 Oct 2013 12:42:39 -0700 (PDT) Received: from mail135-db8-R.bigfish.com (10.174.8.234) by DB8EHSOBE013.bigfish.com (10.174.4.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 3 Oct 2013 19:42:38 +0000 Received: from mail135-db8 (localhost [127.0.0.1]) by mail135-db8-R.bigfish.com (Postfix) with ESMTP id EDAA84C01D2 for ; Thu, 3 Oct 2013 19:42:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail135-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(189002)(199002)(56816003)(74662001)(74502001)(33646001)(81686001)(31966008)(81342001)(80976001)(76786001)(47446002)(81542001)(83072001)(85306002)(66066001)(69226001)(77096001)(74316001)(76796001)(81816001)(79102001)(83322001)(76576001)(46102001)(54356001)(53806001)(74366001)(50986001)(47976001)(51856001)(74706001)(54316002)(56776001)(77982001)(76176001)(80022001)(63696002)(4396001)(65816001)(59766001)(74876001)(76482001)(47736001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB322; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail135-db8 (localhost.localdomain [127.0.0.1]) by mail135-db8 (MessageSwitch) id 138082935648950_8887; Thu, 3 Oct 2013 19:42:36 +0000 (UTC) Received: from DB8EHSMHS009.bigfish.com (unknown [10.174.8.241]) by mail135-db8.bigfish.com (Postfix) with ESMTP id 083F74A00B3 for ; Thu, 3 Oct 2013 19:42:36 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS009.bigfish.com (10.174.4.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 3 Oct 2013 19:42:34 +0000 Received: from BLUPR05MB322.namprd05.prod.outlook.com (10.141.24.25) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 3 Oct 2013 19:42:33 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB322.namprd05.prod.outlook.com (10.141.24.25) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 3 Oct 2013 19:42:33 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.5]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.131]) with mapi id 15.00.0775.005; Thu, 3 Oct 2013 19:42:32 +0000 From: Stephen Hanna To: "sacm@ietf.org" Thread-Topic: Title for SACM Use Cases Draft Thread-Index: Ac7AcLLPpnMpwtlTQT6Ha61+RvsErA== Date: Thu, 3 Oct 2013 19:42:32 +0000 Message-ID: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09888BC01D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:03:07 -0000 Dave and Nancy were talking about the title for the SACM Use Cases document. The old title was: Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases The new title is: Using Security Posture Assessment to Grant Access to Enterprise Network Res= ources I prefer the old title. The new title implies that the only purpose of this work is to "Grant Access to Enterprise Network Resources". There are many other purposes such as preparing reports on endpoint policy compliance, finding misconfigured endpoints so they can be fixed, etc. Thanks, Steve From Kent_Landfield@mcafee.com Thu Oct 3 17:42:24 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8164721E80A9 for ; Thu, 3 Oct 2013 17:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HYIKsAjselbH for ; Thu, 3 Oct 2013 17:42:13 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1545621E80A6 for ; Thu, 3 Oct 2013 17:42:01 -0700 (PDT) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 4b74_f1ab_6c450c78_982a_493b_856e_a9b69a855b85; Thu, 03 Oct 2013 19:41:55 -0500 Received: from MIVEXEMEA1N2.corp.nai.org (10.48.48.32) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Oct 2013 20:41:47 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.249]) by MIVEXEMEA1N2.corp.nai.org ([169.254.2.218]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 20:41:47 -0400 From: To: Thread-Topic: [sacm] Title for SACM Use Cases Draft Thread-Index: Ac7AcLLPpnMpwtlTQT6Ha61+RvsErAAS1SKA Date: Fri, 4 Oct 2013 00:41:47 +0000 Message-ID: <03BAA9D0-53CA-4807-8717-FCE984AE8EFE@McAfee.com> References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> In-Reply-To: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <4BBE27B9948C3E47B3FB1316755D0263@McAfee.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 00:42:24 -0000 I agree with Steve. I like the first one as the new title gives the wrong i= mpression. Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026=20 > On Oct 3, 2013, at 1:03 PM, "Stephen Hanna" wrote: >=20 > Dave and Nancy were talking about the title for > the SACM Use Cases document. The old title was: >=20 > Analysis of Security Automation and Continuous Monitoring (SACM) Use Case= s >=20 > The new title is: >=20 > Using Security Posture Assessment to Grant Access to Enterprise Network R= esources >=20 > I prefer the old title. The new title implies > that the only purpose of this work is to > "Grant Access to Enterprise Network Resources". > There are many other purposes such as preparing > reports on endpoint policy compliance, finding > misconfigured endpoints so they can be fixed, etc. >=20 > Thanks, >=20 > Steve >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Erik.Cockrell@polycom.com Fri Oct 4 09:14:46 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DA121F9A90 for ; Fri, 4 Oct 2013 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIUkO9tBolK1 for ; Fri, 4 Oct 2013 09:14:34 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0342121F9978 for ; Fri, 4 Oct 2013 09:09:20 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 4 Oct 2013 09:09:15 -0700 From: "Cockrell, Erik" To: "sacm@ietf.org" Date: Fri, 4 Oct 2013 09:09:13 -0700 Thread-Topic: Re: [sacm] Title for SACM Use Cases Draft Thread-Index: Ac7BG/ntPoeEXsqER8uuY9uZrLvUJg== Message-ID: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EA@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EACRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:14:46 -0000 --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EACRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also support the old title since the scope of this group is not just limi= ted to granting access to resources. Erik Cockrell, Product Security Engineer, Polycom Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.71= 55 | c: 512.739.4250 | f: 512.372.7142 --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EACRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also support t= he old title since the scope of this group is not just limited to granting = access to resources.

 

Erik Cockrell, Produc= t Security Engineer, Polycom Product Secur= ity Office

The holy grail of = security is airtight input validation.

7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 = | = t: 512.372.7155 | c: 512.739.4250 | f: 512.37= 2.7142

 

= --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EACRPMBOXPRD07pol_-- From blueroofmusic@gmail.com Fri Oct 4 10:15:31 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A960B21F9C46 for ; Fri, 4 Oct 2013 10:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUhEwsRHuYF9 for ; Fri, 4 Oct 2013 10:15:30 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1A121F9A98 for ; Fri, 4 Oct 2013 10:15:27 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id qd12so9793040ieb.36 for ; Fri, 04 Oct 2013 10:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9j1/yjoXI32eY2bYi+BUXq7+V5Fv1KyLKbvHTLxawsQ=; b=KWRJLCvpN6sascfelLKAaIllO/Y7/XoPZNYIyB+KfAGHXFwt1k6elpqNMb2Fpm0MkD Wgw7qWraChagZOAWpyQJxvpXm0DZMce0YRxvDtI0hOpW8Hg7CzFBYnB/zsIpQBXp/Vis hPMegJmZ7aK64uApRvOmNvPqVuU5zem5x9YnplTHVrYhHPKCj5/4/xPuTAcpeUucHqCo rPotqDRkx22usJ6vwjipIAtV0QcLMtafTNYONapj2CB8JeBzVKOJI0he1jGabxPVfhgl LtFcuPxrmaLnhJZwM1MToZTDOn+RkacP85zr0RARwTDrP2gI7TlCd8M/GyB55QCEP2dc xFIg== X-Received: by 10.50.127.197 with SMTP id ni5mr7273340igb.54.1380906926536; Fri, 04 Oct 2013 10:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.96.135 with HTTP; Fri, 4 Oct 2013 10:15:06 -0700 (PDT) In-Reply-To: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EA@CRPMBOXPRD07.polycom.com> References: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EA@CRPMBOXPRD07.polycom.com> From: Ira McDonald Date: Fri, 4 Oct 2013 13:15:06 -0400 Message-ID: To: "Cockrell, Erik" , Ira McDonald Content-Type: multipart/alternative; boundary=089e013a286ed33abe04e7ed7273 Cc: "sacm@ietf.org" Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 17:15:31 -0000 --089e013a286ed33abe04e7ed7273 Content-Type: text/plain; charset=ISO-8859-1 Hi, I also prefer the original title. Although I suggest deleting the redundant "Analysis of" prefix. A search of the RFC Index for use cases from other IETF WGs supports my suggestion. And "Analysis of" could easily imply the extraction of Design Requirements and it appears there is rough consensus to leave that for a separate document. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Oct 4, 2013 at 12:09 PM, Cockrell, Erik wrote: > I also support the old title since the scope of this group is not just > limited to granting access to resources.**** > > ** ** > > *Erik Cockrell*,* *Product Security Engineer, Polycom Product Security > Office**** > > *The holy grail of security is airtight input validation.* > > 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: > 512.372.7155 | c: 512.739.4250 | f: 512.372.7142**** > > ** ** > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > --089e013a286ed33abe04e7ed7273 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I also prefer the original= title.

Although I suggest deleting the redundant "Analysis of&= quot; prefix.=A0 A search of the
RFC Index for use cases from=A0 other I= ETF WGs supports my suggestion.

And "Analysis of" could easily imply the extractio= n of Design Requirements and
it appears there is rough consen= sus to leave that for a separate document.

Cheers,<= br>
- Ira


= Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Op= en Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair -= IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded System= s Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roo= f Music/High North Inc
http://sites.google.= com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Fri, Oct 4, 2013 at 12:09 PM, Cockrel= l, Erik <Erik.Cockrell@polycom.com> wrote:

I also support the old title since the scope of this group is not just = limited to granting access to resources.

=A0

Eri= k Cockrell, Product Security Engineer, = Polycom Product Security Office

The holy grail of security i= s airtight input validation.

7700 West Parmer Lane, Bldg. C, Suite 100, Austin,= TX 78730 | t: 512.372.7155 <= /span>| c: 512.739.4250 | f: 512.372.7142

=A0


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


--089e013a286ed33abe04e7ed7273-- From pkampana@cisco.com Fri Oct 4 10:32: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 31B9921F9D92 for ; Fri, 4 Oct 2013 10:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynE6Jf0UjM5u for ; Fri, 4 Oct 2013 10:32:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id ABC8B21F9C12 for ; Fri, 4 Oct 2013 10:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1459; q=dns/txt; s=iport; t=1380907928; x=1382117528; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VU9SzAaDU3EhLkxUq3AkZlYMWOeCqQi304I9AKxwzY4=; b=HMLpQsi1QtOdf2sNzebairaMjR7xvcK7vUXbSryk91JfrrEb4TU6rShU WU1WC89+RY6kT/dLdstUJJ6R/Hq2VHrDTChGtktXrZAml+DzzPRuAKo/0 QwKGuxfzWWk8nKd5CTlaNWTIftZp4AYpabPJsgPvs1CRhM16Mflmb2qey I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAHD6TlKtJV2Y/2dsb2JhbABWA4MHOFLBSIEaFm0HgiUBAQEDAQEBATc0EAcEAgEIEQQBAQEKFAkHJwsUCQgBAQQTCId4Bgy8IQSPICEXBguDDoEEA6oAgySCKg X-IronPort-AV: E=Sophos;i="4.90,1034,1371081600"; d="scan'208";a="268234852" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 04 Oct 2013 17:32:08 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r94HW7ej023545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Oct 2013 17:32:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 12:32:07 -0500 From: "Panos Kampanakis (pkampana)" To: "sacm@ietf.org" Thread-Topic: [sacm] Title for SACM Use Cases Draft Thread-Index: Ac7AcLLPpnMpwtlTQT6Ha61+RvsErAAS1SKAABrlFjA= Date: Fri, 4 Oct 2013 17:32:06 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A75048D78F2@xmb-rcd-x10.cisco.com> References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <03BAA9D0-53CA-4807-8717-FCE984AE8EFE@McAfee.com> In-Reply-To: <03BAA9D0-53CA-4807-8717-FCE984AE8EFE@McAfee.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 17:32:16 -0000 +1 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Thursday, October 03, 2013 8:42 PM To: shanna@juniper.net Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft I agree with Steve. I like the first one as the new title gives the wrong i= mpression. Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026 > On Oct 3, 2013, at 1:03 PM, "Stephen Hanna" wrote: >=20 > Dave and Nancy were talking about the title for the SACM Use Cases=20 > document. The old title was: >=20 > Analysis of Security Automation and Continuous Monitoring (SACM) Use=20 > Cases >=20 > The new title is: >=20 > Using Security Posture Assessment to Grant Access to Enterprise=20 > Network Resources >=20 > I prefer the old title. The new title implies that the only purpose of=20 > this work is to "Grant Access to Enterprise Network Resources". > There are many other purposes such as preparing reports on endpoint=20 > policy compliance, finding misconfigured endpoints so they can be=20 > fixed, etc. >=20 > Thanks, >=20 > Steve >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Fri Oct 4 10:41:01 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B1021F9D62 for ; Fri, 4 Oct 2013 10:41:01 -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 x3ygNNFYo+Zy for ; Fri, 4 Oct 2013 10:40:56 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id A23ED21F9CA6 for ; Fri, 4 Oct 2013 10:40:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=Ni+bNtOlSjmIwEc771Kruj9YNQ4aDDytYWy265WumqhfV2v6rXw6/N4jAETrbUYfMEm25W/o5OURFQSwO/uxJzw188jbh/DdPm/wOFkhRttrr5+SKMzfIPCuKwGOvs8J; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 1823 invoked from network); 4 Oct 2013 10:42:14 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Oct 2013 10:42:14 -0700 Message-ID: <524EFDAE.5030807@ThreatGuard.com> Date: Fri, 04 Oct 2013 13:41:02 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Hanna References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> In-Reply-To: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 17:41:01 -0000 I'd like to hear from Dave and Nancy on their thinking about this, but I suspect the reason for the title change has more to do with the recognition that the current use cases document covers much more than use cases. If that was the goal, then given the choice between change the document name and break it out into other documents, a title change is fine. It's just that, as everybody who has responded so far has pointed out, SACM isn't focused just on network access. Dave: Apologies, but I've barely had time to do more than take a quick glance at your changes to the "use cases" document, so I can only give a broad opinion right now. First: All of the text in the document is good. I expect on detailed examination to find some typos and maybe some quibbles with phrasing, but overall the current text is all good. Second: The restructure of the document is a help Third: I'm still not seeing justification for much of the contents of the document, especially in the context of the SACM charter. I've got a thought for inserting a new chapter 3 ahead of the current one that might help -- hopefully I can make some time by the start of next week to flesh that out. On 10/3/2013 3:42 PM, Stephen Hanna wrote: > Dave and Nancy were talking about the title for > the SACM Use Cases document. The old title was: > > Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases > > The new title is: > > Using Security Posture Assessment to Grant Access to Enterprise Network Resources > > I prefer the old title. The new title implies > that the only purpose of this work is to > "Grant Access to Enterprise Network Resources". > There are many other purposes such as preparing > reports on endpoint policy compliance, finding > misconfigured endpoints so they can be fixed, etc. > > Thanks, > > Steve > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From stephen.whitlock@boeing.com Fri Oct 4 11:07: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 0A47E21F941F for ; Fri, 4 Oct 2013 11:07: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 HFlqnBuU2ZMZ for ; Fri, 4 Oct 2013 11:07:49 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82021F9D92 for ; Fri, 4 Oct 2013 11:07:48 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r94I7kJL013163 for ; Fri, 4 Oct 2013 13:07:46 -0500 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r94I7iPt013090 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 4 Oct 2013 13:07:46 -0500 Received: from XCH-BLV-501.nw.nos.boeing.com (130.247.25.190) by XCH-NWHT-06.nw.nos.boeing.com (130.247.25.110) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 4 Oct 2013 11:07:45 -0700 Received: from XCH-BLV-401.nw.nos.boeing.com ([169.254.1.219]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.153]) with mapi id 14.02.0328.011; Fri, 4 Oct 2013 11:07:44 -0700 From: "Whitlock, Stephen" To: Gunnar Engelbach , Stephen Hanna Thread-Topic: [sacm] Title for SACM Use Cases Draft Thread-Index: AQHOwSjkDSHgk93t00WOlBCDSjBgdZnk1qSA Date: Fri, 4 Oct 2013 18:07:44 +0000 Message-ID: <69235492DB20AC4EBBED65919EB0A2A606C1EA@XCH-BLV-401.nw.nos.boeing.com> References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> In-Reply-To: <524EFDAE.5030807@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "sacm@ietf.org" Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 18:07:55 -0000 +1 on keeping them in one document. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gun= nar Engelbach Sent: Friday, October 04, 2013 10:41 AM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft I'd like to hear from Dave and Nancy on their thinking about this, but I su= spect the reason for the title change has more to do with the recognition t= hat the current use cases document covers much more than use cases. If that was the goal, then given the choice between change the document nam= e and break it out into other documents, a title change is fine. It's just that, as everybody who has responded so far has pointed out, SACM= isn't focused just on network access. Dave: Apologies, but I've barely had time to do more than take a quick=20 glance at your changes to the "use cases" document, so I can only give a=20 broad opinion right now. First: All of the text in the document is good. I expect on detailed=20 examination to find some typos and maybe some quibbles with phrasing,=20 but overall the current text is all good. Second: The restructure of the document is a help Third: I'm still not seeing justification for much of the contents of=20 the document, especially in the context of the SACM charter. I've got a=20 thought for inserting a new chapter 3 ahead of the current one that=20 might help -- hopefully I can make some time by the start of next week=20 to flesh that out. On 10/3/2013 3:42 PM, Stephen Hanna wrote: > Dave and Nancy were talking about the title for > the SACM Use Cases document. The old title was: > > Analysis of Security Automation and Continuous Monitoring (SACM) Use Case= s > > The new title is: > > Using Security Posture Assessment to Grant Access to Enterprise Network R= esources > > I prefer the old title. The new title implies > that the only purpose of this work is to > "Grant Access to Enterprise Network Resources". > There are many other purposes such as preparing > reports on endpoint policy compliance, finding > misconfigured endpoints so they can be fixed, etc. > > Thanks, > > Steve > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Fri Oct 4 12:33: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 9EE9A21F9D7A for ; Fri, 4 Oct 2013 12:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrJh0-dXk+K8 for ; Fri, 4 Oct 2013 12:33:32 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) by ietfa.amsl.com (Postfix) with ESMTP id 076B221F9CC5 for ; Fri, 4 Oct 2013 12:33:30 -0700 (PDT) Received: from [216.82.242.179:10217] by server-9.bemta-8.messagelabs.com id B2/FA-16766-9081F425; Fri, 04 Oct 2013 19:33:29 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-86.messagelabs.com!1380915208!44045530!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 12443 invoked from network); 4 Oct 2013 19:33:29 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 4 Oct 2013 19:33:29 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Fri, 4 Oct 2013 15:33:27 -0400 From: Adam Montville To: "Whitlock, Stephen" , Gunnar Engelbach , Stephen Hanna Thread-Topic: [sacm] Title for SACM Use Cases Draft Thread-Index: Ac7AcLLPpnMpwtlTQT6Ha61+RvsErAA2bjwAAADuuAAABakkwA== Date: Fri, 4 Oct 2013 19:33:26 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D68713AC@CISEXCHANGE1.msisac.org.local> References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> <69235492DB20AC4EBBED65919EB0A2A606C1EA@XCH-BLV-401.nw.nos.boeing.com> In-Reply-To: <69235492DB20AC4EBBED65919EB0A2A606C1EA@XCH-BLV-401.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 19:33:36 -0000 It would be great to see as much response to use-case-specific discussions= as there is to titling and formatting :-) Unfortunately, as many of you have probably already seen, David Waltermire= is essentially out-of-pocket during the USG shutdown, and I'm not sure wh= en he might be popping back up here. In light of this, it might be good for David Harrington, or someone else, = to pick up editing of the Use Case document. Any thoughts on this? Adam > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Whitlock, Stephen > Sent: Friday, October 04, 2013 11:08 AM > To: Gunnar Engelbach; Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Title for SACM Use Cases Draft >=20 > +1 on keeping them in one document. >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Friday, October 04, 2013 10:41 AM > To: Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Title for SACM Use Cases Draft >=20 >=20 > I'd like to hear from Dave and Nancy on their thinking about this, but I= > suspect the reason for the title change has more to do with the recognit= ion > that the current use cases document covers much more than use cases. >=20 > If that was the goal, then given the choice between change the document > name and break it out into other documents, a title change is fine. >=20 > It's just that, as everybody who has responded so far has pointed out, S= ACM > isn't focused just on network access. >=20 >=20 > Dave: Apologies, but I've barely had time to do more than take a quick > glance at your changes to the "use cases" document, so I can only give a= > broad opinion right now. >=20 > First: All of the text in the document is good. I expect on detailed > examination to find some typos and maybe some quibbles with phrasing, bu= t > overall the current text is all good. >=20 > Second: The restructure of the document is a help >=20 > Third: I'm still not seeing justification for much of the contents of t= he > document, especially in the context of the SACM charter. I've got a tho= ught > for inserting a new chapter 3 ahead of the current one that might help -= - > hopefully I can make some time by the start of next week to flesh that o= ut. >=20 >=20 >=20 >=20 > On 10/3/2013 3:42 PM, Stephen Hanna wrote: > > Dave and Nancy were talking about the title for the SACM Use Cases > > document. The old title was: > > > > Analysis of Security Automation and Continuous Monitoring (SACM) Use > > Cases > > > > The new title is: > > > > Using Security Posture Assessment to Grant Access to Enterprise > > Network Resources > > > > I prefer the old title. The new title implies that the only purpose of= > > this work is to "Grant Access to Enterprise Network Resources". > > There are many other purposes such as preparing reports on endpoint > > policy compliance, finding misconfigured endpoints so they can be > > fixed, etc. > > > > Thanks, > > > > Steve > > > > > > _______________________________________________ > > 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 > ... . . . From blueroofmusic@gmail.com Fri Oct 4 13:47: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 5E11421F9C42 for ; Fri, 4 Oct 2013 13:47: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qykkCvGPvsLQ for ; Fri, 4 Oct 2013 13:47:18 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2821F9E3A for ; Fri, 4 Oct 2013 13:47:16 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so9882691ieb.26 for ; Fri, 04 Oct 2013 13:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kQ1ZhIMa858S7fYb0MQy4mreOPc7p/en4SsPHoC5y5o=; b=WBz3rWSfZEQ+2ieacIl3aKMjdStRcFK5RKfnTu36kS9WpRLhs2No+zweK/lZTYAby6 ya6cJbRR26CyplWOBhZCWbmA4QJoHzN8bD6i3/aTvYDbtuvDJfyLMJnJW4WCAyOQZHDo T7TOxbil87XPikXqz/REi89PsgdNFRemxJASpdu2nWQdcQfEgO/6aYQNgA8QzYmCosnI X0Oj8oCaLNT+cY8TRM4BkOLBNSCTUn9mRGLIAL+GYU1gtiGuYLU2nPvvmcvQ5wCJFl6B qR53Exb27h4kV1Q+jvQsM9RJQBnq+uP6K/BTNKxWmIGLKfB6ysjIt3CsO7HkSkf2R3Ja Hnjg== X-Received: by 10.50.127.197 with SMTP id ni5mr8010634igb.54.1380919635531; Fri, 04 Oct 2013 13:47:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.96.135 with HTTP; Fri, 4 Oct 2013 13:46:55 -0700 (PDT) In-Reply-To: <472d40191a3844599aa3995a94a0cb2a@BLUPR05MB323.namprd05.prod.outlook.com> References: <472d40191a3844599aa3995a94a0cb2a@BLUPR05MB323.namprd05.prod.outlook.com> From: Ira McDonald Date: Fri, 4 Oct 2013 16:46:55 -0400 Message-ID: To: Stephen Hanna , Ira McDonald Content-Type: multipart/alternative; boundary=089e013a286e56e32a04e7f0680f Cc: "sacm@ietf.org" Subject: Re: [sacm] My Comments on draft-ietf-sacm-use-cases-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 20:47:19 -0000 --089e013a286e56e32a04e7f0680f Content-Type: text/plain; charset=ISO-8859-1 Hi, +1 to all of Steve Hanna and Nancy Cam-Winget's comments on this draft. Section 4 Functional Capabilities does not belong in this Use Cases document. It descends into solution details that obscure the simple use cases. Steve - please do send paragraphs on your 3 suggested additional use cases: - Search for Signs of Infection - Remediation & Mitigation - Endpoint Information Analysis & Reporting Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Oct 3, 2013 at 3:33 PM, Stephen Hanna wrote: > I just finished a review of the latest SACM > use cases draft. Here are my comments. > > * I agree with Nancy that Section 4 (Functional > Capabilities) does not belong in a Use Case > document. We may need to add this back later > but I think we should first focus on agreeing > on what problems we want to solve (use cases). > I suggest that we remove section 4 for now. > > * I definitely like the new use cases vs. the > old ones in the -00 version. The new use cases > are specific. I know what they mean. The old > ones were too general and lengthy. I was never > sure that I understood them and it seemed > quite likely that two people reading them would > understand them differently. Thanks for making > these changes. > > * All the current use cases seem to be in scope > for this group. > > * At the start of section 3.1, you ask > > QUESTION: This use case applies equally to vendors representing other > endpoint types. Should this be generalized to capture this notion? > > I suggest that you keep the current text. It's > good to have specific use cases that span the > problem space. If you want, you can add a sentence > at the end that says this use case could apply to > other endpoint types just as easily. > > * At the end of section 3.1, you ask > > QUESTION: Is providing traceability to functional capabilities > useful? If so, we need to replicate this for the other use cases. > > As I mentioned above, I don't think it's a good > idea to add a list of abstract capabilities to > this document. Let's agree on the problems that > we want to solve. Then we can talk about which > concepts to use to solve those problems. So I'd > like to delete the list of capabilities at the > end of section 3.1. > > * In section 3.2, the checklists might come from > sources other than vendors. For example, the > financial services company might get checklists > from a financial industry group or develop its > own checklists. I'm perfectly happy leaving this > use case mainly as it is but adding a sentence > at the end saying that the checklists could also > come from sources other than the application or > OS vendor. Similar text should also go at the > end of section 3.1. > > * Here are a few more use cases: Search for Signs > of Infection, Remediation & Mitigation, and > Endpoint Information Analysis & Reporting. > Do you want me to write a few paragraphs > on those? > > Thanks, > > Steve > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --089e013a286e56e32a04e7f0680f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

+1 to all of Steve Hanna a= nd Nancy Cam-Winget's comments on this draft.

Section 4 Fu= nctional Capabilities does not belong in this Use Cases document.
It descends into solution details that obscure the simple use cases.

Steve - please do send paragraphs on your 3 sug= gested additional use cases:
- Search for Signs of Infection
- Remedi= ation & Mitigation
- Endpoint Information Analysis & Reporting

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - L= inux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP= WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded= Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434



On Thu, Oct 3, 2013 at 3:33 PM, Stephen = Hanna <shanna@juniper.net> wrote:
I just finished a review of the latest SACM
use cases draft. Here are my comments.

* I agree with Nancy that Section 4 (Functional
=A0 Capabilities) does not belong in a Use Case
=A0 document. We may need to add this back later
=A0 but I think we should first focus on agreeing
=A0 on what problems we want to solve (use cases).
=A0 I suggest that we remove section 4 for now.

* I definitely like the new use cases vs. the
=A0 old ones in the -00 version. The new use cases
=A0 are specific. I know what they mean. The old
=A0 ones were too general and lengthy. I was never
=A0 sure that I understood them and it seemed
=A0 quite likely that two people reading them would
=A0 understand them differently. Thanks for making
=A0 these changes.

* All the current use cases seem to be in scope
=A0 for this group.

* At the start of section 3.1, you ask

QUESTION: This use case applies equally to vendors representing other
endpoint types. =A0Should this be generalized to capture this notion?

=A0 I suggest that you keep the current text. It's
=A0 good to have specific use cases that span the
=A0 problem space. If you want, you can add a sentence
=A0 at the end that says this use case could apply to
=A0 other endpoint types just as easily.

* At the end of section 3.1, you ask

QUESTION: Is providing traceability to functional capabilities
useful? =A0If so, we need to replicate this for the other use cases.

=A0 As I mentioned above, I don't think it's a good
=A0 idea to add a list of abstract capabilities to
=A0 this document. Let's agree on the problems that
=A0 we want to solve. Then we can talk about which
=A0 concepts to use to solve those problems. So I'd
=A0 like to delete the list of capabilities at the
=A0 end of section 3.1.

* In section 3.2, the checklists might come from
=A0 sources other than vendors. For example, the
=A0 financial services company might get checklists
=A0 from a financial industry group or develop its
=A0 own checklists. I'm perfectly happy leaving this
=A0 use case mainly as it is but adding a sentence
=A0 at the end saying that the checklists could also
=A0 come from sources other than the application or
=A0 OS vendor. Similar text should also go at the
=A0 end of section 3.1.

* Here are a few more use cases: Search for Signs
=A0 of Infection, Remediation & Mitigation, and
=A0 Endpoint Information Analysis & Reporting.
=A0 Do you want me to write a few paragraphs
=A0 on those?

Thanks,

Steve


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

--089e013a286e56e32a04e7f0680f-- From ietfdbh@comcast.net Fri Oct 4 19:21: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 23CCC21F9DB4 for ; Fri, 4 Oct 2013 19:21:53 -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 8ISWPS0Zx-nj for ; Fri, 4 Oct 2013 19:21:48 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 375B221F9A4A for ; Fri, 4 Oct 2013 19:21:47 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta06.westchester.pa.mail.comcast.net with comcast id ZEKi1m00227AodY56EMnR0; Sat, 05 Oct 2013 02:21:47 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta19.westchester.pa.mail.comcast.net with comcast id ZEMm1m00Q2yZEBF3fEMmE1; Sat, 05 Oct 2013 02:21:47 +0000 From: "ietfdbh" To: "'Adam Montville'" , "'Whitlock, Stephen'" , "'Gunnar Engelbach'" , "'Stephen Hanna'" References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> <69235492DB20AC4EBBED65919EB0A2A606C1EA@XCH-BLV-401.nw.nos.boeing.com> <05BCCEB107AF88469B9F99783D47C1D68713AC@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D68713AC@CISEXCHANGE1.msisac.org.local> Date: Fri, 4 Oct 2013 22:21:48 -0400 Message-ID: <02b301cec171$a5ace600$f106b200$@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: AQJGg/1mngwXI+xc5q4MvxRT2zq0bgHYYNWmAUMItnwB8bgcxZjNcdAQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380939707; bh=Klo1mCftREwS0RzqRquWf8QXvk1hISBqxy+sQq96tNc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Xt3AOhRJO+eOPpaGSN53gmQsgefG06lvUYxUk23cgMjJTFQstZA6zhXhVTxmMH/ZB R1htJgok7zfHEYyU8v/CoIwwF6b7iYDiqGNaWMSImgIyOYBAi60H4jEIiaVyODVlzB deE/vEVkib+M5/kFSaEmviK5As8GE9ICjal8d0ap22g1Q/W/EfcSkdwlXR/GSdDc/H PV5S0VFLu1ALEJ6O6WsX6N4/D7yqk+MV1pkmpBFRPBQwg7yRcUDwq3xnnQiBVtOss0 1bVqEuwrFa55C3bGph04Es4zQpnJSEdM0lE58huD9ZTFVUfokZmw3QNNjRNyZsAfdK 607M5LHg22fOA== Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 02:21:53 -0000 Hi, OK with me. We need some consensus on the content before editing can occur ... Discussions of use cases would be very helpful. I'll try to get the latest sources from DM, or work from the latest I have. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, October 04, 2013 3:33 PM > To: Whitlock, Stephen; Gunnar Engelbach; Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Title for SACM Use Cases Draft > > It would be great to see as much response to use-case-specific discussions as > there is to titling and formatting :-) > > Unfortunately, as many of you have probably already seen, David Waltermire > is essentially out-of-pocket during the USG shutdown, and I'm not sure when > he might be popping back up here. > > In light of this, it might be good for David Harrington, or someone else, to pick > up editing of the Use Case document. Any thoughts on this? > > Adam > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Whitlock, Stephen > > Sent: Friday, October 04, 2013 11:08 AM > > To: Gunnar Engelbach; Stephen Hanna > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > > +1 on keeping them in one document. > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Gunnar Engelbach > > Sent: Friday, October 04, 2013 10:41 AM > > To: Stephen Hanna > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > > > > I'd like to hear from Dave and Nancy on their thinking about this, but I > > suspect the reason for the title change has more to do with the recognition > > that the current use cases document covers much more than use cases. > > > > If that was the goal, then given the choice between change the document > > name and break it out into other documents, a title change is fine. > > > > It's just that, as everybody who has responded so far has pointed out, > SACM > > isn't focused just on network access. > > > > > > Dave: Apologies, but I've barely had time to do more than take a quick > > glance at your changes to the "use cases" document, so I can only give a > > broad opinion right now. > > > > First: All of the text in the document is good. I expect on detailed > > examination to find some typos and maybe some quibbles with phrasing, > but > > overall the current text is all good. > > > > Second: The restructure of the document is a help > > > > Third: I'm still not seeing justification for much of the contents of the > > document, especially in the context of the SACM charter. I've got a > thought > > for inserting a new chapter 3 ahead of the current one that might help -- > > hopefully I can make some time by the start of next week to flesh that out. > > > > > > > > > > On 10/3/2013 3:42 PM, Stephen Hanna wrote: > > > Dave and Nancy were talking about the title for the SACM Use Cases > > > document. The old title was: > > > > > > Analysis of Security Automation and Continuous Monitoring (SACM) Use > > > Cases > > > > > > The new title is: > > > > > > Using Security Posture Assessment to Grant Access to Enterprise > > > Network Resources > > > > > > I prefer the old title. The new title implies that the only purpose of > > > this work is to "Grant Access to Enterprise Network Resources". > > > There are many other purposes such as preparing reports on endpoint > > > policy compliance, finding misconfigured endpoints so they can be > > > fixed, etc. > > > > > > Thanks, > > > > > > Steve > > > > > > > > > _______________________________________________ > > > 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 ietfdbh@comcast.net Sat Oct 5 04:37: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 529A821F9CC5 for ; Sat, 5 Oct 2013 04:37:06 -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 WPOU9zqI0Asy for ; Sat, 5 Oct 2013 04:37:01 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 8F76B21F9CBF for ; Sat, 5 Oct 2013 04:36:49 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id ZPXk1m0030cZkys5DPcnqh; Sat, 05 Oct 2013 11:36:47 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id ZPcl1m00g2yZEBF3WPcmtb; Sat, 05 Oct 2013 11:36:47 +0000 From: "ietfdbh" To: "'Adam Montville'" , , "Waltermire, David A." References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> <69235492DB20AC4EBBED65919EB0A2A606C1EA@XCH-BLV-401.nw.nos.boeing.com> <05BCCEB107AF88469B9F99783D47C1D68713AC@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D68713AC@CISEXCHANGE1.msisac.org.local> Date: Sat, 5 Oct 2013 07:36:48 -0400 Message-ID: <02bd01cec1bf$2e80a460$8b81ed20$@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: AQJGg/1mngwXI+xc5q4MvxRT2zq0bgHYYNWmAUMItnwB8bgcxZjN9ABg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380973007; bh=kD5hSTXMonKToYHjM6H1saTElxe9b+N4pAscZJG6hpI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=k9pSswUYmXBq9QG0uF+YqwHz2CsJqzMdophoLkk9DFm3RybD7MRPEOKUnPGbgcbrh fYNT5FBFP8fnAsyIhCC5Kk8z7ystAht6F9F10m3UfKRnIyavz7ZDBkFOksmweuuxD7 0pwj1422hTRgnNwY+Cpjn32Xvx+LJPmuprvjIXhsE8gW2CPeSTbpjv2DYwleuQD/Cr +b592Z6X2DwcAVSQyAUNAlyveb2YCIs/l/0SaTER1dw5cVfOkcAdE7UD9yE/bal/5V 6/lmQtvCs406GqDmVuGNBwRMoSXOodewul1WGo3iaounF2NI9UjXe7PWoISk91gCCf /vnfqViAUCESQ== Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 11:37:06 -0000 Hi Adam, Did David ask you to request that others pick up the pen for the use cases doc? I will call David to discuss whether he needs me to take the pen, and to get his latest sources. -- out of pocket -- People operating in IETF contribute as individuals. I have been operating out-of-pocket all the time I have been editing for sacm. Many contribute to IETF out-of-pocket. The fact that David is operating out-of-pocket during the US govt shutdown shouldn't really make a difference to his IETF editing capabilities. I would think that with the US govt shutdown, David might have MORE time to edit the documents. -- ietf88 -- I do think the govt shutdown, and David's out-of-pocket situation, could impact David's attendance at the next meeting. I know from Tim Polk's experience with a previous shutdown that NIST employees are bound by a set of rules about what they are allowed to finance on their own, or to accept as "gifts" to cover IETF meeting expenses. I do not expect to attend the next meeting; I would have difficulty justifying the out-of-pocket costs. Following the recommended IETF approach, we should stimulate ML discussion and update the document prior to the deadline. I think David and I (and the chairs) can do that, and David and I can prepare "status" slides for the meeting, and participate remotely. -- use cases document -- David has been driving the discussions with the intention of updating the document. We changed the structure and content significantly from the -00- revision. We want WG reaction to the changes, and the next revision will bring the document closer to WG consensus preferences. I have been deliberately letting David drive the discussions, track the needed changes, and edit the next revision. We have gotten some good feedback on the list. I have also been tracking the discussions and proposed changes, in case I needed to pick up the pen. I have the xml2rfc sources for the -00- revision; I don't know if David has a more updated, unpublished revision of XML source. I am of the impression that WG consensus is to remove the functional capabilities analysis from the use cases doc. Some of the analysis might be more appropriate for the requirements doc. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, October 04, 2013 3:33 PM > To: Whitlock, Stephen; Gunnar Engelbach; Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Title for SACM Use Cases Draft > > It would be great to see as much response to use-case-specific discussions as > there is to titling and formatting :-) > > Unfortunately, as many of you have probably already seen, David Waltermire > is essentially out-of-pocket during the USG shutdown, and I'm not sure when > he might be popping back up here. > > In light of this, it might be good for David Harrington, or someone else, to pick > up editing of the Use Case document. Any thoughts on this? > > Adam > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Whitlock, Stephen > > Sent: Friday, October 04, 2013 11:08 AM > > To: Gunnar Engelbach; Stephen Hanna > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > > +1 on keeping them in one document. > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Gunnar Engelbach > > Sent: Friday, October 04, 2013 10:41 AM > > To: Stephen Hanna > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > > > > I'd like to hear from Dave and Nancy on their thinking about this, but I > > suspect the reason for the title change has more to do with the recognition > > that the current use cases document covers much more than use cases. > > > > If that was the goal, then given the choice between change the document > > name and break it out into other documents, a title change is fine. > > > > It's just that, as everybody who has responded so far has pointed out, > SACM > > isn't focused just on network access. > > > > > > Dave: Apologies, but I've barely had time to do more than take a quick > > glance at your changes to the "use cases" document, so I can only give a > > broad opinion right now. > > > > First: All of the text in the document is good. I expect on detailed > > examination to find some typos and maybe some quibbles with phrasing, > but > > overall the current text is all good. > > > > Second: The restructure of the document is a help > > > > Third: I'm still not seeing justification for much of the contents of the > > document, especially in the context of the SACM charter. I've got a > thought > > for inserting a new chapter 3 ahead of the current one that might help -- > > hopefully I can make some time by the start of next week to flesh that out. > > > > > > > > > > On 10/3/2013 3:42 PM, Stephen Hanna wrote: > > > Dave and Nancy were talking about the title for the SACM Use Cases > > > document. The old title was: > > > > > > Analysis of Security Automation and Continuous Monitoring (SACM) Use > > > Cases > > > > > > The new title is: > > > > > > Using Security Posture Assessment to Grant Access to Enterprise > > > Network Resources > > > > > > I prefer the old title. The new title implies that the only purpose of > > > this work is to "Grant Access to Enterprise Network Resources". > > > There are many other purposes such as preparing reports on endpoint > > > policy compliance, finding misconfigured endpoints so they can be > > > fixed, etc. > > > > > > Thanks, > > > > > > Steve > > > > > > > > > _______________________________________________ > > > 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 ietfdbh@comcast.net Sat Oct 5 05:57:46 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA9221F8F2A for ; Sat, 5 Oct 2013 05:57:35 -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 26XgOXqYKJge for ; Sat, 5 Oct 2013 05:57:30 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 97BED21F8F09 for ; Sat, 5 Oct 2013 05:57:27 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id ZPyk1m0041c6gX85FQxTji; Sat, 05 Oct 2013 12:57:27 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta23.westchester.pa.mail.comcast.net with comcast id ZQxS1m00T2yZEBF3jQxSqp; Sat, 05 Oct 2013 12:57:26 +0000 From: "ietfdbh" To: "'Gunnar Engelbach'" , "'Stephen Hanna'" References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> In-Reply-To: <524EFDAE.5030807@ThreatGuard.com> Date: Sat, 5 Oct 2013 08:57:29 -0400 Message-ID: <02c401cec1ca$72f0eeb0$58d2cc10$@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: AQJGg/1mngwXI+xc5q4MvxRT2zq0bgHYYNWmmOe+g8A= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380977847; bh=eD9lOrWJXpUIadmb9l4DD0nEEY7S5frISaPHxD0/G0w=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=TXnmHredKVsgk1rcT3NYvGPIyn2Ehtw/TVA/CQN8blJWQRxZBqYmgWbOxZGNOa0UP YC+ixMQB7JMBfjIVPdj10ipq2bzSn7FL3ruMHYd2eir9PKrgh1fVBZCPL71uk75d4p a5o916AVdKlnm5jtM1QpMpoPYzM5IQHmDqIuYvZgHhm8mIBDJMa261WB9KsFAimxA9 bkKgUhArRqgb5EB8nCcmR5QN7TJVfmwiUUaQa8M7+ghyZ4EFdhFsycuQtWBeEODF++ bOYyCdRRsfVLIMcWVtYKyeSxWf7vwz2jg8rpLjk5tnqpTt1V5XykAdMC85vqMMmHAe BsBNWk7OnsfXw== Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 12:57:46 -0000 Hi, I agree with recent comments that SACM deals with more than just access decisions. In July, there was discussion of the scope of the work, and particularly the scope of the use-cases document. WG consensus was to limit the document to UC1; UC2 and UC3 were removed from THIS use cases document. See http://www.ietf.org/mail-archive/web/sacm/current/msg01265.html WG consensus was also to limit the scope to Enterprises. The title was changed to reflect that the content was only for "Endpoint Posture Assessment" related to Enterprise resources. The old title " Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases" is misleading in that it covers far more scope than enterprise-specific Endpoint Posture Assessment use cases. So we changed it to: "Using Security Posture Assessment to Grant Access to Enterprise Network Resources" We are using posture from RFC5209: " Posture - Configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy." "Our" posture is specific to security policy; there may be other "posture assessments" that are not specific to security policy, such as asset management policies, or regulatory compliance policies, or network management policies set by departments other than the security policy department. WG consensus seems to be we do not want to talk too much about asset management (or other scopes of policy-based management) because asset management is not part of SACM; it is referenced by SACM. SACM scope is about assessing relative to security policy. I therefore suggest "Endpoint Security Posture Assessment - Enterprise Use Cases" David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Friday, October 04, 2013 1:41 PM > To: Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > I'd like to hear from Dave and Nancy on their thinking about this, but I > suspect the reason for the title change has more to do with the > recognition that the current use cases document covers much more than > use cases. > > If that was the goal, then given the choice between change the document > name and break it out into other documents, a title change is fine. > > It's just that, as everybody who has responded so far has pointed out, > SACM isn't focused just on network access. > > > Dave: Apologies, but I've barely had time to do more than take a quick > glance at your changes to the "use cases" document, so I can only give a > broad opinion right now. > > First: All of the text in the document is good. I expect on detailed > examination to find some typos and maybe some quibbles with phrasing, > but overall the current text is all good. > > Second: The restructure of the document is a help > > Third: I'm still not seeing justification for much of the contents of > the document, especially in the context of the SACM charter. I've got a > thought for inserting a new chapter 3 ahead of the current one that > might help -- hopefully I can make some time by the start of next week > to flesh that out. > > > > > On 10/3/2013 3:42 PM, Stephen Hanna wrote: > > Dave and Nancy were talking about the title for > > the SACM Use Cases document. The old title was: > > > > Analysis of Security Automation and Continuous Monitoring (SACM) Use > Cases > > > > The new title is: > > > > Using Security Posture Assessment to Grant Access to Enterprise Network > Resources > > > > I prefer the old title. The new title implies > > that the only purpose of this work is to > > "Grant Access to Enterprise Network Resources". > > There are many other purposes such as preparing > > reports on endpoint policy compliance, finding > > misconfigured endpoints so they can be fixed, etc. > > > > Thanks, > > > > Steve > > > > > > _______________________________________________ > > 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 Sat Oct 5 06:00:24 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA6321F90A7 for ; Sat, 5 Oct 2013 06:00:24 -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.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 qg5dxWBWlazs for ; Sat, 5 Oct 2013 06:00:19 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 4F31E21F8CDD for ; Sat, 5 Oct 2013 05:59:33 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id ZQrJ1m0030Fqzac5EQzX0u; Sat, 05 Oct 2013 12:59:31 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id ZQzW1m00X2yZEBF3UQzWaT; Sat, 05 Oct 2013 12:59:30 +0000 From: "ietfdbh" To: "'Ira McDonald'" , "'Cockrell, Erik'" References: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE6EA@CRPMBOXPRD07.polycom.com> In-Reply-To: Date: Sat, 5 Oct 2013 08:59:33 -0400 Message-ID: <02c501cec1ca$bccc6730$36653590$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C6_01CEC1A9.35BBFFB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJZYwX3zMzBlWD1Wt/fYn2fjoA5kgGi8I3jmMO3lOA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380977971; bh=1loGM9ZISwl8+WTHkRcTZwjC9o1uN7/n73VbDYIRY+A=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=cjqoGNcMp2dVjuBYoGSO9GgyOjS+m1nQADOliXZIgIWwjDbv5Qx9YxsDQ53XKFiOJ Mhj1VHVa5YJCL9d0dOlxAnHATjeNr6+5wW8P/SDtW+SumlbttfCwCcOQV2Vv4WE8k6 7CGPTDCW0wIWxKwGfO/opnRik7qj20CIAyReHsr1z0Hh+KUFIdkQ5fu44KdS0UO/It DBLfzSKdD6ny+goqrH/Ys7FVI8aWgInsJKGbDgYvxBEbSQLKN9lM2Q0S2CMdih1cgJ 3ei+5xD63MqKTNSG16czxVGu3138p0WnpYwrn2rC+DVIdLzw6EuzbQWFFK8bny5TME egBzB74KSnR2w== Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 13:00:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C6_01CEC1A9.35BBFFB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree we should eliminate "Analysis of" because that does imply extracting design requirements, and I think that belongs in the requirements doc, not the use cases doc. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald Sent: Friday, October 04, 2013 1:15 PM To: Cockrell, Erik; Ira McDonald Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft Hi, I also prefer the original title. Although I suggest deleting the redundant "Analysis of" prefix. A search of the RFC Index for use cases from other IETF WGs supports my suggestion. And "Analysis of" could easily imply the extraction of Design Requirements and it appears there is rough consensus to leave that for a separate document. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Oct 4, 2013 at 12:09 PM, Cockrell, Erik wrote: I also support the old title since the scope of this group is not just limited to granting access to resources. Erik Cockrell, Product Security Engineer, Polycom Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.7155 | c: 512.739.4250 | f: 512.372.7142 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_02C6_01CEC1A9.35BBFFB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree we should eliminate “Analysis of” because that = does imply extracting design requirements, and I think that belongs in = the requirements doc, not the use cases doc.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Ira McDonald
Sent: Friday, October 04, 2013 1:15 = PM
To: Cockrell, Erik; Ira McDonald
Cc: = sacm@ietf.org
Subject: Re: [sacm] Title for SACM Use Cases = Draft

 

Hi,

I also prefer the = original title.

Although I suggest deleting the redundant = "Analysis of" prefix.  A search of the
RFC Index for = use cases from  other IETF WGs supports my = suggestion.

And = "Analysis of" could easily imply the extraction of Design = Requirements and

it = appears there is rough consensus to leave that for a separate = document.

 

Cheers,

- Ira


Ira McDonald (Musician = / Software Architect)
Chair - Linux Foundation Open Printing = WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - = IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions = WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic=
http://sites.google.com/site/highnorthinc<= /a>
mailto:blueroofmusic@gmail.com
Winter  579 Park = Place  Saline, MI  48176  734-944-0094
Summer  PO = Box 221  Grand Marais, MI 49839  = 906-494-2434

 

On Fri, Oct 4, 2013 at 12:09 PM, Cockrell, Erik <Erik.Cockrell@polycom.com> = wrote:

I also = support the old title since the scope of this group is not just limited = to granting access to resources.

 <= /o:p>

Erik Cockrell, Product Se= curity Engineer, Polycom Product Security Office

The= holy grail of security is airtight input = validation.

7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 = | = t: 512.372.7155 | c: 512.739.4250 = | = f: 512.372.7142

 <= /o:p>


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

 

------=_NextPart_000_02C6_01CEC1A9.35BBFFB0-- From ietfdbh@comcast.net Sat Oct 5 06:44: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 41B7221F8E3D for ; Sat, 5 Oct 2013 06:44:21 -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 a647V03InQXL for ; Sat, 5 Oct 2013 06:44:16 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1521F8495 for ; Sat, 5 Oct 2013 06:44:13 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id ZQp91m0031ei1Bg51RkDyu; Sat, 05 Oct 2013 13:44:13 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta24.westchester.pa.mail.comcast.net with comcast id ZRkD1m0032yZEBF3kRkDPP; Sat, 05 Oct 2013 13:44:13 +0000 From: "ietfdbh" To: "'Gunnar Engelbach'" , "'Stephen Hanna'" References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> In-Reply-To: <524EFDAE.5030807@ThreatGuard.com> Date: Sat, 5 Oct 2013 09:44:15 -0400 Message-ID: <02d601cec1d0$fbba9330$f32fb990$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJGg/1mngwXI+xc5q4MvxRT2zq0bgHYYNWmmOfUhtA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380980653; bh=iQfNLhipWtPyA08q2HSgQekgJcS6rG/+GpNIF2ndWCY=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=NsC9eM+NdNnQXNxtpIWDVnXAfQxut513KCvhNew6v1RCyzeNhx/r2WeLYleQYv4LV ZAs41gw1VkJqMrei8WCuyBYgWCOQR/5+F4uW0V+yAmfwjicJ+rjXDpybe8M9anQRZn JSKnN4ud8txF7G892H+Eh/+7ViRfRxuZocEpON13ocT1+v7NhSvRW6cw0AjgR04wIF TUDSXOZT62/lC5qxsDuwTGiIyKR6zZN3jBTTAfHj9fwuz7bxA7z1+Rgk8qFpUuBpxd nIrAdxDc7O7TOfSIy8p+58qUg8u+JPLxEelFQPBio5PrLg0FdsMG2OLhAeE0uCo396 oCwG8UlgDICYA== Cc: sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 13:44:21 -0000 Hi Gunnar, Can you be more specific about what content you do not see as justified vis-=E0-vis the charter? Are you talking about section 4, as others are? The deadline for publication of a revision is 10-21. I don't know if I'll have any delay in getting the latest sources from = Dave W. If you want something inserted into the document, you should send your proposed addition to the list asap, so we can pick it apart ;-) and try = to reach a consensus on adding it well in advance of deadline. Can you share a quick strawman before fleshing out the details? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of > Gunnar Engelbach > Sent: Friday, October 04, 2013 1:41 PM > To: Stephen Hanna > Cc: sacm@ietf.org > Subject: Re: [sacm] Title for SACM Use Cases Draft >=20 >=20 > I'd like to hear from Dave and Nancy on their thinking about this, but = I > suspect the reason for the title change has more to do with the > recognition that the current use cases document covers much more than > use cases. >=20 > If that was the goal, then given the choice between change the = document > name and break it out into other documents, a title change is fine. >=20 > It's just that, as everybody who has responded so far has pointed out, > SACM isn't focused just on network access. >=20 >=20 > Dave: Apologies, but I've barely had time to do more than take a = quick > glance at your changes to the "use cases" document, so I can only give = a > broad opinion right now. >=20 > First: All of the text in the document is good. I expect on detailed > examination to find some typos and maybe some quibbles with phrasing, > but overall the current text is all good. >=20 > Second: The restructure of the document is a help >=20 > Third: I'm still not seeing justification for much of the contents of > the document, especially in the context of the SACM charter. I've got = a > thought for inserting a new chapter 3 ahead of the current one that > might help -- hopefully I can make some time by the start of next week > to flesh that out. >=20 >=20 >=20 >=20 > On 10/3/2013 3:42 PM, Stephen Hanna wrote: > > Dave and Nancy were talking about the title for > > the SACM Use Cases document. The old title was: > > > > Analysis of Security Automation and Continuous Monitoring (SACM) Use > Cases > > > > The new title is: > > > > Using Security Posture Assessment to Grant Access to Enterprise = Network > Resources > > > > I prefer the old title. The new title implies > > that the only purpose of this work is to > > "Grant Access to Enterprise Network Resources". > > There are many other purposes such as preparing > > reports on endpoint policy compliance, finding > > misconfigured endpoints so they can be fixed, etc. > > > > Thanks, > > > > Steve > > > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Sat Oct 5 10:36: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 310F121F8CDD for ; Sat, 5 Oct 2013 10:36:55 -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 GKHW31QgZyUi for ; Sat, 5 Oct 2013 10:36:50 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1721F8C40 for ; Sat, 5 Oct 2013 10:36:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=LcnvXaCnKVirRy7scvErHu9fnN7FvqJwIWkQ1xOtKHJg6DprEl5al7ARlTXNJ6LLZ+o/CwqIWD7nk/CwBI88mWfi0fqA7XuCNK2tlP6lrCNxXIVDylgtViap2awgsu7u; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 31086 invoked from network); 5 Oct 2013 10:38:04 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Oct 2013 10:38:04 -0700 Message-ID: <52504E33.7010501@ThreatGuard.com> Date: Sat, 05 Oct 2013 13:36:51 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ietfdbh References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> <02d601cec1d0$fbba9330$f32fb990$@comcast.net> In-Reply-To: <02d601cec1d0$fbba9330$f32fb990$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'Stephen Hanna' , sacm@ietf.org Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 17:36:55 -0000 On 10/5/2013 9:44 AM, ietfdbh wrote: > Hi Gunnar, > > Can you be more specific about what content you do not see as justified > vis-à-vis the charter? > Are you talking about section 4, as others are? I don't have a problem with any of the text in the document. I suspect that it all is stuff that is needed, but that suspicion is born of my experience in this area -- somebody else reading these could just as easily disagree. Starting at the charter and working down through the documents I'm just not seeing anything that justifies the inclusion of anything that is talked about. Early talks about the structure of the use cases document did a better job of that, so my thought was to insert a new section between 2 and 3 that expands on the two items in the charter describing what this 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" And you're right, suspense is nigh, and I probably won't get a change very soon to flesh this out as much as I'd like, so let me put down what I can right now while I have a few moments. 3. Usage Examples 3.1 Endpoint Assessment [The current section 3 is a good start on this, but it's worth trying to push examples out toward the edge cases, such as the one I sent a couple months back -- Steve Hanna mentioned three more good examples] 3.2 Repository Interaction 3.2.1 Retrieve materials necessary to perform categorization of an asset (such as determine its CPE) 3.2.2 Retrieve all materials necessary to complete an automated assessment to determine the level of compliance of a Windows 7 x64 desktop machine with HIPAA regulations. 3.2.2 Retrieve materials necessary to perform evaluation of all potential vulnerabilities for iOS identified since some date that can yield unauthorized remote access or privilege escalation. 3.2.3 Retrieve human audience non-automated content associated with HIPAA compliance (such as the current HIPAA regulation, security training videos, etc). 3.2.4 Register with repository for immediate notification of new security vulnerability content that match a selection filter (Filter terms could include OSs, applications, severity rating, automated check/vulnerability announcement, original content source, content author rating, etc) Each of the examples given in section 3 can then include a summary of needs which then drive requirements. But as you pointed out that will likely have a lot of duplication. So, either: 1) Each section only lists those needs not already identified 2) The needs are listed in section 4 with a reference back to which example or architectural detail justifies its existence. The drawback, of course, is that we can't possibly think of everything right now, but I still feel a lot more comfortable that we are focused correctly and headed toward a feasible real-world solution if we make an effort to do so. These examples don't need to be long, involved, and detailed, but they do need to cover as broad a scope as fits within the charter and be detailed enough that an experienced person can infer needs from. This also gives us a potential opportunity to see if any of these needs are divergent or mutually exclusive and therefore have an opportunity to annotate scenarios that we don't expect SACM to be able to address. > > The deadline for publication of a revision is 10-21. > I don't know if I'll have any delay in getting the latest sources from Dave > W. > If you want something inserted into the document, you should send your > proposed addition to the list asap, so we can pick it apart ;-) and try to > reach a consensus on adding it well in advance of deadline. > Can you share a quick strawman before fleshing out the details? > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Gunnar Engelbach >> Sent: Friday, October 04, 2013 1:41 PM >> To: Stephen Hanna >> Cc: sacm@ietf.org >> Subject: Re: [sacm] Title for SACM Use Cases Draft >> >> >> I'd like to hear from Dave and Nancy on their thinking about this, but I >> suspect the reason for the title change has more to do with the >> recognition that the current use cases document covers much more than >> use cases. >> >> If that was the goal, then given the choice between change the document >> name and break it out into other documents, a title change is fine. >> >> It's just that, as everybody who has responded so far has pointed out, >> SACM isn't focused just on network access. >> >> >> Dave: Apologies, but I've barely had time to do more than take a quick >> glance at your changes to the "use cases" document, so I can only give a >> broad opinion right now. >> >> First: All of the text in the document is good. I expect on detailed >> examination to find some typos and maybe some quibbles with phrasing, >> but overall the current text is all good. >> >> Second: The restructure of the document is a help >> >> Third: I'm still not seeing justification for much of the contents of >> the document, especially in the context of the SACM charter. I've got a >> thought for inserting a new chapter 3 ahead of the current one that >> might help -- hopefully I can make some time by the start of next week >> to flesh that out. >> >> >> >> >> On 10/3/2013 3:42 PM, Stephen Hanna wrote: >>> Dave and Nancy were talking about the title for >>> the SACM Use Cases document. The old title was: >>> >>> Analysis of Security Automation and Continuous Monitoring (SACM) Use >> Cases >>> >>> The new title is: >>> >>> Using Security Posture Assessment to Grant Access to Enterprise Network >> Resources >>> >>> I prefer the old title. The new title implies >>> that the only purpose of this work is to >>> "Grant Access to Enterprise Network Resources". >>> There are many other purposes such as preparing >>> reports on endpoint policy compliance, finding >>> misconfigured endpoints so they can be fixed, etc. >>> >>> Thanks, >>> >>> Steve >>> >>> >>> _______________________________________________ >>> 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 Oct 6 01:35: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 3D6AB21F9D7B for ; Sun, 6 Oct 2013 01:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.411 X-Spam-Level: X-Spam-Status: No, score=-103.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 avwoYxc96oEj for ; Sun, 6 Oct 2013 01:35:18 -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 6EEED21F9EB5 for ; Sun, 6 Oct 2013 01:35:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMNAEcgUVLGmAcV/2dsb2JhbABZgmYhOFKDKKkjlE0XfhZtB4IlAQEBAQMSCwYRNxoGAQgNBAQBAQMCBgsSAwIEMBQBBgEBBQUEEwgMDodkAQuaJYRIij6RYReBKYxfgRg+BIJgNYEEA5QkhQyFLosjgySBcTk X-IronPort-AV: E=Sophos;i="4.90,1043,1371096000"; d="scan'208";a="26709219" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Oct 2013 04:35:15 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Oct 2013 04:31:22 -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.03.0146.000; Sun, 6 Oct 2013 10:35:03 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: NOMCOM 2013 - Second Call for Nominations - two weeks left Thread-Index: AQHOwSewhpu8VeF/l0OSNTEvDOPwD5nnW4dw Date: Sun, 6 Oct 2013 08:35:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128FE3C2@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 08:35:18 -0000 UGxlYXNlIHN1Ym1pdCB0byBOT01DT00gMjAxMyB5b3VyIHByb3Bvc2FscyBmb3Igbm9taW5hdGlv bnMgZm9yIHRoZSBiZXN0IHBlb3BsZSB3aG8gY2FuIGZpbGwgaW4gdGhlIG9wZW4gcG9zaXRpb25z LiBUaGlzIGlzIGFuIGltcG9ydGFudCBjb250cmlidXRpb24gdG8gdGhlIElFVEYuIA0KDQpUaGFu a3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5v dW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTMNClNl bnQ6IEZyaWRheSwgT2N0b2JlciAwNCwgMjAxMyA4OjMyIFBNDQpUbzogSUVURiBBbm5vdW5jZW1l bnQgTGlzdA0KQ2M6IElFVEYgRGlzY3VzcyBMaXN0DQpTdWJqZWN0OiBOT01DT00gMjAxMyAtIFNl Y29uZCBDYWxsIGZvciBOb21pbmF0aW9ucyAtIHR3byB3ZWVrcyBsZWZ0DQoNCk5vbWluYXRpb25z IGZvciB0aGUgSUVTRywgSUFCLCBhbmQgSUFPQyBhcmUgZHVlIHRvIHRoZSBOb21jb20gYnkgRnJp ZGF5LCAxOCBPY3RvYmVyLCAyMDEzLg0KDQpJcyB0aGVyZSBzb21lb25lIHlvdSB3b3JrIHdpdGgg YXQgSUVURiB3aG8gaGFzIGxlYWRlcnNoaXAgcG90ZW50aWFsIGFuZCBhIGdyb3dpbmcgdHJhY2sg cmVjb3JkPyBQbGVhc2UgcmVhZCB0aGUgTm9tY29tIGNhbGwgZm9yIG5vbWluYXRpb25zIGFuZCBj b25zaWRlciBub21pbmF0aW5nIGhlciBvciBoaW0uIE9yIHNldmVyYWwgZm9sa3MhIERlYWRsaW5l IGZvciBub21pbmF0aW9ucyBpcyBPY3RvYmVyIDE4LiAgTm9taW5hdGUgc29vbiB0byBnaXZlIHlv dXIgbm9taW5lZShzKSBwbGVudHkgdGltZSB0byBmaWxsIGluIHRoZSBxdWVzdGlvbm5haXJlLiBJ bmZvcm1hdGlvbiBhYm91dCB0aGUgZGVzaXJlZCBleHBlcnRpc2UgZm9yIHBvc2l0aW9ucyBpcyBo ZXJlOiANCiAgICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAx My9leHBlcnRpc2UNCg0KTG90cyBtb3JlLCBpbmNsdWRpbmcgd2hpY2ggcG9zaXRpb25zIGFyZSBv cGVuLCBob3cgdG8gbWFrZSBhIG5vbWluYXRpb24sIGFuZCBob3cgdG8gc2VuZCB1cyB5b3VyIGZl ZWRiYWNrIG9uIHRoZSBkZXNpcmVkIGV4cGVydGlzZSwgZm9sbG93cy4NCg0KSUVURmVycywgbGV0 J3MgaGVhciBmcm9tIHlvdSEgIE1ha2Ugbm9taW5hdGlvbnMsIGFjY2VwdCBub21pbmF0aW9ucyEN Cg0KSWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBhYm91dCB0aGUgcHJvY2VzcywgZmVlbCBmcmVl IHRvIGdldCBpbiB0b3VjaCB3aXRoIG1lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkFsbGlzb24gZm9y IHRoZSBOb21jb20NCg0KQWxsaXNvbiBNYW5raW4NCk5vbWNvbSBDaGFpciAyMDEzLTE0DQoNCi0t LS0tIFRoZSBJbmZvIFlvdSBOZWVkIGZvciBOb21pbmF0aW5nIC0tLS0tDQoNClRoZSAyMDEzLTE0 IE5vbWluYXRpbmcgQ29tbWl0dGVlIChOb21jb20pIGlzIHNlZWtpbmcgbm9taW5hdGlvbnMgZnJv bSBub3cgdW50aWwgT2N0b2JlciAxOCwgMjAxMy4gVGhlIG9wZW4gcG9zaXRpb25zIGJlaW5nIGNv bnNpZGVyZWQgYnkgdGhpcyB5ZWFyJ3MgTm9tY29tIGNhbiBiZSBmb3VuZCBsYXRlciBpbiB0aGlz IHNlY3Rpb24sIGFuZCBhbHNvIG9uIHRoaXMgeWVhcidzIE5vbWNvbSB3ZWJzaXRlOiANCg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxMy8NCg0KTm9taW5hdGlvbnMgbWF5 IGJlIG1hZGUgYnkgc2VsZWN0aW5nIHRoZSBOb21pbmF0ZSBsaW5rIGF0IHRoZSB0b3Agb2YgdGhl IE5vbWNvbSAyMDEzIGhvbWUgcGFnZSwgb3IgYnkgdmlzaXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6 IA0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzL25vbWluYXRlLw0K DQpOb3RlIHRoYXQgbm9taW5hdGlvbnMgbWFkZSB1c2luZyB0aGUgd2ViIHRvb2wgcmVxdWlyZSBh biBpZXRmLm9yZyBkYXRhdHJhY2tlciBhY2NvdW50LiBZb3UgY2FuIGNyZWF0ZSBhIGRhdGF0cmFj a2VyIGlldGYub3JnIGFjY291bnQgaWYgeW91IGRvbid0IGhhdmUgb25lIGFscmVhZHkgYnkgdmlz aXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv YWNjb3VudHMvY3JlYXRlLw0KDQpOb21pbmF0aW9ucyBtYXkgYWxzbyBiZSBtYWRlIGJ5IGVtYWls IHRvIG5vbWNvbTEzIGF0IGlldGYub3JnLg0KSWYgeW91IG5vbWluYXRlIGJ5IGVtYWlsLCBwbGVh c2UgaW5jbHVkZSB0aGUgd29yZCAiTm9taW5hdGUiIGluIHRoZSBTdWJqZWN0IGFuZCBpbmRpY2F0 ZSBpbiB0aGUgZW1haWwgd2hvIGlzIGJlaW5nIG5vbWluYXRlZCwgdGhlaXIgZW1haWwgYWRkcmVz cyAodG8gY29uZmlybSBhY2NlcHRhbmNlIG9mIHRoZSBub21pbmF0aW9uKSwgYW5kIHRoZSBwb3Np dGlvbiBmb3Igd2hpY2ggeW91IGFyZSBtYWtpbmcgdGhlIG5vbWluYXRpb24uIElmIHlvdSB1c2Ug ZW1haWwsIHBsZWFzZSB1c2UgYSBzZXBhcmF0ZSBlbWFpbCBmb3IgZWFjaCBwZXJzb24geW91IG5v bWluYXRlLCBhbmQgZm9yIGVhY2ggcG9zaXRpb24gKGlmIHlvdSBhcmUgbm9taW5hdGluZyBvbmUg cGVyc29uIGZvciBtdWx0aXBsZSBwb3NpdGlvbnMpLg0KDQpTZWxmLW5vbWluYXRpb24gaXMgd2Vs Y29tZSEgIE5vIG5lZWQgdG8gYmUgc2h5Lg0KDQpOb21jb20gMjAxMy0xNCB3aWxsIGZvbGxvdyB0 aGUgcG9saWN5IGZvciAiT3BlbiBEaXNjbG9zdXJlIG9mIFdpbGxpbmcgTm9taW5lZXMiIGRlc2Ny aWJlZCBpbiBSRkMgNTY4MC4gIEFzIHN0YXRlZCBpbiBSRkMgNTY4MDogIlRoZSBsaXN0IG9mIG5v bWluZWVzIHdpbGxpbmcgdG8gYmUgY29uc2lkZXJlZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmll dyBpbiB0aGUgY3VycmVudCBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxp bmcgbm9taW5lZXMgZm9yIGVhY2ggcG9zaXRpb24gd2lsbCBiZSBsaXN0ZWQgaW4gYSBwdWJsaWNs eSBhY2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRoIGEgZGF0YXRyYWNrZXIgYWNjb3VudCBtYXkg YWNjZXNzIHRoZSBsaXN0cy4gIEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5 IHJlcXVpcmVtZW50cyBvZiBSRkMgMzc3Ny9CQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsIGZl ZWRiYWNrIGFuZCBhbGwgTm9tY29tIGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50 aWFsIGFuZCB3aWxsIG5vdCBiZSBkaXNjbG9zZWQuICANCg0KSW4gb3JkZXIgdG8gZW5zdXJlIHRp bWUgdG8gY29sbGVjdCBzdWZmaWNpZW50IGNvbW11bml0eSBmZWVkYmFjayBhYm91dCBlYWNoIG9m IHRoZSB3aWxsaW5nIG5vbWluZWVzLCBub21pbmF0aW9ucyBtdXN0IGJlIHJlY2VpdmVkIGJ5IHRo ZSBOb21jb20gb24gb3IgYmVmb3JlIE9jdG9iZXIgMTgsIDIwMTMuICBQbGVhc2Ugc3VibWl0IHlv dXIgbm9taW5hdGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUgZm9yIHRoZSBzYWtlIG9mIHlvdXIg bm9taW5lZXMsIGFzIHdlJ3ZlIHNldCB0aGUgcXVlc3Rpb25uYWlyZSBzdWJtaXNzaW9uIGRlYWRs aW5lIGZvciBPY3RvYmVyIDI1LCAyMDEzLg0KDQpUaGUgbGlzdCBvZiBwZW9wbGUgYW5kIHBvc3Rz IHdob3NlIHRlcm1zIGVuZCB3aXRoIHRoZSBNYXJjaCAyMDE0IElFVEYgbWVldGluZywgYW5kIHRo dXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggd2UgYXJlIGFjY2VwdGluZyBub21pbmF0aW9uczog IA0KDQpJQU9DDQpDaHJpcyBHcmlmZml0aHMNCg0KSUFCDQpCZXJuYXJkIEFib2JhDQpNYXJjIEJs YW5jaGV0DQpSb3NzIENhbGxvbg0KRWxpb3QgTGVhcg0KSGFubmVzIFRzY2hvZmVuaWcNCg0KSUVT Rw0KQmFycnkgTGVpYmEgKEFwcGxpY2F0aW9ucykNCkJyaWFuIEhhYmVybWFuIChJbnRlcm5ldCkN CkJlbm9pdCBDbGFpc2UgKE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQpIEdvbnphbG8gQ2FtYXJp bGxvIChSQUkpIFN0ZXdhcnQgQnJ5YW50IChSb3V0aW5nKSBTZWFuIFR1cm5lciAoU2VjdXJpdHkp IE1hcnRpbiBTdGllbWVybGluZyAoVHJhbnNwb3J0KQ0KDQpQbGVhc2UgYmUgcmVzb3VyY2VmdWwg aW4gaWRlbnRpZnlpbmcgcG9zc2libGUgY2FuZGlkYXRlcyBmb3IgdGhlc2UgcG9zaXRpb25zLCBh cyBkZXZlbG9waW5nIG91ciB0YWxlbnQgaXMgYSB2ZXJ5IGNydWNpYWwgcmVxdWlyZW1lbnQgZm9y IHRoZSBJRVRGLiAgQWxzbywgcGxlYXNlIGdpdmUgc2VyaW91cyBjb25zaWRlcmF0aW9uIHRvIGFj Y2VwdGluZyBub21pbmF0aW9ucyB5b3UgcmVjZWl2ZS4gIA0KIA0KVGhlIHN1bW1hcmllcyBvZiB0 aGUgZGVzaXJlZCBleHBlcnRpc2UgZm9yIHRoZSBwb3NpdGlvbnMsIGRldmVsb3BlZCBieSB0aGUg cmVzcGVjdGl2ZSBib2RpZXMsIGFyZSBmb3VuZCBhdDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9ub21jb20vMjAxMy9leHBlcnRpc2UvDQoNCkluIGFkZGl0aW9uIHRvIG5vbWluYXRp b25zLCB0aGUgTm9tY29tIHNlZWtzIGNvbW11bml0eSBpbnB1dCBvbiB0aGUgcG9zaXRpb25zIHRo ZW1zZWx2ZXMuICBXZSBuZWVkIGFuZCB3ZWxjb21lIHRoZSBjb21tdW5pdHkncyB2aWV3cyBhbmQg aW5wdXQgb24gdGhlIGpvYnMgd2l0aGluIGVhY2ggb3JnYW5pemF0aW9uLiBJZiB5b3UgaGF2ZSBp ZGVhcyBvbiB0aGUgcG9zaXRpb25zJyByZXNwb25zaWJpbGl0aWVzIChtb3JlLCBsZXNzLCBkaWZm ZXJlbnQpLCBwbGVhc2UgbGV0IHVzIGtub3cuICBZb3UgY2FuIHNlbmQgdXMgZW1haWwgYWJvdXQg dGhpcyB0bw0Kbm9tY29tMTMgYXQgaWV0Zi5vcmcsIGFuZCB3ZSB3aWxsIHVzZSB0aGlzIGZlZWRi YWNrIGFjdGl2ZWx5Lg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscCBpbiBub21pbmF0aW5nIGEg Z3JlYXQgcG9vbCBvZiBzdHJvbmcgYW5kIGludGVyZXN0aW5nIG5vbWluZWVzIQ0KDQoNCg0K From dbharrington@comcast.net Mon Oct 7 08:13:07 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C882711E8151 for ; Mon, 7 Oct 2013 08:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khmx0zQWk0ay for ; Mon, 7 Oct 2013 08:13:02 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id CCFAF11E80EC for ; Mon, 7 Oct 2013 08:13:01 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id aBbm1m0020QuhwU51FCrKF; Mon, 07 Oct 2013 15:12:51 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta02.westchester.pa.mail.comcast.net with comcast id aFCr1m0092yZEBF3NFCr98; Mon, 07 Oct 2013 15:12:51 +0000 From: "David Harrington" To: Date: Mon, 7 Oct 2013 11:12:54 -0400 Message-ID: <033301cec36f$b30c0a60$19241f20$@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: Ac7DbebnAx1mR4QJQJScqDYRCULxQw== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381158771; bh=yMfO35XtMndaIbToBdaOQIq6gcWFRuigFSvFP8j+j4k=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=hWO/U3WtLxs3tPZ6fc0U1vI+4UvSjXTWBfEg5639PsAKpVOTeK8823FxcT8/pWWZh QuDpV+dT8cdwHe3MP1R6XY89F4/5l2muCNnYxQWzcCc0pQLO0gYL0RTfXRmTlBEzac TnUbugkgEFLdLLp1j+WYkDnnYHhs4ba5TKXLzUf+BYL9QX3A/uFVYC4KtTboNmjTmz l+bGqfu0Cpg2DqnDAN3O2Itz7ZyMGxvEHyjGiNV5T6aSKEiMbx+vgKSjJyKDeTKrP3 BL64x94/xntu+oE8uGq/XkZXD6LJNOlA2cXTFxRJAel80kmIoVcbx3oiRChUFfWard bS8nYqQ0+nqXA== Subject: [sacm] terminology draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:13:07 -0000 Hi, We presently have an individual draft containing terminology extracted from a previous use-cases draft. We should probably adopt this as a WG draft, as a starting point for a WG terminology draft. I can submit draft-dbh-sacm-terminology-00 as draft-ietf-sacm-terminology-00 before the ietf88 publication deadline. Does anybody have any objection to my doing so? Chairs, can you tell me to go ahead, and can you pre-approve this -00-? David Harrington dbharrington@comcast.net +1-603-828-1401 From shanna@juniper.net Mon Oct 7 08:19:07 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DED11E814B for ; Mon, 7 Oct 2013 08:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jlTg585FLFK1 for ; Mon, 7 Oct 2013 08:19:02 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id C762611E80ED for ; Mon, 7 Oct 2013 08:19:01 -0700 (PDT) Received: from mail186-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Mon, 7 Oct 2013 15:18:52 +0000 Received: from mail186-tx2 (localhost [127.0.0.1]) by mail186-tx2-R.bigfish.com (Postfix) with ESMTP id AE2F0300096; Mon, 7 Oct 2013 15:18:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail186-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(13464003)(164054003)(51704005)(199002)(189002)(80976001)(76576001)(74706001)(85306002)(76786001)(77096001)(74876001)(56816003)(76796001)(50986001)(47976001)(47736001)(49866001)(4396001)(81542001)(74366001)(81342001)(51856001)(46102001)(69226001)(74316001)(80022001)(77982001)(65816001)(79102001)(56776001)(54316002)(66066001)(63696002)(83322001)(19580395003)(19580405001)(59766001)(81686001)(83072001)(54356001)(53806001)(31966008)(33646001)(15975445006)(76482001)(81816001)(74662001)(47446002)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB321; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail186-tx2 (localhost.localdomain [127.0.0.1]) by mail186-tx2 (MessageSwitch) id 1381159130505290_19507; Mon, 7 Oct 2013 15:18:50 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.252]) by mail186-tx2.bigfish.com (Postfix) with ESMTP id 674391C004C; Mon, 7 Oct 2013 15:18:50 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 7 Oct 2013 15:18:48 +0000 Received: from BLUPR05MB321.namprd05.prod.outlook.com (10.141.24.13) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 7 Oct 2013 15:18:46 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB321.namprd05.prod.outlook.com (10.141.24.13) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 7 Oct 2013 15:18:46 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) with mapi id 15.00.0785.001; Mon, 7 Oct 2013 15:18:45 +0000 From: Stephen Hanna To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] terminology draft Thread-Index: Ac7DbebnAx1mR4QJQJScqDYRCULxQwAAoh/Q Date: Mon, 7 Oct 2013 15:18:44 +0000 Message-ID: <8ffa52a7d1cd4c1588646f875bbfdafa@BLUPR05MB323.namprd05.prod.outlook.com> References: <033301cec36f$b30c0a60$19241f20$@comcast.net> In-Reply-To: <033301cec36f$b30c0a60$19241f20$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09928BEC91 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] terminology draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:19:07 -0000 No objection. In fact, I think this is a very good idea. I support adopting this document as a SACM WG draft. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > David Harrington > Sent: Monday, October 07, 2013 11:13 AM > To: sacm@ietf.org > Subject: [sacm] terminology draft >=20 > Hi, >=20 > We presently have an individual draft containing terminology extracted > from > a previous use-cases draft. > We should probably adopt this as a WG draft, as a starting point for a > WG > terminology draft. >=20 > I can submit draft-dbh-sacm-terminology-00 as draft-ietf-sacm- > terminology-00 > before the ietf88 publication deadline. > Does anybody have any objection to my doing so? >=20 > Chairs, can you tell me to go ahead, and can you pre-approve this -00-? >=20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Adam.Montville@cisecurity.org Mon Oct 7 08:52: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 8FB5521E80BB for ; Mon, 7 Oct 2013 08:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDfcyBlwWwwx for ; Mon, 7 Oct 2013 08:52:51 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.5]) by ietfa.amsl.com (Postfix) with ESMTP id B44AF21E8093 for ; Mon, 7 Oct 2013 08:52:50 -0700 (PDT) Received: from [216.82.250.19:56431] by server-5.bemta-12.messagelabs.com id 9A/21-07788-1D8D2525; Mon, 07 Oct 2013 15:52:49 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-16.tower-87.messagelabs.com!1381161168!18240586!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 4787 invoked from network); 7 Oct 2013 15:52:49 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-16.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 7 Oct 2013 15:52:49 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Mon, 7 Oct 2013 11:52:47 -0400 From: Adam Montville To: ietfdbh , "dromasca@avaya.com" , "Waltermire, David A." Thread-Topic: [sacm] Title for SACM Use Cases Draft Thread-Index: Ac7AcLLPpnMpwtlTQT6Ha61+RvsErAA2bjwAAADuuAAABakkwAAe+j8AAGUKheA= Date: Mon, 7 Oct 2013 15:52:47 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D68736D3@CISEXCHANGE1.msisac.org.local> References: <9fddfbc984484aeda9158285be225dfa@BLUPR05MB323.namprd05.prod.outlook.com> <524EFDAE.5030807@ThreatGuard.com> <69235492DB20AC4EBBED65919EB0A2A606C1EA@XCH-BLV-401.nw.nos.boeing.com> <05BCCEB107AF88469B9F99783D47C1D68713AC@CISEXCHANGE1.msisac.org.local> <02bd01cec1bf$2e80a460$8b81ed20$@comcast.net> In-Reply-To: <02bd01cec1bf$2e80a460$8b81ed20$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Title for SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:52:56 -0000 > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Saturday, October 05, 2013 4:37 AM > To: Adam Montville; dromasca@avaya.com; Waltermire, David A. > Cc: sacm@ietf.org > Subject: RE: [sacm] Title for SACM Use Cases Draft >=20 > Hi Adam, >=20 > Did David ask you to request that others pick up the pen for the use cas= es > doc? [AWM]=20 No, but I've been unable to reach him. It seems that the contact informat= ion I have for David is NIST-related. In an effort to keep things moving = forward, I made the suggestion. > I will call David to discuss whether he needs me to take the pen, and to= get > his latest sources. >=20 > -- out of pocket -- > People operating in IETF contribute as individuals. > I have been operating out-of-pocket all the time I have been editing for= > sacm. Many contribute to IETF out-of-pocket. > The fact that David is operating out-of-pocket during the US govt shutdo= wn > shouldn't really make a difference to his IETF editing capabilities. > I would think that with the US govt shutdown, David might have MORE time= > to edit the documents. [AWM]=20 I agree. However, I also recognize that most people I know in the IETF wo= uld not be participating were it not for the funding of their employer. I= believe Dave is in this situation in terms of attendance, which you addre= ss below. >=20 > -- ietf88 -- > I do think the govt shutdown, and David's out-of-pocket situation, could= > impact David's attendance at the next meeting. > I know from Tim Polk's experience with a previous shutdown that NIST > employees are bound by a set of rules about what they are allowed to > finance on their own, or to accept as "gifts" to cover IETF meeting expe= nses. > I do not expect to attend the next meeting; I would have difficulty just= ifying > the out-of-pocket costs. > Following the recommended IETF approach, we should stimulate ML > discussion and update the document prior to the deadline. > I think David and I (and the chairs) can do that, and David and I can pr= epare > "status" slides for the meeting, and participate remotely. [AWM]=20 This sounds reasonable. >=20 > -- use cases document -- > David has been driving the discussions with the intention of updating th= e > document. > We changed the structure and content significantly from the -00- revisio= n. > We want WG reaction to the changes, and the next revision will bring the= > document closer to WG consensus preferences. > I have been deliberately letting David drive the discussions, track the = needed > changes, and edit the next revision. > We have gotten some good feedback on the list. > I have also been tracking the discussions and proposed changes, in case = I > needed to pick up the pen. > I have the xml2rfc sources for the -00- revision; I don't know if David = has a > more updated, unpublished revision of XML source. [AWM]=20 I have no idea about updated sources. >=20 > I am of the impression that WG consensus is to remove the functional > capabilities analysis from the use cases doc. > Some of the analysis might be more appropriate for the requirements doc.= >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Friday, October 04, 2013 3:33 PM > > To: Whitlock, Stephen; Gunnar Engelbach; Stephen Hanna > > Cc: sacm@ietf.org > > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > > It would be great to see as much response to use-case-specific > > discussions > as > > there is to titling and formatting :-) > > > > Unfortunately, as many of you have probably already seen, David > > Waltermire is essentially out-of-pocket during the USG shutdown, and > > I'm not sure > when > > he might be popping back up here. > > > > In light of this, it might be good for David Harrington, or someone > > else, > to pick > > up editing of the Use Case document. Any thoughts on this? > > > > Adam > > > > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > Of > > > Whitlock, Stephen > > > Sent: Friday, October 04, 2013 11:08 AM > > > To: Gunnar Engelbach; Stephen Hanna > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > > > > +1 on keeping them in one document. > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > Of > > > Gunnar Engelbach > > > Sent: Friday, October 04, 2013 10:41 AM > > > To: Stephen Hanna > > > Cc: sacm@ietf.org > > > Subject: Re: [sacm] Title for SACM Use Cases Draft > > > > > > > > > I'd like to hear from Dave and Nancy on their thinking about this, > > > but I suspect the reason for the title change has more to do with > > > the > recognition > > > that the current use cases document covers much more than use cases.= > > > > > > If that was the goal, then given the choice between change the > > > document name and break it out into other documents, a title change = is > fine. > > > > > > It's just that, as everybody who has responded so far has pointed > > > out, > > SACM > > > isn't focused just on network access. > > > > > > > > > Dave: Apologies, but I've barely had time to do more than take a > > > quick glance at your changes to the "use cases" document, so I can > > > only give a broad opinion right now. > > > > > > First: All of the text in the document is good. I expect on > > > detailed examination to find some typos and maybe some quibbles with= > > > phrasing, > > but > > > overall the current text is all good. > > > > > > Second: The restructure of the document is a help > > > > > > Third: I'm still not seeing justification for much of the contents > > > of > the > > > document, especially in the context of the SACM charter. I've got a= > > thought > > > for inserting a new chapter 3 ahead of the current one that might > > > help > -- > > > hopefully I can make some time by the start of next week to flesh > > > that > out. > > > > > > > > > > > > > > > On 10/3/2013 3:42 PM, Stephen Hanna wrote: > > > > Dave and Nancy were talking about the title for the SACM Use Cases= > > > > document. The old title was: > > > > > > > > Analysis of Security Automation and Continuous Monitoring (SACM) > > > > Use Cases > > > > > > > > The new title is: > > > > > > > > Using Security Posture Assessment to Grant Access to Enterprise > > > > Network Resources > > > > > > > > I prefer the old title. The new title implies that the only > > > > purpose of this work is to "Grant Access to Enterprise Network > Resources". > > > > There are many other purposes such as preparing reports on > > > > endpoint policy compliance, finding misconfigured endpoints so > > > > they can be fixed, etc. > > > > > > > > Thanks, > > > > > > > > Steve > > > > > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > ... > > > > . . . > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 > ... . . . From Erik.Cockrell@polycom.com Mon Oct 7 12:41: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 3B07111E8152 for ; Mon, 7 Oct 2013 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5tof4H2BQcU for ; Mon, 7 Oct 2013 12:41:11 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3439A11E811A for ; Mon, 7 Oct 2013 12:41:11 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 7 Oct 2013 12:41:10 -0700 From: "Cockrell, Erik" To: "sacm@ietf.org" Date: Mon, 7 Oct 2013 12:41:07 -0700 Thread-Topic: Final date and time for sacm at IETF 88? Thread-Index: Ac7DlSrAmvdowLJNRB2rGrqRpq0RUA== Message-ID: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [sacm] Final date and time for sacm at IETF 88? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:41:16 -0000 --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - have the date and time for sacm session(s) at IETF 88 been finalized = yet? If so, can someone send out that information? Thank you. Erik Cockrell, Product Security Engineer, Polycom Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.71= 55 | c: 512.739.4250 | f: 512.372.7142 --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All – have= the date and time for sacm session(s) at IETF 88 been finalized yet? If so= , can someone send out that information?  Thank you.

 

Erik C= ockrell, Product Security Engineer,<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#5959= 59'> Polycom Product Security Office

The holy grail of security is airtight input validation= .

7700 West Parmer Lane,= Bldg. C, Suite 100, Austin, TX 78730 | t: 512.3= 72.7155 | c: 512.739.4250 | f: 512.372.7142

 

= --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4CRPMBOXPRD07pol_-- From ietfdbh@comcast.net Mon Oct 7 13:31:22 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6E611E814C for ; Mon, 7 Oct 2013 13:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 2+BYmH8DU+Ci for ; Mon, 7 Oct 2013 13:31:17 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4611E8138 for ; Mon, 7 Oct 2013 13:31:17 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id aCGt1m0021c6gX85DLXGdr; Mon, 07 Oct 2013 20:31:16 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta23.westchester.pa.mail.comcast.net with comcast id aLXG1m00P2yZEBF3jLXGSv; Mon, 07 Oct 2013 20:31:16 +0000 From: "ietfdbh" To: "'Cockrell, Erik'" , References: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4@CRPMBOXPRD07.polycom.com> In-Reply-To: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4@CRPMBOXPRD07.polycom.com> Date: Mon, 7 Oct 2013 16:31:20 -0400 Message-ID: <036701cec39c$2ec99380$8c5cba80$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0368_01CEC37A.A7B9EF50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH3hCgrV72wNVPSnYLFIHTOXwPQM5mYJjPg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381177876; bh=XDnu/L1NjzVaaJFSdAFUXPUowbFFp6Pz110zo2AUxUE=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=tNvB5Q04ZhAwoEnJ9c5uiJDHn5Ac/2YdWP9Uecw33Jrb/NjK9gnMk4DrCKPIp9Ry0 IwFYlw6hCS54axbZhiPDYVCHRVS/twxCPJHjfQhkqH0VyG4yklqu617pPhqMV0t3N1 KAm5qzZiL1DsYYdEc0mWvB86NINzHYZBvcGV5uYY94p8hkLBmwQmOokK/Z9OL5T3Hv YVjxENApxSwxRPMaKngjUgqw+22bibTMuUhQB3T40A3Sy1IhRL/3+hRF/oVSRnikvE 84YSvHUAIof+yaGMoDYEKHb2LGIaABoRwZdgDd2zCP4Cds3+1Clsm3/AgOVTcetVwi npgfzS3xYMaug== Subject: Re: [sacm] Final date and time for sacm at IETF 88? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:31:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0368_01CEC37A.A7B9EF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Erik, The ietf88 agenda has not been finalized yet. Here is where you can find the most current version of the agenda: http://datatracker.ietf.org/meeting/agenda/ The standard warning is that "IETF agendas are subject to change, up to and during the meeting." Hence, you should plan to attend the whole week. Some sessions possibly relevant to sacm: The plenary technical presentation (Wednesday 0900) is about Internet hardening in light of pervasive Internet monitoring. Bruce Schneier introduces the problem, and Brian Carpenter and Stephen Farrell talking about IETF activities, past and future. This is followed by a BOF related to pervasive monitoring. SAAG (thurs 1300) is the Security Area's open meeting, which can be about anything related to internet security. Service function chaining (thurs 1520) BOF will discuss an architecture for service chaining, that will likely involve firewall and ids functionality, as well as forwarding functionality. SCIM (fri 1120) talks about cross-domain identity management. The behave WG (not currently scheduled) is discussing NAT logging via syslog, ipfix, and snmp. These might be important for sacm monitoring. Netconf (mon 0900) is discussing Netconf-over-tls plus a call-home mechanism to allow server initiated service establishment for SSH and TLS. Netmod (wed 1550-1720) is discussing how to make YANG independent from Netconf, so it can be used to model information withut being bound by Netconf constraints. YANG has been suggested as a possible protocol for sacm modeling. I don't see mile or nea on the schedule. Hope this helps, David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cockrell, Erik Sent: Monday, October 07, 2013 3:41 PM To: sacm@ietf.org Subject: [sacm] Final date and time for sacm at IETF 88? All - have the date and time for sacm session(s) at IETF 88 been finalized yet? If so, can someone send out that information? Thank you. Erik Cockrell, Product Security Engineer, Polycom Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.7155 | c: 512.739.4250 | f: 512.372.7142 ------=_NextPart_000_0368_01CEC37A.A7B9EF50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Erik,

 

The ietf88 agenda has = not been finalized yet.

Here is where you can find the most current = version of the agenda:

http://datatracker.ietf.org/meeting/agenda/<= /o:p>

 

The standard warning is = that “IETF agendas = are subject to change, up to and during the = meeting.”

Hence, you should plan to attend the whole = week.

 

Some sessions possibly = relevant to sacm:

 

The plenary technical = presentation (Wednesday 0900) is about Internet hardening in light of = pervasive Internet monitoring.

Bruce Schneier = introduces the problem, and Brian Carpenter and Stephen Farrell talking = about IETF activities, past and future.

This is followed by a = BOF related to pervasive monitoring.

 

SAAG (thurs 1300) is the = Security Area’s  open meeting, which can be about anything = related to internet security.

Service function = chaining (thurs 1520) BOF will discuss an architecture for service = chaining, that will likely involve firewall and ids functionality, as = well as forwarding functionality.

SCIM (fri 1120) talks = about cross-domain identity management.

The behave WG (not = currently scheduled) is discussing NAT logging via syslog, ipfix, and = snmp. These might be important for sacm = monitoring.

Netconf (mon 0900) is discussing = Netconf-over-tls plus a call-home mechanism to allow server initiated = service establishment for SSH and TLS.

Netmod (wed 1550-1720) = is discussing how to make YANG independent from Netconf, so it can be = used to model information withut being bound by Netconf constraints. = YANG has been suggested as a possible protocol for sacm = modeling.

 

I don’t see mile = or nea on the schedule.

 

Hope this = helps,

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Cockrell, Erik
Sent: Monday, October 07, 2013 3:41 = PM
To: sacm@ietf.org
Subject: [sacm] Final date and = time for sacm at IETF 88?

 

All – = have the date and time for sacm session(s) at IETF 88 been finalized = yet? If so, can someone send out that information?  Thank you. =

 

Erik Cockrell, Product Se= curity Engineer, Polycom Product Security Office

The= holy grail of security is airtight input = validation.

7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 = | = t: 512.372.7155 | c: 512.739.4250 | f: 512.372.7142

 

------=_NextPart_000_0368_01CEC37A.A7B9EF50-- From dromasca@avaya.com Tue Oct 8 04:37: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 3F79811E80DE for ; Tue, 8 Oct 2013 04:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 PDYhZ9Mg17ZN for ; Tue, 8 Oct 2013 04:37:10 -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 4A90F11E81AF for ; Tue, 8 Oct 2013 04:37:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFADztU1KHCzI1/2dsb2JhbABWA4JmIThSwSKBHxZ0giUBAQEBAwEBAQ8oNBcEAgEIDQEDBAEBCxQJBycLFAkIAQEEARIIGodSAw8BC51fkn0IiVkTBI8RIRcGC4MOgQQDnl6LI4Mkgio X-IronPort-AV: E=Sophos;i="4.90,1056,1371096000"; d="scan'208";a="31620505" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Oct 2013 07:37:08 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Oct 2013 07:28:07 -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.03.0146.000; Tue, 8 Oct 2013 13:37:01 +0200 From: "Romascanu, Dan (Dan)" To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] terminology draft Thread-Index: Ac7DbebnAx1mR4QJQJScqDYRCULxQwArEO0w Date: Tue, 8 Oct 2013 11:37:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12900DE5@AZ-FFEXMB04.global.avaya.com> References: <033301cec36f$b30c0a60$19241f20$@comcast.net> In-Reply-To: <033301cec36f$b30c0a60$19241f20$@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] terminology draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:37:16 -0000 I have pre-approved draft-ietf-sacm-terminology.=20 I do not see a problem with this action because this is derived from what i= s now draft-ietf-sacm-use-cases. However, if somebody has concerns please b= ring them up.=20 Thanks and Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > David Harrington > Sent: Monday, October 07, 2013 6:13 PM > To: sacm@ietf.org > Subject: [sacm] terminology draft >=20 > Hi, >=20 > We presently have an individual draft containing terminology extracted > from a previous use-cases draft. > We should probably adopt this as a WG draft, as a starting point for a > WG terminology draft. >=20 > I can submit draft-dbh-sacm-terminology-00 as draft-ietf-sacm- > terminology-00 before the ietf88 publication deadline. > Does anybody have any objection to my doing so? >=20 > Chairs, can you tell me to go ahead, and can you pre-approve this -00-? >=20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Erik.Cockrell@polycom.com Tue Oct 8 07:28: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 E93E921E81C0 for ; Tue, 8 Oct 2013 07:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhtl98tmtQm9 for ; Tue, 8 Oct 2013 07:28:15 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA7021E81F3 for ; Tue, 8 Oct 2013 07:28:05 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 8 Oct 2013 07:26:44 -0700 From: "Cockrell, Erik" To: ietfdbh , "sacm@ietf.org" Date: Tue, 8 Oct 2013 07:26:43 -0700 Thread-Topic: [sacm] Final date and time for sacm at IETF 88? Thread-Index: AQH3hCgrV72wNVPSnYLFIHTOXwPQM5mYJjPggAE2RSA= Message-ID: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE9B1@CRPMBOXPRD07.polycom.com> References: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4@CRPMBOXPRD07.polycom.com> <036701cec39c$2ec99380$8c5cba80$@comcast.net> In-Reply-To: <036701cec39c$2ec99380$8c5cba80$@comcast.net> 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_6E789DB94EAF0A4D979B56F5C47D0FBD010EE9B1CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [sacm] Final date and time for sacm at IETF 88? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 14:28:20 -0000 --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE9B1CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes thanks very much From: ietfdbh [mailto:ietfdbh@comcast.net] Sent: Monday, October 07, 2013 3:31 PM To: Cockrell, Erik; sacm@ietf.org Subject: RE: [sacm] Final date and time for sacm at IETF 88? Hi Erik, The ietf88 agenda has not been finalized yet. Here is where you can find the most current version of the agenda: http://datatracker.ietf.org/meeting/agenda/ The standard warning is that "IETF agendas are subject to change, up to and= during the meeting." Hence, you should plan to attend the whole week. Some sessions possibly relevant to sacm: The plenary technical presentation (Wednesday 0900) is about Internet harde= ning in light of pervasive Internet monitoring. Bruce Schneier introduces the problem, and Brian Carpenter and Stephen Farr= ell talking about IETF activities, past and future. This is followed by a BOF related to pervasive monitoring. SAAG (thurs 1300) is the Security Area's open meeting, which can be about = anything related to internet security. Service function chaining (thurs 1520) BOF will discuss an architecture for= service chaining, that will likely involve firewall and ids functionality,= as well as forwarding functionality. SCIM (fri 1120) talks about cross-domain identity management. The behave WG (not currently scheduled) is discussing NAT logging via syslo= g, ipfix, and snmp. These might be important for sacm monitoring. Netconf (mon 0900) is discussing Netconf-over-tls plus a call-home mechanis= m to allow server initiated service establishment for SSH and TLS. Netmod (wed 1550-1720) is discussing how to make YANG independent from Netc= onf, so it can be used to model information withut being bound by Netconf c= onstraints. YANG has been suggested as a possible protocol for sacm modelin= g. I don't see mile or nea on the schedule. Hope this helps, David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Cockrell, Erik Sent: Monday, October 07, 2013 3:41 PM To: sacm@ietf.org Subject: [sacm] Final date and time for sacm at IETF 88? All - have the date and time for sacm session(s) at IETF 88 been finalized = yet? If so, can someone send out that information? Thank you. Erik Cockrell, Product Security Engineer, Polycom Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.71= 55 | c: 512.739.4250 | f: 512.372.7142 --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE9B1CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes thanks very much

 

<= p class=3DMsoNormal>From: ietfdbh [mailto:ietfdbh@comcast.net]
Sent: Monday, October 07, 2013 3:31 PM
To: Cockrell, Erik; sacm@ietf= .org
Subject: RE: [sacm] Final date and time for sacm at IETF 88?=

 

Hi Erik,

 

The ietf88 agenda h= as not been finalized yet.

Here is where you can find the most current version= of the agenda:

http:/= /datatracker.ietf.org/meeting/agenda/

 

The standard warning is that = 220;IETF agendas are subject to change, up to and during the meeting.= ”

=

Hence, you should plan t= o attend the whole week.

 

Some sessions possibly relevant to sacm:

 =

The ple= nary technical presentation (Wednesday 0900) is about Internet hardening in= light of pervasive Internet monitoring.

Bruce Schneier introduces the problem= , and Brian Carpenter and Stephen Farrell talking about IETF activities, pa= st and future.

This is followed by a BOF related to pervasive monitoring.=

&n= bsp;

SAA= G (thurs 1300) is the Security Area’s  open meeting, which can b= e about anything related to internet security.

Service function chaining (thur= s 1520) BOF will discuss an architecture for service chaining, that will li= kely involve firewall and ids functionality, as well as forwarding function= ality.

SCIM (fri 1120) talks about cross-domain identity management.

The behave W= G (not currently scheduled) is discussing NAT logging via syslog, ipfix, an= d snmp. These might be important for sacm monitoring.

=

Netconf (mon 0900) is di= scussing Netconf-over-tls plus a call-home mechanism to allow server initia= ted service establishment for SSH and TLS.

Netmod (wed 1550-1720) is discussin= g how to make YANG independent from Netconf, so it can be used to model inf= ormation withut being bound by Netconf constraints. YANG has been suggested= as a possible protocol for sacm modeling.

 

I don’t see mile or nea o= n the schedule.

 

Hope this helps,

David Harrington

ietfdbh@comcast.net<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:= #1F497D'>

+1-603-828-1= 401

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

From: s= acm-bounces@ietf.org [mailto:s= acm-bounces@ietf.org] On Behalf Of Cockrell, Erik
Sent: Monday, October 07, 2013 3:41 PM
To: sacm@ietf.org
Subject: [sacm] Final date and time for = sacm at IETF 88?

 

All – have the date and time fo= r sacm session(s) at IETF 88 been finalized yet? If so, can someone send ou= t that information?  Thank you.

 

Erik Cockrell, Product Security Engineer, Poly= com Product Security Office

T= he holy grail of security is airtight input validation.

7700 West Parmer Lane, Bldg. C, Suite 100, = Austin, TX 78730 | t: 512.372.7155 | c: 512.739.42= 50 | f: 512.372.7142

&nbs= p;

= --_000_6E789DB94EAF0A4D979B56F5C47D0FBD010EE9B1CRPMBOXPRD07pol_-- From Adam.Montville@cisecurity.org Wed Oct 9 14:33:10 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD17421E81D3 for ; Wed, 9 Oct 2013 14:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhyQVepuN21C for ; Wed, 9 Oct 2013 14:33:06 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.112]) by ietfa.amsl.com (Postfix) with ESMTP id D926C21E81A0 for ; Wed, 9 Oct 2013 14:33:05 -0700 (PDT) Received: from [216.82.253.227:2901] by server-16.bemta-7.messagelabs.com id 19/B5-13150-09BC5525; Wed, 09 Oct 2013 21:33:04 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-170.messagelabs.com!1381354383!22654028!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 24747 invoked from network); 9 Oct 2013 21:33:04 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 9 Oct 2013 21:33:04 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Wed, 9 Oct 2013 17:33:02 -0400 From: Adam Montville To: ietfdbh , "'Cockrell, Erik'" , "sacm@ietf.org" Thread-Topic: [sacm] Final date and time for sacm at IETF 88? Thread-Index: Ac7DlSrAmvdowLJNRB2rGrqRpq0RUAAKIqkAAF5QwjQ= Date: Wed, 9 Oct 2013 21:33:01 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6877B24@CISEXCHANGE1.msisac.org.local> References: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4@CRPMBOXPRD07.polycom.com>, <036701cec39c$2ec99380$8c5cba80$@comcast.net> In-Reply-To: <036701cec39c$2ec99380$8c5cba80$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D6877B24CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [sacm] Final date and time for sacm at IETF 88? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:33:11 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D6877B24CISEXCHANGE1msisa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mile won't be having a meeting this time around, and I don't believe nea i= s either. Agenda is supposed to be finalized sometime on Friday. It looks like we'r= e presently in the last slot of the day on Monday, but this is, of course,= subject to change. Adam ________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of ietfdbh [= ietfdbh@comcast.net] Sent: Monday, October 07, 2013 1:31 PM To: 'Cockrell, Erik'; sacm@ietf.org Subject: Re: [sacm] Final date and time for sacm at IETF 88? Hi Erik, The ietf88 agenda has not been finalized yet. Here is where you can find the most current version of the agenda: http://datatracker.ietf.org/meeting/agenda/ The standard warning is that =93IETF agendas are subject to change, up to = and during the meeting.=94 Hence, you should plan to attend the whole week. Some sessions possibly relevant to sacm: The plenary technical presentation (Wednesday 0900) is about Internet hard= ening in light of pervasive Internet monitoring. Bruce Schneier introduces the problem, and Brian Carpenter and Stephen Far= rell talking about IETF activities, past and future. This is followed by a BOF related to pervasive monitoring. SAAG (thurs 1300) is the Security Area=92s open meeting, which can be abo= ut anything related to internet security. Service function chaining (thurs 1520) BOF will discuss an architecture fo= r service chaining, that will likely involve firewall and ids functionalit= y, as well as forwarding functionality. SCIM (fri 1120) talks about cross-domain identity management. The behave WG (not currently scheduled) is discussing NAT logging via sysl= og, ipfix, and snmp. These might be important for sacm monitoring. Netconf (mon 0900) is discussing Netconf-over-tls plus a call-home mechani= sm to allow server initiated service establishment for SSH and TLS. Netmod (wed 1550-1720) is discussing how to make YANG independent from Net= conf, so it can be used to model information withut being bound by Netconf= constraints. YANG has been suggested as a possible protocol for sacm mode= ling. I don=92t see mile or nea on the schedule. Hope this helps, David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Co= ckrell, Erik Sent: Monday, October 07, 2013 3:41 PM To: sacm@ietf.org Subject: [sacm] Final date and time for sacm at IETF 88? All =96 have the date and time for sacm session(s) at IETF 88 been finaliz= ed yet? If so, can someone send out that information? Thank you. Erik Cockrell, Product Security Engineer, Polycom Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.7= 155 | c: 512.739.4250 | f: 512.372.7142 ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D6877B24CISEXCHANGE1msisa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Mile won't be having a meeting this time around, and I don't belie= ve nea is either.

Agenda is supposed to be finalized sometime on Friday.  It looks= like we're presently in the last slot of the day on Monday, but this is, = of course, subject to change.

Adam

From: sacm-bounces@ietf.org [sacm-boun= ces@ietf.org] on behalf of ietfdbh [ietfdbh@comcast.net]
Sent: Monday, October 07, 2013 1:31 PM
To: 'Cockrell, Erik'; sacm@ietf.org
Subject: Re: [sacm] Final date and time for sacm at IETF 88?

Hi Erik,

 

The ietf88 agenda has= not been finalized yet.

Here is where you can= find the most current version of the agenda:

http://datatracker.ie= tf.org/meeting/agenda/

 

The standard warning = is that =93IETF agendas are subject to change,= up to and during the meeting.=94

Hence, you should pla= n to attend the whole week.

 

Some sessions possibl= y relevant to sacm:

 

The plenary technical= presentation (Wednesday 0900) is about Internet hardening in light of per= vasive Internet monitoring.

Bruce Schneier introd= uces the problem, and Brian Carpenter and Stephen Farrell talking about IE= TF activities, past and future.

This is followed by a= BOF related to pervasive monitoring.

 

SAAG (thurs 1300) is = the Security Area=92s  open meeting, which can be about anything rela= ted to internet security.

Service function chai= ning (thurs 1520) BOF will discuss an architecture for service chaining, t= hat will likely involve firewall and ids functionality, as well as forward= ing functionality.

SCIM (fri 1120) talks= about cross-domain identity management.

The behave WG (not cu= rrently scheduled) is discussing NAT logging via syslog, ipfix, and snmp. = These might be important for sacm monitoring.

Netconf (mon 0900) is= discussing Netconf-over-tls plus a call-home mechanism to allow server in= itiated service establishment for SSH and TLS.

Netmod (wed 1550-1720= ) is discussing how to make YANG independent from Netconf, so it can be us= ed to model information withut being bound by Netconf constraints. YANG ha= s been suggested as a possible protocol for sacm modeling.

 

I don=92t see mile or= nea on the schedule.

 

Hope this helps,

David Harrington=

ietfdbh@comcast.net

+1-603-828-1401

From: sac= m-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cockrell, Erik
Sent: Monday, October 07, 2013 3:41 PM
To: sacm@ietf.org
Subject: [sacm] Final date and time for sacm at IETF 88?

=

 

All =96 have the date and time for sacm session(s) = at IETF 88 been finalized yet? If so, can someone send out that informatio= n?  Thank you.

 

Erik Cockrell= , Product Security Engineer, Polycom Product Security Office<= /p>

The holy grail of securi= ty is airtight input validation.

7700 West Parmer Lane, = Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.7155 | c: 512.739.4250 | f: 512.372.7142

 


...

. . .
--_000_05BCCEB107AF88469B9F99783D47C1D6877B24CISEXCHANGE1msisa_-- From shanna@juniper.net Wed Oct 9 14:37:17 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A656821E81E3 for ; Wed, 9 Oct 2013 14:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.265 X-Spam-Level: X-Spam-Status: No, score=-105.265 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 c2LRiGukGO71 for ; Wed, 9 Oct 2013 14:37:11 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id A385C21E81E5 for ; Wed, 9 Oct 2013 14:37:10 -0700 (PDT) Received: from mail22-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE032.bigfish.com (10.236.130.95) with Microsoft SMTP Server id 14.1.225.22; Wed, 9 Oct 2013 21:37:09 +0000 Received: from mail22-co9 (localhost [127.0.0.1]) by mail22-co9-R.bigfish.com (Postfix) with ESMTP id E7828E00C3; Wed, 9 Oct 2013 21:37:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz9371Ic85fhc430Ic25dL4015I328cMzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail22-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(502244003)(377454003)(129404003)(497574002)(164054003)(189002)(199002)(59766001)(77982001)(74316001)(76786001)(19580395003)(76796001)(83322001)(19580405001)(33646001)(16236675002)(54316002)(31966008)(74706001)(19300405004)(74366001)(76482001)(77096001)(19609705001)(76576001)(56816003)(63696002)(74876001)(47446002)(56776001)(74662001)(74502001)(15975445006)(81542001)(81342001)(47736001)(49866001)(4396001)(65816001)(47976001)(50986001)(80022001)(66066001)(53806001)(54356001)(85306002)(83072001)(46102001)(51856001)(81816001)(79102001)(15202345003)(69226001)(81686001)(18717965001)(80976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB323; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail22-co9 (localhost.localdomain [127.0.0.1]) by mail22-co9 (MessageSwitch) id 1381354626955988_16594; Wed, 9 Oct 2013 21:37:06 +0000 (UTC) Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.232]) by mail22-co9.bigfish.com (Postfix) with ESMTP id DA4112007D; Wed, 9 Oct 2013 21:37:06 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 9 Oct 2013 21:37:06 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 9 Oct 2013 21:37:03 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 9 Oct 2013 21:37:01 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) with mapi id 15.00.0785.001; Wed, 9 Oct 2013 21:37:01 +0000 From: Stephen Hanna To: Adam Montville , ietfdbh , "'Cockrell, Erik'" , "sacm@ietf.org" Thread-Topic: [sacm] Final date and time for sacm at IETF 88? Thread-Index: Ac7DlSrAmvdowLJNRB2rGrqRpq0RUAABwOUAAGa8s4AAABg3IA== Date: Wed, 9 Oct 2013 21:37:01 +0000 Message-ID: References: <6E789DB94EAF0A4D979B56F5C47D0FBD010EE8F4@CRPMBOXPRD07.polycom.com>, <036701cec39c$2ec99380$8c5cba80$@comcast.net> <05BCCEB107AF88469B9F99783D47C1D6877B24@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6877B24@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0994F5E0C5 Content-Type: multipart/alternative; boundary="_000_fb8420b3b02b430a94137210c44f6608BLUPR05MB323namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Final date and time for sacm at IETF 88? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:37:17 -0000 --_000_fb8420b3b02b430a94137210c44f6608BLUPR05MB323namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable nea will not be meeting at IETF 88. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Wednesday, October 09, 2013 5:33 PM To: ietfdbh; 'Cockrell, Erik'; sacm@ietf.org Subject: Re: [sacm] Final date and time for sacm at IETF 88? Mile won't be having a meeting this time around, and I don't believe nea is= either. Agenda is supposed to be finalized sometime on Friday. It looks like we're= presently in the last slot of the day on Monday, but this is, of course, s= ubject to change. Adam ________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] on behalf of ietfdbh [ietfdbh@comcast.net] Sent: Monday, October 07, 2013 1:31 PM To: 'Cockrell, Erik'; sacm@ietf.org Subject: Re: [sacm] Final date and time for sacm at IETF 88? Hi Erik, The ietf88 agenda has not been finalized yet. Here is where you can find the most current version of the agenda: http://datatracker.ietf.org/meeting/agenda/ The standard warning is that "IETF agendas are subject to change, up to and= during the meeting." Hence, you should plan to attend the whole week. Some sessions possibly relevant to sacm: The plenary technical presentation (Wednesday 0900) is about Internet harde= ning in light of pervasive Internet monitoring. Bruce Schneier introduces the problem, and Brian Carpenter and Stephen Farr= ell talking about IETF activities, past and future. This is followed by a BOF related to pervasive monitoring. SAAG (thurs 1300) is the Security Area's open meeting, which can be about = anything related to internet security. Service function chaining (thurs 1520) BOF will discuss an architecture for= service chaining, that will likely involve firewall and ids functionality,= as well as forwarding functionality. SCIM (fri 1120) talks about cross-domain identity management. The behave WG (not currently scheduled) is discussing NAT logging via syslo= g, ipfix, and snmp. These might be important for sacm monitoring. Netconf (mon 0900) is discussing Netconf-over-tls plus a call-home mechanis= m to allow server initiated service establishment for SSH and TLS. Netmod (wed 1550-1720) is discussing how to make YANG independent from Netc= onf, so it can be used to model information withut being bound by Netconf c= onstraints. YANG has been suggested as a possible protocol for sacm modelin= g. I don't see mile or nea on the schedule. Hope this helps, David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Cockrell, Erik Sent: Monday, October 07, 2013 3:41 PM To: sacm@ietf.org Subject: [sacm] Final date and time for sacm at IETF 88? All - have the date and time for sacm session(s) at IETF 88 been finalized = yet? If so, can someone send out that information? Thank you. Erik Cockrell, Product Security Engineer, Polycom Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.71= 55 | c: 512.739.4250 | f: 512.372.7142 ... . . . --_000_fb8420b3b02b430a94137210c44f6608BLUPR05MB323namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

nea will not be meetin= g at IETF 88.

 

Thanks,

 

Steve

 

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, October 09, 2013 5:33 PM
To: ietfdbh; 'Cockrell, Erik'; sacm@ietf.org
Subject: Re: [sacm] Final date and time for sacm at IETF 88?

 

Mile won't be having a meeti= ng this time around, and I don't believe nea is either.

 

Agenda is supposed to be fin= alized sometime on Friday.  It looks like we're presently in the last = slot of the day on Monday, but this is, of course, subject to change.

 

Adam

 

From: sacm-bounces@ietf.org [sacm-bo= unces@ietf.org] on behalf of ietfdbh [ietfdbh@comcast.net]
Sent: Monday, October 07, 2013 1:31 PM
To: 'Cockrell, Erik'; sacm@ietf.org=
Subject: Re: [sacm] Final date and time for sacm at IETF 88?<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:black">

Hi Erik,

 

The ietf88 agenda has = not been finalized yet.

Here is where you can = find the most current version of the agenda:

http://datatracker.ietf.org/meeting/agend= a/

 

The standard warning i= s that “IETF agendas are subjec= t to change, up to and during the meeting.”

Hence, you should plan= to attend the whole week.

 

Some sessions possibly= relevant to sacm:

 

The plenary technical = presentation (Wednesday 0900) is about Internet hardening in light of perva= sive Internet monitoring.

Bruce Schneier introdu= ces the problem, and Brian Carpenter and Stephen Farrell talking about IETF= activities, past and future.=

This is followed by a = BOF related to pervasive monitoring.

 

SAAG (thurs 1300) is t= he Security Area’s  open meeting, which can be about anything re= lated to internet security.

Service function chain= ing (thurs 1520) BOF will discuss an architecture for service chaining, tha= t will likely involve firewall and ids functionality, as well as forwarding= functionality.

SCIM (fri 1120) talks = about cross-domain identity management.<= o:p>

The behave WG (not cur= rently scheduled) is discussing NAT logging via syslog, ipfix, and snmp. Th= ese might be important for sacm monitoring.

Netconf (mon 0900) is = discussing Netconf-over-tls plus a call-home mechanism to allow server init= iated service establishment for SSH and TLS.

Netmod (wed 1550-1720)= is discussing how to make YANG independent from Netconf, so it can be used= to model information withut being bound by Netconf constraints. YANG has b= een suggested as a possible protocol for sacm modeling.

 

I don’t see mile= or nea on the schedule.

 

Hope this helps,

David Harrington

ietfdbh@comcast.net<= o:p>

+1-603-828-1401<= span style=3D"color:black">

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cockrell, Erik
Sent: Monday, October 07, 2013 3:41 PM
To: sacm@ietf.org
Subject: [sacm] Final date and time for sacm at IETF 88?

 =

All – have the dat= e and time for sacm session(s) at IETF 88 been finalized yet? If so, can so= meone send out that information?  Thank you.

 =

Erik Cockrell= , Product Security Engineer, Polycom Product Security Office

The holy grail of security i= s airtight input validation.

7700 West Parmer Lane, Bldg= . C, Suite 100, Austin, TX 78730 | t: 512.372.7155 | c: 512.739.4250 | f: 512.372.7142

 =


...


. . .

--_000_fb8420b3b02b430a94137210c44f6608BLUPR05MB323namprd05pro_-- From ncamwing@cisco.com Mon Oct 14 11:43:25 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8632E21E80EE for ; Mon, 14 Oct 2013 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBVIgRJVjx8c for ; Mon, 14 Oct 2013 11:43:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 840C911E814B for ; Mon, 14 Oct 2013 11:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1419; q=dns/txt; s=iport; t=1381776200; x=1382985800; h=from:to:subject:date:message-id:mime-version; bh=0bSqh2Sqyc+kHuu0T/v0dgfKsTEXKzWp7M+KMFRaU+M=; b=G1ZAqKwS2+SVgF6u1uUwTkU/Svp54qUlWVHUT9T9jozk/83Bd0peZV5y b5EfzvWrvSnvKh5zgbxnzxjHra/sK+maI+gPIILA8YV/sIx0pxIT9q6OT HY+wogCqDSMN7c4mkLrgkjED7lX+FQgunmToWwp0xNh0aqflBuya2noU+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGAM06XFKtJXG8/2dsb2JhbABZgkNEOFK5QYg5gSYWbQeCHAsBBIELAQsBHlYnBBsBh30MnA6hUY8gg1eBBAOqB4Mkgik X-IronPort-AV: E=Sophos;i="4.93,493,1378857600"; d="scan'208,217";a="272055115" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 14 Oct 2013 18:43:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9EIhEep027332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Oct 2013 18:43:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 13:43:14 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "sacm@ietf.org" Thread-Topic: Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwzng== Date: Mon, 14 Oct 2013 18:43:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.69.71] Content-Type: multipart/alternative; boundary="_000_B80278DF1B7C814184086F4A6ECB311532F16F4Cxmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 18:43:25 -0000 --_000_B80278DF1B7C814184086F4A6ECB311532F16F4Cxmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As the submission deadline is today, I've posted a skeleton draft to help u= s drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-s= acm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. --_000_B80278DF1B7C814184086F4A6ECB311532F16F4Cxmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <2C0B2364A0E59D4B951637F3E36020E4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Folks,

As the submission deadline is today, I've posted a skeleton draft to h= elp us drive the Requirements just now: http://www.ietf.org/id/draft-= camwinget-sacm-requirements-00.txt

There's plenty to discuss!

Thanks, Nancy.
--_000_B80278DF1B7C814184086F4A6ECB311532F16F4Cxmbalnx02ciscoc_-- From gunnar.engelbach@threatguard.com Mon Oct 14 12:41:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE18021E80FB for ; Mon, 14 Oct 2013 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZg--0uXSxvN for ; Mon, 14 Oct 2013 12:41:19 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3821F93BF for ; Mon, 14 Oct 2013 12:41:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=GEnlFHUC5o2oVrUO5YbRUG2WSvXlNZO4ArDy5ZaUFs6XXpYWr/QYTR38DOLhlxJnHgDZo2T18Z12p3uKQuzXfbvJ3vEQdnR6l0/wsn/xNTF0ClCB4oAOtUQSt/TGCyMM; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 3741 invoked from network); 14 Oct 2013 12:43:02 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Oct 2013 12:43:02 -0700 Message-ID: <525C48DF.8050500@ThreatGuard.com> Date: Mon, 14 Oct 2013 15:41:19 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:41:24 -0000 Nancy, is this just a strawman to meet the document deadline? The role of SACM as you've outlined here has changed considerably from the conversations we've been having for the past 18 months (ish). Most notably is the assumption that NEA will now be the only assessment methodology. Is that the direction SACM has decided to go? If you just need a quick ASCII architecture and text to C&P into your skeleton, how about Dave Waltermire's original draft: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: > Folks, > > As the submission deadline is today, I've posted a skeleton draft to > help us drive the Requirements just now: > http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt > > There's plenty to discuss! > > Thanks, Nancy. > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From Kent_Landfield@mcafee.com Mon Oct 14 12:53: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 5BA3721E80DC for ; Mon, 14 Oct 2013 12:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fibzuwFLpj15 for ; Mon, 14 Oct 2013 12:53:07 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2A11E818E for ; Mon, 14 Oct 2013 12:53:05 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 5efe_cdf6_ed3e28e9_194f_4c01_b133_327b3389a8ff; Mon, 14 Oct 2013 14:53:04 -0500 Received: from MIVEXAPP2N1.corp.nai.org (10.48.48.71) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Oct 2013 15:52:24 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.249]) by MIVEXAPP2N1.corp.nai.org ([169.254.2.151]) with mapi id 14.03.0158.001; Mon, 14 Oct 2013 15:52:24 -0400 From: To: , , Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOyRbmkHa6GnwwFUaNPfiFYzt+xA== Date: Mon, 14 Oct 2013 19:52:23 +0000 Message-ID: In-Reply-To: <525C48DF.8050500@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_CE81B3E2560EBkentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:53:18 -0000 --_000_CE81B3E2560EBkentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are other means to accomplish assessments and NEA was not going to be= the only direction considered. This would be a direction change from what= has been discussed in all the side meetings and BOFs leading up to the SAC= M WG creation. If this is just a document to meet the deadline, ok. I am not aware of any consensus around NEA being the sole focus or the only= assessment methodology. And if that was brought up for consideration I wou= ld vote against it. There are many deployed products today that use other = means for assessment that have proven effective. We do need to get some of= that into this working group but the focus has been on getting the archite= cture document nailed down=85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Gunnar Engelbach > Organization: ThreatGuard, Inc. Date: Monday, October 14, 2013 2:41 PM To: "Nancy Cam-Winget (ncamwing)" >, "sacm@ietf.org" > Subject: Re: [sacm] Rough work in progress for Requirements Nancy, is this just a strawman to meet the document deadline? The role of SACM as you've outlined here has changed considerably from the conversations we've been having for the past 18 months (ish). Most notably is the assumption that NEA will now be the only assessment methodology. Is that the direction SACM has decided to go? If you just need a quick ASCII architecture and text to C&P into your skeleton, how about Dave Waltermire's original draft: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: Folks, As the submission deadline is today, I've posted a skeleton draft to help us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CE81B3E2560EBkentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
There are other means to accomplish assessments and NEA was not going = to be the only direction considered.  This would be a direction change= from what has been discussed in all the side meetings and BOFs leading up = to the SACM WG creation.  If this is just a document to meet the deadline, ok. 

I am not aware of any consensus around NEA being the sole focus or the= only assessment methodology. And if that was brought up for consideration = I would vote against it.  There are many deployed products today that = use other means for assessment that have proven effective.  We do need to get some of that into this working g= roup but the focus has been on getting the architecture document nailed dow= n=85

Kent Landfield

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

From: Gunnar Engelbach <gunnar.engelbach@threatguard.c= om>
Organization: ThreatGuard, Inc.
Date: Monday, October 14, 2013 2:41= PM
To: "Nancy Cam-Winget (ncamwin= g)" <ncamwing@cisco.com&g= t;, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Rough work in p= rogress for Requirements



Nancy, is this just a strawman to meet the document deadline?

The role of SACM as you've outlined here has changed considerably from=
the conversations we've been having for the past 18 months (ish).

Most notably is the assumption that NEA will now be the only assessmen= t
methodology.  Is that the direction SACM has decided to go?<= /div>


If you just need a quick ASCII architecture and text to C&P into y= our
skeleton, how about Dave Waltermire's original draft:






On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote:
Folks,

As the submission deadline is today, I've posted a skeleton draft to
help us drive the Requirements just now:
http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt

There's plenty to discuss!

Thanks, Nancy.


_______________________________________________
sacm mailing list

_______________________________________________
sacm mailing list

 --_000_CE81B3E2560EBkentlandfieldmcafeecom_-- From internet-drafts@ietf.org Mon Oct 14 10:59:40 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ED211E8152; Mon, 14 Oct 2013 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 fZXsQNFIWLSo; Mon, 14 Oct 2013 10:59:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C7C21F9FB4; Mon, 14 Oct 2013 10:59:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014175937.11455.94679.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 10:59:37 -0700 X-Mailman-Approved-At: Mon, 14 Oct 2013 13:29:43 -0700 Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 17:59:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Security Automation and Continuous Monito= ring Working Group of the IETF. Title : Terminology for Security Assessment Author(s) : David Waltermire Adam W. Montville David Harrington Filename : draft-ietf-sacm-terminology-00.txt Pages : 7 Date : 2013-10-14 Abstract: This memo documents terminology used in the documents produced by the SACM WG (Security Automation and Continuous Monitoring). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-terminology-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 14 13:27: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 C534C11E818E; Mon, 14 Oct 2013 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 VGgVhVjwiBJY; Mon, 14 Oct 2013 13:27:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6329E21F9D1B; Mon, 14 Oct 2013 13:27:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014202751.11509.1119.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 13:27:51 -0700 X-Mailman-Approved-At: Mon, 14 Oct 2013 13:29:43 -0700 Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 20:27:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Security Automation and Continuous Monito= ring Working Group of the IETF. Title : Endpoint Security Posture Assessment - Enterprise Use Ca= ses Author(s) : David Waltermire David Harrington Filename : draft-ietf-sacm-use-cases-02.txt Pages : 11 Date : 2013-10-14 Abstract: This memo documents a sampling of use cases for securely aggregating configuration and operational data and assessing that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and assessing data relevant to security posture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfdbh@comcast.net Mon Oct 14 13:39: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 7D14921E8105 for ; Mon, 14 Oct 2013 13:39:01 -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 nlSUKuMslIf0 for ; Mon, 14 Oct 2013 13:38:55 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 489B811E80DC for ; Mon, 14 Oct 2013 13:38:55 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id d6vC1m0010cZkys548euuE; Mon, 14 Oct 2013 20:38:54 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id d8es1m0072yZEBF3W8etXa; Mon, 14 Oct 2013 20:38:54 +0000 User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 14 Oct 2013 16:38:51 -0400 From: David Harrington To: "" Message-ID: Thread-Topic: New Version Notification for draft-ietf-sacm-use-cases-02.txt In-Reply-To: <20131014202751.11509.91539.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381783134; bh=3MczMHNLWxmtoVJ36v6WzKIVvlMcB1P+GSendf6gmr0=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=at/FTu76wyhZIA5AqC0LCvAMD7/dTdfMC7qwWGboQCEShaciHz7SjGxMJ8A+ZPTD0 t6gq5odtwQXEDkDGMnf7SxsLNrMddT0647uco+Mtd7qOet2YAAO8KqWueKgHtV+etV 9Ix5bySS9xBH7i9nfBMEX51nd3zce8Y+n7kZOKcBncHVBN3dpauqcIqehiFpNAt/2e cDnLvlVh+kSvB84JkW9jzG+2PWqiO1XqDJ95mGiNzXF4Fl3SperJAvI1JyBaAXS+7m xNigyLDojMX+bBjGCZVXo/Tpgk+A3vHWuKSP+1rLNm+tMmNt9mvEMPzoHjsizP9qOY sPku6j/SBWrTQ== Subject: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 20:39:05 -0000 Hi, I published a revision of the use-cases doc. Changed title removed section 4, expecting it will be moved into the requirements document. removed the list of proposed caabilities from section 3.1 Added empty sections for Search for Signs of Infection, Remediation and Mitigation, and Endpoint Information Analysis and Reporting. Removed Requirements Language section and rfc2119 reference. Removed unused references (which ended up being all references). (added 2 references back in, one normative, one informative to pass xml2rfc and idnits requirements which don't accept empty reference sections or no reference sections. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 10/14/13 4:27 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-sacm-use-cases-02.txt >has been successfully submitted by David Waltermire and posted to the >IETF repository. > >Filename: draft-ietf-sacm-use-cases >Revision: 02 >Title: Endpoint Security Posture Assessment - Enterprise Use Cases >Creation date: 2013-10-14 >Group: sacm >Number of pages: 11 >URL: >http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-cases-02.txt >Status: http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases >Htmlized: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-02 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-02 > >Abstract: > This memo documents a sampling of use cases for securely aggregating > configuration and operational data and assessing that data to > determine an organization's security posture. From these operational > use cases, we can derive common functional capabilities and > requirements to guide development of vendor-neutral, interoperable > standards for aggregating and assessing data relevant to security > posture. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From shanna@juniper.net Mon Oct 14 15:49: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 EAF5021E8139 for ; Mon, 14 Oct 2013 15:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 bCCcidkkIWYQ for ; Mon, 14 Oct 2013 15:49:06 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 068ED21E813D for ; Mon, 14 Oct 2013 15:48:23 -0700 (PDT) Received: from mail198-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE024.bigfish.com (10.174.4.87) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 22:48:23 +0000 Received: from mail198-db8 (localhost [127.0.0.1]) by mail198-db8-R.bigfish.com (Postfix) with ESMTP id 9E5F658023B; Mon, 14 Oct 2013 22:48:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zzbb2dI98dI9371I9f17Rc85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h186068h18602eh8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail198-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(479174003)(377454003)(24454002)(407274004)(189002)(199002)(53806001)(15202345003)(54356001)(81342001)(74366001)(74876001)(15975445006)(74502001)(18717965001)(31966008)(77096001)(33646001)(83072001)(19609705001)(16236675002)(49866001)(47736001)(74316001)(69226001)(51856001)(81816001)(74706001)(85306002)(50986001)(46102001)(47976001)(4396001)(81686001)(81542001)(19300405004)(54316002)(56776001)(59766001)(80976001)(76482001)(76796001)(76786001)(77982001)(19580395003)(63696002)(66066001)(76576001)(74662001)(79102001)(83322001)(80022001)(19580405001)(65816001)(47446002)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB323; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail198-db8 (localhost.localdomain [127.0.0.1]) by mail198-db8 (MessageSwitch) id 1381790836948343_5011; Mon, 14 Oct 2013 22:47:16 +0000 (UTC) Received: from DB8EHSMHS011.bigfish.com (unknown [10.174.8.228]) by mail198-db8.bigfish.com (Postfix) with ESMTP id D9BDC4400F3; Mon, 14 Oct 2013 22:47:16 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS011.bigfish.com (10.174.4.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 22:47:16 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 14 Oct 2013 22:47:11 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 14 Oct 2013 22:47:10 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) with mapi id 15.00.0785.001; Mon, 14 Oct 2013 22:47:09 +0000 From: Stephen Hanna To: "Kent_Landfield@McAfee.com" , "Gunnar.Engelbach@ThreatGuard.com" , "ncamwing@cisco.com" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn0mJqAgAADGICAAC8gUA== Date: Mon, 14 Oct 2013 22:47:09 +0000 Message-ID: References: <525C48DF.8050500@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0999136621 Content-Type: multipart/alternative; boundary="_000_ef88e1f287ce4309936b45470a150773BLUPR05MB323namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 22:49:12 -0000 --_000_ef88e1f287ce4309936b45470a150773BLUPR05MB323namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Kent and Gunnar that SACM needs to support assessment techniqu= es other than the NEA protocols. However, it's not clear to me whether Nanc= y intended to imply that only NEA-based assessment would be supported. I gu= ess that's why she called this a rough draft. ;-) Two comments on earlier emails in this thread: 1) Nancy said "the submission deadline is today". Actually, the deadli= ne is a week from today. See http://www.ietf.org/meeting/cutoff-dates-2013.= html#IETF88 2) Kent said "the focus has been on getting the architecture document = nailed down". Even before that, we need to get the use cases agreed to. I see that David has just posted a new SACM use cases draft. I'll go review= that now. And write those 3 use cases that I promised... Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, October 14, 2013 3:52 PM To: Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements There are other means to accomplish assessments and NEA was not going to be= the only direction considered. This would be a direction change from what= has been discussed in all the side meetings and BOFs leading up to the SAC= M WG creation. If this is just a document to meet the deadline, ok. I am not aware of any consensus around NEA being the sole focus or the only= assessment methodology. And if that was brought up for consideration I wou= ld vote against it. There are many deployed products today that use other = means for assessment that have proven effective. We do need to get some of= that into this working group but the focus has been on getting the archite= cture document nailed down... Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Gunnar Engelbach > Organization: ThreatGuard, Inc. Date: Monday, October 14, 2013 2:41 PM To: "Nancy Cam-Winget (ncamwing)" >, "sacm@ietf.org" > Subject: Re: [sacm] Rough work in progress for Requirements Nancy, is this just a strawman to meet the document deadline? The role of SACM as you've outlined here has changed considerably from the conversations we've been having for the past 18 months (ish). Most notably is the assumption that NEA will now be the only assessment methodology. Is that the direction SACM has decided to go? If you just need a quick ASCII architecture and text to C&P into your skeleton, how about Dave Waltermire's original draft: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: Folks, As the submission deadline is today, I've posted a skeleton draft to help us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_ef88e1f287ce4309936b45470a150773BLUPR05MB323namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Kent and Gun= nar that SACM needs to support assessment techniques other than the NEA pro= tocols. However, it’s not clear to me whether Nancy intended to imply that only NEA-based assessment would be supported. I guess that&#= 8217;s why she called this a rough draft. ;-)

 <= /p>

Two comments on earlier e= mails in this thread:

 <= /p>

1) = ;     Nancy said “= ;the submission deadline is today”. Actually, the deadline is a week = from today. See http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88

2) = ;     Kent said “= the focus has been on getting the architecture document nailed down”.= Even before that, we need to get the use cases agreed to.

 <= /p>

I see that David has just= posted a new SACM use cases draft. I’ll go review that now. And writ= e those 3 use cases that I promised…

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Monday, October 14, 2013 3:52 PM
To: Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.= org
Subject: Re: [sacm] Rough work in progress for Requirements

 

There are other means to= accomplish assessments and NEA was not going to be the only direction cons= idered.  This would be a direction change from what has been discussed= in all the side meetings and BOFs leading up to the SACM WG creation.  If this is just a document to meet the d= eadline, ok. 

 =

I am not aware of any co= nsensus around NEA being the sole focus or the only assessment methodology.= And if that was brought up for consideration I would vote against it. &nbs= p;There are many deployed products today that use other means for assessment that have proven effective.  We d= o need to get some of that into this working group but the focus has been o= n getting the architecture document nailed down…

 =

Kent Landfield

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

 =

From: Gunnar Engelbach <gunnar.engelbach@threatguard.com><= br> Organization: ThreatGuard, Inc.
Date: Monday, October 14, 2013 2:41 PM
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "sacm@ietf.org" <sacm= @ietf.org>
Subject: Re: [sacm] Rough work in progress for Requirements

 =

 =

 =

Nancy, is this just a st= rawman to meet the document deadline?

 =

The role of SACM as you'= ve outlined here has changed considerably from

the conversations we've = been having for the past 18 months (ish).

 =

Most notably is the assu= mption that NEA will now be the only assessment

methodology.  = Is that the direction SACM has decided to go?

 =

 =

If you just need a quick= ASCII architecture and text to C&P into your

skeleton, how about Dave= Waltermire's original draft:

 =

 =

 =

 =

 =

 =

On 10/14/2013 2:43 PM, N= ancy Cam-Winget (ncamwing) wrote:

Folks,=

 =

As the submission deadli= ne is today, I've posted a skeleton draft to

help us drive the Requir= ements just now:

 =

There's plenty to discus= s!

 =

Thanks, Nancy.

 =

 =

________________________= _______________________

sacm mailing list

 =

________________________= _______________________

sacm mailing list

 =

--_000_ef88e1f287ce4309936b45470a150773BLUPR05MB323namprd05pro_-- From ncamwing@cisco.com Tue Oct 15 07:17: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 4308011E8128 for ; Tue, 15 Oct 2013 07:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5smNCfq484l1 for ; Tue, 15 Oct 2013 07:17:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A160D11E81E4 for ; Tue, 15 Oct 2013 07:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1866; q=dns/txt; s=iport; t=1381846649; x=1383056249; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=YxVZxQSU3XLP9CxhFEXDVL+C4fxLmU7Bg7d9bsI6lwY=; b=OONYKOWJ80AaOzeMsxDFfGlwlwaFC06+/k7hrKECNVzruPFxWA4oZyLV h8+ontLkAx9dkmRhJILEun6G8OEUfrJ4DAKZpue4rGpnGdLR8NCi9QQdd 7CPjyUVHiZpnX6WNR3ktlW53MMByrAy10ky/vKK7C54koXHRfuEchuUJH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAO1NXVKtJV2a/2dsb2JhbABagwc4UsIjgSAWdIIlAQEBBAEBAWsdAQgSBgpLCxcOAgQBEggBh30MvR6PGTiDH4EGA5kzkFODJIIp X-IronPort-AV: E=Sophos;i="4.93,499,1378857600"; d="scan'208";a="272312055" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 14:17:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9FEHSEe029774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 14:17:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 09:17:28 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Gunnar Engelbach , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOybFGo2WeMTvfmkOCiYf8IH+iew== Date: Tue, 15 Oct 2013 14:17:27 +0000 Message-ID: In-Reply-To: <525C48DF.8050500@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.80.71] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9DFDC194218FCF4A961369F4011226AB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:17:45 -0000 Hi Gunnar, Yes, it is a very rough straw man (note that there are still sections TBD) and the ones I did fill are to help us get the conversation going. My intent was not to state that NEA was the only assessment method, but one of=8Abut nonetheless, my point was to state how the posture assessment is achieved and stored from the end point was not our focus=8A.as groups like NEA have done so=8A.I can clean up the language as such. As for architecture, admittedly, the one that was posted by Russ and Sean resonated better to me draft-handt-sacm-alternate-architecture-01=8A. Nancy. On 10/14/13 12:41 PM, "Gunnar Engelbach" wrote: > > >Nancy, is this just a strawman to meet the document deadline? > >The role of SACM as you've outlined here has changed considerably from >the conversations we've been having for the past 18 months (ish). > >Most notably is the assumption that NEA will now be the only assessment >methodology. Is that the direction SACM has decided to go? > > >If you just need a quick ASCII architecture and text to C&P into your >skeleton, how about Dave Waltermire's original draft: > >http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 > > > > > >On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: >> Folks, >> >> As the submission deadline is today, I've posted a skeleton draft to >> help us drive the Requirements just now: >> http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt >> >> There's plenty to discuss! >> >> Thanks, Nancy. >> >> >> _______________________________________________ >> 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 ncamwing@cisco.com Tue Oct 15 07:20:22 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BDD21E80BF for ; Tue, 15 Oct 2013 07:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueJCOh3PEwfH for ; Tue, 15 Oct 2013 07:20:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D5B1621E809E for ; Tue, 15 Oct 2013 07:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24780; q=dns/txt; s=iport; t=1381846813; x=1383056413; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=5LoozmIkTynMROfdxfQANQYQNz+ubSC7NeEdBndmjG0=; b=R9JoSsAnefqbctWVqJbJTTTkYrRkd3DN0pdd2s4Q19oxsI3n/lEfZho9 M9Tv4yerAbIXqnH73sf+z5qhB7jgLTQnX1AP6uaHwmsp64pC7nNgjfW+a nPJTuEnzjIo8MACgSYMvUqmrykMEdSntjEpgjFhfXUOIZZ6QVafLkYCC5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAO1NXVKtJV2c/2dsb2JhbABXA4JDRDhSuViIS4EgFnSCJQEBAQQBAQEqHCUdAQgHBwMBAgEBAQsWBy4LFAMGCAIEARIIAYd9DL0ejxkNEwEMCgERgw6BBgOZM5BTgySCKQ X-IronPort-AV: E=Sophos;i="4.93,499,1378857600"; d="scan'208,217";a="272299827" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 15 Oct 2013 14:20:12 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9FEKCtM022599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 14:20:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 09:20:12 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Stephen Hanna , "Kent_Landfield@McAfee.com" , "Gunnar.Engelbach@ThreatGuard.com" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOybGoo2WeMTvfmkOCiYf8IH+iew== Date: Tue, 15 Oct 2013 14:20:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.80.71] Content-Type: multipart/alternative; boundary="_000_B80278DF1B7C814184086F4A6ECB311532F187FFxmbalnx02ciscoc_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:20:22 -0000 --_000_B80278DF1B7C814184086F4A6ECB311532F187FFxmbalnx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Steve, Please see below: From: Stephen Hanna > Date: Monday, October 14, 2013 3:47 PM To: "Kent_Landfield@McAfee.com" >, "Gunnar.Engelbach@Thr= eatGuard.com" >, "ncamwing@cisco.co= m" >, "sacm@ietf.org" > Subject: RE: [sacm] Rough work in progress for Requirements I agree with Kent and Gunnar that SACM needs to support assessment techniqu= es other than the NEA protocols. However, it=92s not clear to me whether Na= ncy intended to imply that only NEA-based assessment would be supported. I = guess that=92s why she called this a rough draft. ;-) [NCW] Right, I just responded to Gunnar in kind=85.. Two comments on earlier emails in this thread: 1) Nancy said =93the submission deadline is today=94. Actually, the de= adline is a week from today. See http://www.ietf.org/meeting/cutoff-dates-2= 013.html#IETF88 [NCW] For some reason I had it that it was due yesterday, so my bad=85.in t= his case, better to get it done now and get the dialogue going. 2) Kent said =93the focus has been on getting the architecture documen= t nailed down=94. Even before that, we need to get the use cases agreed to. [NCW] Agreed!!! I see that David has just posted a new SACM use cases draft. I=92ll go revi= ew that now. And write those 3 use cases that I promised=85 Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Monday, October 14, 2013 3:52 PM To: Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements There are other means to accomplish assessments and NEA was not going to be= the only direction considered. This would be a direction change from what= has been discussed in all the side meetings and BOFs leading up to the SAC= M WG creation. If this is just a document to meet the deadline, ok. I am not aware of any consensus around NEA being the sole focus or the only= assessment methodology. And if that was brought up for consideration I wou= ld vote against it. There are many deployed products today that use other = means for assessment that have proven effective. We do need to get some of= that into this working group but the focus has been on getting the archite= cture document nailed down=85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Gunnar Engelbach > Organization: ThreatGuard, Inc. Date: Monday, October 14, 2013 2:41 PM To: "Nancy Cam-Winget (ncamwing)" >, "sacm@ietf.org" > Subject: Re: [sacm] Rough work in progress for Requirements Nancy, is this just a strawman to meet the document deadline? The role of SACM as you've outlined here has changed considerably from the conversations we've been having for the past 18 months (ish). Most notably is the assumption that NEA will now be the only assessment methodology. Is that the direction SACM has decided to go? If you just need a quick ASCII architecture and text to C&P into your skeleton, how about Dave Waltermire's original draft: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: Folks, As the submission deadline is today, I've posted a skeleton draft to help us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_B80278DF1B7C814184086F4A6ECB311532F187FFxmbalnx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Steve,

Please see below:

I agree with Kent and Gunnar that = SACM needs to support assessment techniques other than the NEA protocols. H= owever, it=92s not clear to me whether Nancy intended to imply that only NEA-based assessment would be supported.= I guess that=92s why she called this a rough draft. ;-)

[NCW] Right, I just responded to Gunnar in kind=85..

 

Two comments on earlier emails in = this thread:

 

1)&= nbsp;     Nancy said =93the subm= ission deadline is today=94. Actually, the deadline is a week from today. S= ee http:= //www.ietf.org/meeting/cutoff-dates-2013.html#IETF88
[NCW] For some reason I had it that it was due yesterday, so my bad=85= .in this case, better to get it done now and get the dialogue going.

2)&= nbsp;     Kent said =93the focus= has been on getting the architecture document nailed down=94. Even before = that, we need to get the use cases agreed to.

 [NCW] Agreed!!!

I see that David has just posted a= new SACM use cases draft. I=92ll go review that now. And write those 3 use= cases that I promised=85

 

Thanks,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Monday, October 14, 2013 3:52 PM
To: Gunnar.Engel= bach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.org
Subject: Re: [sacm] Rough work in progress for Requirements

 

There are other means to= accomplish assessments and NEA was not going to be the only direction cons= idered.  This would be a direction change from what has been discussed= in all the side meetings and BOFs leading up to the SACM WG creation.  If this is just a document to meet the d= eadline, ok. 

 =

I am not aware of any co= nsensus around NEA being the sole focus or the only assessment methodology.= And if that was brought up for consideration I would vote against it. &nbs= p;There are many deployed products today that use other means for assessment that have proven effective.  We d= o need to get some of that into this working group but the focus has been o= n getting the architecture document nailed down=85

 =

Kent Landfield

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

 =

From: Gunnar Engelbach <gunnar.engelbach@threatguard.com>
Organization: ThreatGuard, Inc.
Date: Monday, October 14, 2013 2:41 PM
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "sacm@ietf.org" <sacm= @ietf.org>
Subject: Re: [sacm] Rough work in progress for Requirements

 =

 =

 =

Nancy, is this just a st= rawman to meet the document deadline?

 =

The role of SACM as you'= ve outlined here has changed considerably from

the conversations we've = been having for the past 18 months (ish).

 =

Most notably is the assu= mption that NEA will now be the only assessment

methodology.  = Is that the direction SACM has decided to go?

 =

 =

If you just need a quick= ASCII architecture and text to C&P into your

skeleton, how about Dave= Waltermire's original draft:

 =

 =

 =

 =

 =

 =

On 10/14/2013 2:43 PM, N= ancy Cam-Winget (ncamwing) wrote:

Folks,=

 =

As the submission deadli= ne is today, I've posted a skeleton draft to

help us drive the Requir= ements just now:

 =

There's plenty to discus= s!

 =

Thanks, Nancy.

 =

 =

________________________= _______________________

sacm mailing list

 =

________________________= _______________________

sacm mailing list

 =

--_000_B80278DF1B7C814184086F4A6ECB311532F187FFxmbalnx02ciscoc_-- From dromasca@avaya.com Tue Oct 15 08:53: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 59FDC21E8184 for ; Tue, 15 Oct 2013 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 KXrFXHmCRtu7 for ; Tue, 15 Oct 2013 08:53:23 -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 B375F21E8150 for ; Tue, 15 Oct 2013 08:53:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIOALpjXVLGmAcV/2dsb2JhbABagmYhOFKtSJRigSIWbQeCJwEBAxIoUQEVBRAUQhcPAQQbARmHZAELm3KESJ0DjxmDV4EGA55jiyODJIIp X-IronPort-AV: E=Sophos;i="4.93,500,1378872000"; d="scan'208";a="32088307" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Oct 2013 11:53:22 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Oct 2013 11:49:07 -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.03.0146.000; Tue, 15 Oct 2013 17:53:21 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: ietf-88 preliminary agenda Thread-Index: Ac7JvqvtHm6YLO25TPKcSpMmMKV0XA== Date: Tue, 15 Oct 2013 15:53:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12908659@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] ietf-88 preliminary agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:53:29 -0000 I have uploaded a preliminary agenda for the SACM meeting at ietf-88 (Vanco= uver) at http://www.ietf.org/proceedings/88/agenda/agenda-88-sacm. It right now includes the following:=20 SACM WG Meeting=20 Date and Time: Monday November 4, 2013=20 1740-1940 Afternoon Session III 1. Note Well, Note Takers, Jabber Scribes, Agenda Bashing - Chairs (5 min) 2. Charter and Milestone Review - Chairs (10 min) 3. Terminology - David and David(5 min) 4. Use Cases - David and David(45 min) =20 5. Requirements - Nancy Cam-Winget (30 min) 6. Next Steps - Architecture and Information Model (20 min) =20 7. Open Microphone, Way Forward - available time Reading material:=20 https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/ https://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/ https://datatracker.ietf.org/doc/draft-camwinget-sacm-requirements/ Please read and propose changes and additions.=20 Thanks and Regards,=20 Dan From gunnar.engelbach@threatguard.com Tue Oct 15 08:56: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 A845821E81BB for ; Tue, 15 Oct 2013 08:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gur8722AUGA for ; Tue, 15 Oct 2013 08:56:02 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3741211E813D for ; Tue, 15 Oct 2013 08:56:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=Du62ZdG1Ns/D8mOrdr0s6Mks5/HlACRdOIMF398LVrmzSRFYrzXhzpQXUCcKR1BzgLEc9VaM87+H7wWlGgYfWbyKNihT2nTx1xBP0PPZNNzhiwWbyJo+Y2KvhooIrC/j; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 10773 invoked from network); 15 Oct 2013 08:57:47 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Oct 2013 08:57:47 -0700 Message-ID: <525D6593.5070508@ThreatGuard.com> Date: Tue, 15 Oct 2013 11:56:03 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:56:06 -0000 On 10/15/2013 10:17 AM, Nancy Cam-Winget (ncamwing) wrote: > Hi Gunnar, > > Yes, it is a very rough straw man (note that there are still sections TBD) > and the ones I did fill are to help us get the conversation going. > > My intent was not to state that NEA was the only assessment method, but > one ofŠbut nonetheless, my point was to state how the posture assessment > is achieved and stored from the end point was not our focusŠ.as groups > like NEA have done soŠ.I can clean up the language as such. As for > architecture, admittedly, the one that was posted by Russ and Sean > resonated better to me draft-handt-sacm-alternate-architecture-01Š. With less than a week to go before the document deadline now is not a great time to be discussing major revisions, so I have a couple questions: 1) After this document deadline, how radically can they be changed in future revisions? If large changes are not a problem and it's only important that some sort of document be available, it doesn't really matter what's in the documents right now. If that's the case, the answer to my second question could wait. 2) Is it the consensus of the group that SACM is no longer concerned with "how the posture assessment is achieved and stored", but instead "...the focus of the requirements will revolve around the data models, protocols and transports for B, the communication of posture assessment from an Evaluator to an Assessment Consumer." That strikes me as a significant and surprising change from what I understood as the goal of this working group, and one that I completely disagree with. But I would like to know the perspective of others on this. It seems counterproductive to head into IETF 88 with perspectives that are so dichotomous. --gun > > Nancy. > > On 10/14/13 12:41 PM, "Gunnar Engelbach" > wrote: > >> >> >> Nancy, is this just a strawman to meet the document deadline? >> >> The role of SACM as you've outlined here has changed considerably from >> the conversations we've been having for the past 18 months (ish). >> >> Most notably is the assumption that NEA will now be the only assessment >> methodology. Is that the direction SACM has decided to go? >> >> >> If you just need a quick ASCII architecture and text to C&P into your >> skeleton, how about Dave Waltermire's original draft: >> >> http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 >> >> >> >> >> >> On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: >>> Folks, >>> >>> As the submission deadline is today, I've posted a skeleton draft to >>> help us drive the Requirements just now: >>> http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt >>> >>> There's plenty to discuss! >>> >>> Thanks, Nancy. >>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > From dbharrington@comcast.net Tue Oct 15 11:32:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2280111E8183 for ; Tue, 15 Oct 2013 11:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.561 X-Spam-Level: * X-Spam-Status: No, score=1.561 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yat3k85oPHUL for ; Tue, 15 Oct 2013 11:32:03 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id BD7B311E8160 for ; Tue, 15 Oct 2013 11:31:37 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id dPpo1m00117dt5G5DWXdlu; Tue, 15 Oct 2013 18:31:37 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta13.westchester.pa.mail.comcast.net with comcast id dWXa1m00m2yZEBF3ZWXbJA; Tue, 15 Oct 2013 18:31:37 +0000 User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 15 Oct 2013 14:31:34 -0400 From: David Harrington To: "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Message-ID: Thread-Topic: [sacm] Rough work in progress for Requirements In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3464692296_31493483" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381861897; bh=iw4/ZR5dqrO3ql/wPe2Yaszxjf9CRkqMMD688kFlUEA=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=l+x3smbhENUvY9BRHLQUwGGJ0O5xpQ5qo+m6ckDUw08tjbV8IKVMcX7rxo2l3RYrX jITcMDdx4fbVcyeM45XoHyzjCeEj9iIpPhqar6frbXrj2Feziat2+oBiHr32IvJLz6 4IEnGKgFCOw7BnV1BK+kPd8piJGrUON5rvccL8JDqottmHfF3tX3TvdlT3yd9QuFVx 5FqPgqlz6ebbGibHm7tylVdn9gOzR6yPrRsn2PFuyDCioqUTjS1OtI7YjV8kNsffEz v1kEIlgPUsO2uae7i/lbpdjmo/yGwOHCU5O/K9JwNfx1doR9Z7OyP6cBVw5MdcffV6 Y4BPlF33sjsaA== Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 18:32:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3464692296_31493483 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Nancy, The deadline is next Monday: 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool . I chopped section 4 from the use-cases document, with the understanding you would incorporate that content into the requirements doc. -- David Harrington dbharrington@comcast.net +1-603-828-1401 From: Nancy Cam-Winger Date: Monday, October 14, 2013 2:43 PM To: "sacm@ietf.org" Subject: [sacm] Rough work in progress for Requirements Folks, As the submission deadline is today, I've posted a skeleton draft to help us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --B_3464692296_31493483 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Nancy,

The deadline is next Monday:

I chopped section 4 from the use-cases document, with the understa= nding you would incorporate that content into the requirements doc= .
-- 
David Harringt= on
dbharrington@comcast.net
+1-603-828-1401

2013-10-21 (Mon= day):IETF ID Su= bmission Tool.

From: Nancy Cam-Winger <ncamwing@cisco.com>
Date: Monday, October 14, 2013 2:43 PM
To:= "sacm@ietf.org" <sacm@ietf.org>
S= ubject: [sacm] Rough work in progress for Requirements

Folks,

As the = submission deadline is today, I've posted a skeleton draft to help us drive = the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-re= quirements-00.txt

There's plenty to discuss!

Thanks, Nancy.
_______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/m= ailman/listinfo/sacm --B_3464692296_31493483-- From Kent_Landfield@mcafee.com Tue Oct 15 12:05:44 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9A921F9F9D for ; Tue, 15 Oct 2013 12:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjFIeG-h4b1e for ; Tue, 15 Oct 2013 12:05:40 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id AD07021F9702 for ; Tue, 15 Oct 2013 12:05:27 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 6dd6_ee89_f629508b_de98_44de_af1c_007bc13b342b; Tue, 15 Oct 2013 14:05:15 -0500 Received: from MIVEXAPP2N2.corp.nai.org (10.48.48.72) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Oct 2013 15:04:47 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.249]) by MIVEXAPP2N2.corp.nai.org ([169.254.3.61]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 15:04:47 -0400 From: To: , , , Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOydlqXQsoax33/UWQTiN8929UIw== Date: Tue, 15 Oct 2013 19:04:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_CE82FBB0561D2kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:05:44 -0000 --_000_CE82FBB0561D2kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Oops=85 Totally agree. I must have been looking at the link in Gunnar's m= essage when I typed that. You are correct. ;-) Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Monday, October 14, 2013 5:47 PM To: Kent Landfield >, Gunnar Engelbach >, "ncamwing@cisco.com" <= ncamwing@cisco.com>, "sacm@ietf.org" > Subject: RE: [sacm] Rough work in progress for Requirements I agree with Kent and Gunnar that SACM needs to support assessment techniqu= es other than the NEA protocols. However, it=92s not clear to me whether Na= ncy intended to imply that only NEA-based assessment would be supported. I = guess that=92s why she called this a rough draft. ;-) Two comments on earlier emails in this thread: 1) Nancy said =93the submission deadline is today=94. Actually, the de= adline is a week from today. See http://www.ietf.org/meeting/cutoff-dates-2= 013.html#IETF88 2) Kent said =93the focus has been on getting the architecture documen= t nailed down=94. Even before that, we need to get the use cases agreed to. I see that David has just posted a new SACM use cases draft. I=92ll go revi= ew that now. And write those 3 use cases that I promised=85 Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Monday, October 14, 2013 3:52 PM To: Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements There are other means to accomplish assessments and NEA was not going to be= the only direction considered. This would be a direction change from what= has been discussed in all the side meetings and BOFs leading up to the SAC= M WG creation. If this is just a document to meet the deadline, ok. I am not aware of any consensus around NEA being the sole focus or the only= assessment methodology. And if that was brought up for consideration I wou= ld vote against it. There are many deployed products today that use other = means for assessment that have proven effective. We do need to get some of= that into this working group but the focus has been on getting the archite= cture document nailed down=85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Gunnar Engelbach > Organization: ThreatGuard, Inc. Date: Monday, October 14, 2013 2:41 PM To: "Nancy Cam-Winget (ncamwing)" >, "sacm@ietf.org" > Subject: Re: [sacm] Rough work in progress for Requirements Nancy, is this just a strawman to meet the document deadline? The role of SACM as you've outlined here has changed considerably from the conversations we've been having for the past 18 months (ish). Most notably is the assumption that NEA will now be the only assessment methodology. Is that the direction SACM has decided to go? If you just need a quick ASCII architecture and text to C&P into your skeleton, how about Dave Waltermire's original draft: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: Folks, As the submission deadline is today, I've posted a skeleton draft to help us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CE82FBB0561D2kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4AB75CC2641CAC42A53404EA30773227@McAfee.com> Content-Transfer-Encoding: quoted-printable
Oops=85  Totally agree.  I must have been looking at the lin= k in Gunnar's message when I typed that.  You are correct. ;-)

Kent Landfield

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

From: Stephen Hanna <shanna@juniper.net>
Date: Monday, October 14, 2013 5:47= PM
To: Kent Landfield <Kent_Landfield@McAfee.com>, Gunnar = Engelbach <gunnar.en= gelbach@threatguard.com>, "ncamwing@cisco.com" <ncamwing@cisco.com>, &quo= t;sacm@ietf.org" <sacm@ietf.org>
Subject: RE: [sacm] Rough work in p= rogress for Requirements

I agree with Kent and Gunnar that = SACM needs to support assessment techniques other than the NEA protocols. H= owever, it=92s not clear to me whether Nancy intended to imply that only NEA-based assessment would be supported.= I guess that=92s why she called this a rough draft. ;-)<= /p>

 

Two comments on earlier emails in = this thread:

 

1)      Nancy said =93the subm= ission deadline is today=94. Actually, the deadline is a week from today. S= ee http:= //www.ietf.org/meeting/cutoff-dates-2013.html#IETF88<= /p>

2)      Kent said =93the focus= has been on getting the architecture document nailed down=94. Even before = that, we need to get the use cases agreed to.

 

I see that David has just posted a= new SACM use cases draft. I=92ll go review that now. And write those 3 use= cases that I promised=85

 

Thanks,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landf= ield@McAfee.com
Sent: Monday, October 14, 2013 3:52 PM
To: Gunnar.Engel= bach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.org
Subject: Re: [sacm] Rough work in progress for Requirements

 

There are other means to= accomplish assessments and NEA was not going to be the only direction cons= idered.  This would be a direction change from what has been discussed= in all the side meetings and BOFs leading up to the SACM WG creation.  If this is just a document to meet the d= eadline, ok. 

 =

I am not aware of any co= nsensus around NEA being the sole focus or the only assessment methodology.= And if that was brought up for consideration I would vote against it. &nbs= p;There are many deployed products today that use other means for assessment that have proven effective.  We d= o need to get some of that into this working group but the focus has been o= n getting the architecture document nailed down=85

 =

Kent Landfield

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

 =

From: Gunnar Engelbach <gunnar.engelbach@threatguard.com>
Organization: ThreatGuard, Inc.
Date: Monday, October 14, 2013 2:41 PM
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "sacm@ietf.org" <sacm= @ietf.org>
Subject: Re: [sacm] Rough work in progress for Requirements

 =

 =

 =

Nancy, is this just a st= rawman to meet the document deadline?

 =

The role of SACM as you'= ve outlined here has changed considerably from

the conversations we've = been having for the past 18 months (ish).

 =

Most notably is the assu= mption that NEA will now be the only assessment

methodology.  = Is that the direction SACM has decided to go?

 =

 =

If you just need a quick= ASCII architecture and text to C&P into your

skeleton, how about Dave= Waltermire's original draft:

 =

 =

 =

 =

 =

 =

On 10/14/2013 2:43 PM, N= ancy Cam-Winget (ncamwing) wrote:

Folks,=

 =

As the submission deadli= ne is today, I've posted a skeleton draft to

help us drive the Requir= ements just now:

 =

There's plenty to discus= s!

 =

Thanks, Nancy.

 =

 =

________________________= _______________________

sacm mailing list

 =

________________________= _______________________

sacm mailing list

 =

--_000_CE82FBB0561D2kentlandfieldmcafeecom_-- From shanna@juniper.net Tue Oct 15 16:21:54 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D5711E819A for ; Tue, 15 Oct 2013 16:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 0Qwi5bp2s2sp for ; Tue, 15 Oct 2013 16:21:48 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id C3B3311E8143 for ; Tue, 15 Oct 2013 16:21:47 -0700 (PDT) Received: from mail186-db8-R.bigfish.com (10.174.8.228) by DB8EHSOBE031.bigfish.com (10.174.4.94) with Microsoft SMTP Server id 14.1.225.22; Tue, 15 Oct 2013 23:21:46 +0000 Received: from mail186-db8 (localhost [127.0.0.1]) by mail186-db8-R.bigfish.com (Postfix) with ESMTP id F1160B00080 for ; Tue, 15 Oct 2013 23:21:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail186-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(189002)(199002)(53806001)(81342001)(54356001)(74876001)(74502001)(77096001)(31966008)(33646001)(74366001)(83072001)(49866001)(47736001)(74316001)(51856001)(69226001)(81816001)(74706001)(85306002)(47976001)(4396001)(50986001)(46102001)(81686001)(81542001)(54316002)(56776001)(59766001)(80976001)(76796001)(76482001)(76786001)(77982001)(63696002)(66066001)(76576001)(76176001)(74662001)(79102001)(80022001)(83322001)(65816001)(47446002)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB323; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail186-db8 (localhost.localdomain [127.0.0.1]) by mail186-db8 (MessageSwitch) id 138187930312560_1699; Tue, 15 Oct 2013 23:21:43 +0000 (UTC) Received: from DB8EHSMHS010.bigfish.com (unknown [10.174.8.239]) by mail186-db8.bigfish.com (Postfix) with ESMTP id F2F3340041 for ; Tue, 15 Oct 2013 23:21:42 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS010.bigfish.com (10.174.4.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 15 Oct 2013 23:21:42 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 15 Oct 2013 23:21:37 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 15 Oct 2013 23:21:37 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) with mapi id 15.00.0785.001; Tue, 15 Oct 2013 23:21:37 +0000 From: Stephen Hanna To: "sacm@ietf.org" Thread-Topic: Three More SACM Use Cases Thread-Index: Ac7J/Uouo5Bi8IM8TWyJ0YVyR7GCYQ== Date: Tue, 15 Oct 2013 23:21:36 +0000 Message-ID: <226190353816423d9e3d922ee8d978b9@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 00003DBFE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [sacm] Three More SACM Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 23:21:54 -0000 Here are the additional SACM use cases that I promised. Comments are most welcome! After some thought, I suspect that the Remediation and Mitigation use case is out of scope for this phase of SACM. If others agree, we can drop that use case for now. However, I hope that we design our architecture and protocols to be sufficiently extensible that future extensions can add support for that use case. Thanks, Steve ------ 2.5. Search for Signs of Infection The Example Corporation carefully manages endpoint security with tools that implement the SACM standards. One day, the endpoint security team at Example Corporation learns about a stealthy malware package. This malware has just been discovered but has already spread widely around the world. Certain signs of infection have been identified (e.g. the presence of certain files). The security team would like to know which endpoints owned by the Example Corporation have been infected with this malware. They use their tools to search for the signs of infection and generate a list of infected endpoints. The search for infected endpoints may be performed by gathering new endpoint posture information regarding the presence of the signs of infection. However, this might miss finding endpoints that were previously infected but where the infection has now erased itself. Such previously infected endpoints may be detected by searching a database of posture information previously gathered for the signs of infection. However, this will not work if the malware hides its presence carefully or if the signs of infection were not included in previous posture assessments. In those cases, the database may be used to at least detect which endpoints previously had software vulnerable to infection by the malware. 2.6. Remediation and Mitigation When Example Corporation discovers that one of its endpoints is vulnerable to infection, a process of mitigation and remediation is triggered. The first step is mitigating the impact of the vulnerability, perhaps by placing the endpoint into a safe network or blocking network traffic that could infect the endpoint. The second step is remediation: fixing the vulnerability. In some cases, these steps may happen automatically and rapidly. In other cases, they may require human intervention either to decide what response is most appropriate or to complete the steps, which are sometimes complex. These same steps of mitigation and remediation may be used when Example Corporation discovers that one of its endpoints has become infected with some malware. Alternatively, the infected endpoint may simply be monitored or even placed into a honeynet or similar environment to observe the malware's behavior and lead the attackers astray. 2.7. Endpoint Information Analysis and Reporting Freed from the drudgery of manual endpoint compliance monitoring, one of the security administrators at Example Corporation notices (not using SACM standards) that five endpoints have been uploading lots of data to a suspicious server on the Internet. The administrator queries the SACM database of endpoint posture to see what software is installed on those endpoints and finds that they all have a particular program installed. She then searches the database to see which other endpoints have that program installed. All these endpoints are monitored carefully (not using SACM standards), which allows the administrator to detect that the other endpoints are also infected. This is just one example of the useful analysis that a skilled analyst can do using the database of endpoint posture that SACM can provide. From gunnar.engelbach@threatguard.com Tue Oct 15 17:59: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 B362D11E823E for ; Tue, 15 Oct 2013 17:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f619AllHIKV3 for ; Tue, 15 Oct 2013 17:59:23 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id A623911E822D for ; Tue, 15 Oct 2013 17:59:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=Wnl8DcDQPiyTTbitOe5uoGcqhB6MhSAnArwPDkYc6oND0GMClLXZ9M9qIlgAStHDM5ktChThxw4BLtm3q6VnyRSNJNS8dUj4unXi3fPeXPopVp87iSVQv8camAe/iPdX; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 1360 invoked from network); 15 Oct 2013 18:00:58 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Oct 2013 18:00:58 -0700 Message-ID: <525DE4E2.7000608@ThreatGuard.com> Date: Tue, 15 Oct 2013 20:59:14 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Stephen Hanna , "sacm@ietf.org" References: <226190353816423d9e3d922ee8d978b9@BLUPR05MB323.namprd05.prod.outlook.com> In-Reply-To: <226190353816423d9e3d922ee8d978b9@BLUPR05MB323.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Three More SACM Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 00:59:27 -0000 Steve, You're right, the remediation use case is one of the ones that was dropped a while back. I don't think that means completely ignoring 2.6, however. Even if SACM isn't currently covering remediation, other software can monitor (or receive notification) a SACM system and take mitigation steps based on that. Just like 2.8, it shows using the SACM system for purposes not covered by SACM. I will also repost this use case I wrote a while back: -------------===========================------------- 2.8 Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra A university team receives a grant to do research at a government facility in the arctic. The only network communications will be via an intermittent low-speed high-latency high-cost satellite link. During their extended expedition they will need to show continue compliance with the security policies of the university, the government, and the provider of the satellite network as well as keep current on vulnerability testing. Interactive assessments are therefore not reliable, and since the researchers have very limited funding they need to minimize how much money they spend on network data. Prior to departure they register all equipment with an asset management system owned by the university, which will also initiate and track assessments. On a periodic basis -- either after a maximum time delta or when the content repository has received a threshold level of new vulnerability definitions -- the university uses the information in the asset management system to put together a collection request for all of the deployed assets that encompasses the minimal set of artifacts necessary to evaluate all three security policies as well as vulnerability testing. In the case of new critical vulnerabilities this collection request consists only of the artifacts necessary for those vulnerabilities and collection is only initiated for those assets that could potentially have a new vulnerability. [Optional] Asset artifacts are cached in a local CMDB. When new vulnerabilities are reported to the content repository, a request to the live asset is only done if the artifacts in the CMDB are incomplete and/or not current enough. The collection request is queued for the next window of connectivity. The deployed assets eventually receive the request, fulfill it, and queue the results for the next return opportunity. The collected artifacts eventually make it back to the university where the level of compliance and vulnerability expose is calculated and asset characteristics are compared to what is in the asset management system for accuracy and completeness. On 10/15/2013 7:21 PM, Stephen Hanna wrote: > Here are the additional SACM use cases that I promised. > Comments are most welcome! > > After some thought, I suspect that the Remediation and > Mitigation use case is out of scope for this phase of > SACM. If others agree, we can drop that use case for > now. However, I hope that we design our architecture > and protocols to be sufficiently extensible that future > extensions can add support for that use case. > > Thanks, > > Steve > > ------ > > 2.5. Search for Signs of Infection > > The Example Corporation carefully manages endpoint security > with tools that implement the SACM standards. One day, the > endpoint security team at Example Corporation learns about > a stealthy malware package. This malware has just been > discovered but has already spread widely around the world. > Certain signs of infection have been identified (e.g. the > presence of certain files). The security team would like > to know which endpoints owned by the Example Corporation > have been infected with this malware. They use their tools > to search for the signs of infection and generate a list of > infected endpoints. > > The search for infected endpoints may be performed by > gathering new endpoint posture information regarding > the presence of the signs of infection. However, this > might miss finding endpoints that were previously > infected but where the infection has now erased itself. > Such previously infected endpoints may be detected > by searching a database of posture information > previously gathered for the signs of infection. > However, this will not work if the malware hides > its presence carefully or if the signs of infection > were not included in previous posture assessments. > In those cases, the database may be used to at least > detect which endpoints previously had software > vulnerable to infection by the malware. > > 2.6. Remediation and Mitigation > > When Example Corporation discovers that one of its > endpoints is vulnerable to infection, a process of > mitigation and remediation is triggered. The first > step is mitigating the impact of the vulnerability, > perhaps by placing the endpoint into a safe network > or blocking network traffic that could infect the > endpoint. The second step is remediation: fixing > the vulnerability. In some cases, these steps may > happen automatically and rapidly. In other cases, > they may require human intervention either to > decide what response is most appropriate or to > complete the steps, which are sometimes complex. > > These same steps of mitigation and remediation may > be used when Example Corporation discovers that one > of its endpoints has become infected with some malware. > Alternatively, the infected endpoint may simply be > monitored or even placed into a honeynet or similar > environment to observe the malware's behavior and > lead the attackers astray. > > 2.7. Endpoint Information Analysis and Reporting > > Freed from the drudgery of manual endpoint compliance > monitoring, one of the security administrators at > Example Corporation notices (not using SACM standards) > that five endpoints have been uploading lots of data > to a suspicious server on the Internet. The administrator > queries the SACM database of endpoint posture to see > what software is installed on those endpoints and > finds that they all have a particular program installed. > She then searches the database to see which other > endpoints have that program installed. All these > endpoints are monitored carefully (not using SACM > standards), which allows the administrator to detect > that the other endpoints are also infected. > > This is just one example of the useful analysis > that a skilled analyst can do using the database > of endpoint posture that SACM can provide. > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From dromasca@avaya.com Wed Oct 16 02:23:59 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC8E11E817A for ; Wed, 16 Oct 2013 02:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.368 X-Spam-Level: X-Spam-Status: No, score=-103.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 yP3f748Wxqe1 for ; Wed, 16 Oct 2013 02:23:52 -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 09A4B21F9D87 for ; Wed, 16 Oct 2013 02:23:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANNZXlKHCzI1/2dsb2JhbABagmYhgQrCDYEhFnSCJQEBAQEDEihLBAIBCA0IDRQJBzIUEQIEARIIGodkAaExnRmPIDiDH4EGA55jiyODJIIp X-IronPort-AV: E=Sophos;i="4.93,506,1378872000"; d="scan'208";a="27912215" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Oct 2013 05:23:50 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Oct 2013 05:14:37 -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.03.0146.000; Wed, 16 Oct 2013 11:23:48 +0200 From: "Romascanu, Dan (Dan)" To: Gunnar Engelbach , "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOybFGo2WeMTvfmkOCiYf8IH+ie5n1yS+AgAFEZTA= Date: Wed, 16 Oct 2013 09:23:47 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1290A3A6@AZ-FFEXMB04.global.avaya.com> References: <525D6593.5070508@ThreatGuard.com> In-Reply-To: <525D6593.5070508@ThreatGuard.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] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:23:59 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach >=20 > With less than a week to go before the document deadline now is not a > great time to be discussing major revisions, so I have a couple > questions: >=20 > 1) After this document deadline, how radically can they be changed in > future revisions? >=20 > If large changes are not a problem and it's only important that some > sort of document be available, it doesn't really matter what's in the > documents right now. If that's the case, the answer to my second > question could wait. >=20 >=20 Hi Gunnar,=20 This is simple to answer. draft-camwinget-sacm-requirements-00 is a 00 draf= t of an individual submission. It has a long way to go, and all kind of cha= nges including 'radical' ones can happen. I would not say either that it do= esn't really matter what's in the document right now - as the goal is exact= ly to trigger and structure discussions around existing text, but there wil= l be several iterations of this text until we will reach consensus and noth= ing is cast in stone at this point.=20 Regards, Dan From Adam.Montville@cisecurity.org Wed Oct 16 07:40: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 C3AEE21F9E46 for ; Wed, 16 Oct 2013 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEQpzs3Q5iQE for ; Wed, 16 Oct 2013 07:40:47 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) by ietfa.amsl.com (Postfix) with ESMTP id 06C6711E82A5 for ; Wed, 16 Oct 2013 07:40:39 -0700 (PDT) Received: from [216.82.253.243:21100] by server-10.bemta-7.messagelabs.com id 14/9C-27019-665AE525; Wed, 16 Oct 2013 14:40:38 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-9.tower-171.messagelabs.com!1381934437!22605058!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 30952 invoked from network); 16 Oct 2013 14:40:38 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-9.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 16 Oct 2013 14:40:38 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Wed, 16 Oct 2013 10:40:22 -0400 From: Adam Montville To: David Harrington , "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn2WoAAgAEOaNA= Date: Wed, 16 Oct 2013 14:40:22 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D689AD65@CISEXCHANGE1.msisac.org.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D689AD65CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:40:53 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D689AD65CISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to clarify the deadline issues... The -00 submission deadline was th= is past Monday (2013-10-14). Final submission deadline is this coming Mon= day (2013-10-21). From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Da= vid Harrington Sent: Tuesday, October 15, 2013 1:32 PM To: Nancy Cam-Winget (ncamwing); sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements Hi Nancy, The deadline is next Monday: 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, in= cluding -00) by UTC 24:00, upload using IETF ID Submission Tool. I chopped section 4 from the use-cases document, with the understanding yo= u would incorporate that content into the requirements doc. -- David Harrington dbharrington@comcast.net +1-603-828-1401 From: Nancy Cam-Winger > Date: Monday, October 14, 2013 2:43 PM To: "sacm@ietf.org" > Subject: [sacm] Rough work in progress for Requirements Folks, As the submission deadline is today, I've posted a skeleton draft to help = us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget= -sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@iet= f.org https://www.ietf.org/mailman/listinfo/sacm ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D689AD65CISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just to clarify the dea= dline issues…  The -00 submission deadline was this past Monday= (2013-10-14).  Final submission deadline is this coming Monday (2013= -10-21).

 

From: sac= m-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
Sent: Tuesday, October 15, 2013 1:32 PM
To: Nancy Cam-Winget (ncamwing); sacm@ietf.org
Subject: Re: [sacm] Rough work in progress for Requirements

 

Hi Nancy,

 <= /p>

The deadline is next Mond= ay:

 <= /p>

I chopped section 4 from the use-cases document, with the u= nderstanding you would incorporate that content into the require= ments doc.

-- 

David Harrington

+1-603-828-1401<= /o:p>

 <= /p>

 <= /p>

 <= /p>

From: Nancy Cam-Winger <ncamwing@cisco.com>
Date: Monday, October 14, 2013 2:43 PM
To: "sac= m@ietf.org" <sacm@ietf.org>
Subject: [sacm] Rough work in progress for Requirements<= /span>

 <= /p>

Folks,<= /p>

 <= /p>

As the submission deadlin= e is today, I've posted a skeleton draft to help us drive the Requirements= just now: http://www.ietf.org/id/draft-camwin= get-sacm-requirements-00.txt

 <= /p>

There's plenty to discuss= !

 <= /p>

Thanks, Nancy.=

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


. . .
--_000_05BCCEB107AF88469B9F99783D47C1D689AD65CISEXCHANGE1msisa_-- From shanna@juniper.net Wed Oct 16 08:04: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 73A4E11E8255 for ; Wed, 16 Oct 2013 08:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.765 X-Spam-Level: X-Spam-Status: No, score=-103.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj4r+9DjE44q for ; Wed, 16 Oct 2013 08:04:00 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1769A11E82AA for ; Wed, 16 Oct 2013 08:04:00 -0700 (PDT) Received: from mail112-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE022.bigfish.com (10.243.66.85) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Oct 2013 15:03:58 +0000 Received: from mail112-co1 (localhost [127.0.0.1]) by mail112-co1-R.bigfish.com (Postfix) with ESMTP id 04E08CE018C; Wed, 16 Oct 2013 15:03:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371I936eIc85fh1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah8275dh18c673h1c8fb4h1de097h186068h8275bhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail112-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(24454002)(164054003)(377454003)(377424004)(19609705001)(54356001)(4396001)(74706001)(19300405004)(85306002)(81342001)(54316002)(76576001)(50986001)(47976001)(15202345003)(77096001)(81816001)(65816001)(47736001)(33646001)(81542001)(76482001)(59766001)(77982001)(74316001)(56776001)(69226001)(76786001)(76796001)(56816003)(63696002)(81686001)(53806001)(74502001)(18717965001)(31966008)(47446002)(66066001)(74876001)(74662001)(19580395003)(19580405001)(83322001)(83072001)(80976001)(46102001)(15975445006)(79102001)(51856001)(16236675002)(74366001)(49866001)(80022001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB324; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail112-co1 (localhost.localdomain [127.0.0.1]) by mail112-co1 (MessageSwitch) id 1381935777373704_5632; Wed, 16 Oct 2013 15:02:57 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.252]) by mail112-co1.bigfish.com (Postfix) with ESMTP id 4D2F0A80363; Wed, 16 Oct 2013 15:02:57 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 16 Oct 2013 15:02:52 +0000 Received: from BLUPR05MB324.namprd05.prod.outlook.com (10.141.24.27) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 16 Oct 2013 15:02:51 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB324.namprd05.prod.outlook.com (10.141.24.27) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 16 Oct 2013 15:02:50 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.200]) with mapi id 15.00.0785.001; Wed, 16 Oct 2013 15:02:50 +0000 From: Stephen Hanna To: Adam Montville , David Harrington , "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn2F3IAgAFRvACAAAS+0A== Date: Wed, 16 Oct 2013 15:02:50 +0000 Message-ID: <1e41e953ab5743e48847270201965815@BLUPR05MB323.namprd05.prod.outlook.com> References: <05BCCEB107AF88469B9F99783D47C1D689AD65@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D689AD65@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0001227049 Content-Type: multipart/alternative; boundary="_000_1e41e953ab5743e48847270201965815BLUPR05MB323namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:04:05 -0000 --_000_1e41e953ab5743e48847270201965815BLUPR05MB323namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam wrote: > Just to clarify the deadline issues... The -00 submission deadline was t= his past Monday (2013-10-14). Final submission deadline is this coming Mon= day (2013-10-21). I don't think that's correct. Here's the info from the IETF web site: * 2013-10-07 (Monday): Working Group Chair approval for initial document (= Version -00) submissions appreciated by UTC 24:00. * 2013-10-11 (Friday): Final agenda to be published. * 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, = including -00) by UTC 24:00, upload using IETF ID Submission Tool. Nowhere is October 14 mentioned as a deadline. October 7 is mentioned as a = date by which WG chairs should provide approval for -00 WG drafts. I don't = think that applies here since we won't have any -00 WG drafts coming in thi= s time. So October 21 is the real deadline for drafts in this case. If you = have some information that supports your contention that the -00 deadline w= as October 14, could you please point me to it? I got my info from this web= page: http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88 The IETF used to have a -00 deadline one week before the non-00 deadline bu= t that practice was discontinued for IETF 87 and IETF 88. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Wednesday, October 16, 2013 10:40 AM To: David Harrington; Nancy Cam-Winget (ncamwing); sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements Just to clarify the deadline issues... The -00 submission deadline was thi= s past Monday (2013-10-14). Final submission deadline is this coming Monda= y (2013-10-21). From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, October 15, 2013 1:32 PM To: Nancy Cam-Winget (ncamwing); sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements Hi Nancy, The deadline is next Monday: 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 24:00, upload using IETF ID Submission Tool. I chopped section 4 from the use-cases document, with the understanding you= would incorporate that content into the requirements doc. -- David Harrington dbharrington@comcast.net +1-603-828-1401 From: Nancy Cam-Winger > Date: Monday, October 14, 2013 2:43 PM To: "sacm@ietf.org" > Subject: [sacm] Rough work in progress for Requirements Folks, As the submission deadline is today, I've posted a skeleton draft to help u= s drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-s= acm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@ietf= .org https://www.ietf.org/mailman/listinfo/sacm ... . . . --_000_1e41e953ab5743e48847270201965815BLUPR05MB323namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam wrote:

> Just to clarify the = deadline issues…  The -00 submission deadline was this past Mond= ay (2013-10-14).  Final submission deadline is this coming Monday (201= 3-10-21).

 <= /p>

I don’t think that&= #8217;s correct. Here’s the info from the IETF web site:

 <= /p>

·&n= bsp; 2013-10-07 (Monday): Working Group Chair approval for initial d= ocument (Version -00) submissions appreciated by UTC 24:00.

·&n= bsp; 2013-10-11 (Friday): Final agenda to be published.

·&n= bsp; 2013-10-21 (Monday): Internet Draft submission cut-off (for all= drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool.

 <= /p>

Nowhere is October 14 men= tioned as a deadline. October 7 is mentioned as a date by which WG chairs s= hould provide approval for -00 WG drafts. I don’t think that applies here since we won’t have any -00 WG drafts coming in th= is time. So October 21 is the real deadline for drafts in this case. If you= have some information that supports your contention that the -00 deadline = was October 14, could you please point me to it? I got my info from this web page:

 <= /p>

http://www.ietf.org/meeting/cu= toff-dates-2013.html#IETF88

 <= /p>

The IETF used to have a -= 00 deadline one week before the non-00 deadline but that practice was disco= ntinued for IETF 87 and IETF 88.

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, October 16, 2013 10:40 AM
To: David Harrington; Nancy Cam-Winget (ncamwing); sacm@ietf.org
Subject: Re: [sacm] Rough work in progress for Requirements

 

Just to clarify the deadl= ine issues…  The -00 submission deadline was this past Monday (2= 013-10-14).  Final submission deadline is this coming Monday (2013-10-= 21).

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
Sent: Tuesday, October 15, 2013 1:32 PM
To: Nancy Cam-Winget (ncamwing); sa= cm@ietf.org
Subject: Re: [sacm] Rough work in progress for Requirements

 

Hi Nancy,=

 

The deadline is next Monday= :

20= 13-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upl= oad using IETF ID Submission Tool.

 

I chopped section 4 from the use-cases document, with the unde= rstanding you would incorporate that content into the requirement= s doc.

-- <= /p>

David Harrington=

+1-603-828-1401

 

 

 

From: Nancy Cam-Winger <ncamwing@cisco.com>
Date: Monday, October 14, 2013 2:43 PM
To: "sacm@= ietf.org" <sacm@ietf.org>
Subject: [sacm] Rough work in progress for Requirements

 

Folks,

 

As the submission deadline = is today, I've posted a skeleton draft to help us drive the Requirements ju= st now: http://www.ietf.org/id/draft-camwinget-sa= cm-requirements-00.txt

 

There's plenty to discuss!<= o:p>

 

Thanks, Nancy.

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


. . .

--_000_1e41e953ab5743e48847270201965815BLUPR05MB323namprd05pro_-- From Adam.Montville@cisecurity.org Wed Oct 16 08:07:40 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE6411E8138 for ; Wed, 16 Oct 2013 08:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTsyo1kGvjo5 for ; Wed, 16 Oct 2013 08:07:36 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.7]) by ietfa.amsl.com (Postfix) with ESMTP id A8BC611E82AA for ; Wed, 16 Oct 2013 08:07:32 -0700 (PDT) Received: from [216.82.250.179:35425] by server-7.bemta-12.messagelabs.com id 39/61-30474-3BBAE525; Wed, 16 Oct 2013 15:07:31 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-12.tower-210.messagelabs.com!1381936049!8725383!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 26734 invoked from network); 16 Oct 2013 15:07:30 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-12.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 16 Oct 2013 15:07:30 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Wed, 16 Oct 2013 11:07:14 -0400 From: Adam Montville To: Stephen Hanna , David Harrington , "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn2WoAAgAEOaNCAAEmbAP//vgvg Date: Wed, 16 Oct 2013 15:07:13 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D689AE29@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D689AD65@CISEXCHANGE1.msisac.org.local> <1e41e953ab5743e48847270201965815@BLUPR05MB323.namprd05.prod.outlook.com> In-Reply-To: <1e41e953ab5743e48847270201965815@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D689AE29CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:07:41 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D689AE29CISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen just pointed this out to me as well. I, apparently, have an out-o= f-date set of data in my calendar, which I probably retrieved from IETF a = while back, before the change. Apologies. Adam From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, October 16, 2013 10:04 AM To: Adam Montville; David Harrington; Nancy Cam-Winget (ncamwing); sacm@ie= tf.org Subject: RE: [sacm] Rough work in progress for Requirements Adam wrote: > Just to clarify the deadline issues... The -00 submission deadline was = this past Monday (2013-10-14). Final submission deadline is this coming M= onday (2013-10-21). I don't think that's correct. Here's the info from the IETF web site: * 2013-10-07 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by UTC 24:00. * 2013-10-11 (Friday): Final agenda to be published. * 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts,= including -00) by UTC 24:00, upload using IETF ID Submission Tool. Nowhere is October 14 mentioned as a deadline. October 7 is mentioned as a= date by which WG chairs should provide approval for -00 WG drafts. I don'= t think that applies here since we won't have any -00 WG drafts coming in = this time. So October 21 is the real deadline for drafts in this case. If = you have some information that supports your contention that the -00 deadl= ine was October 14, could you please point me to it? I got my info from th= is web page: http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88 The IETF used to have a -00 deadline one week before the non-00 deadline b= ut that practice was discontinued for IETF 87 and IETF 88. Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, October 16, 2013 10:40 AM To: David Harrington; Nancy Cam-Winget (ncamwing); sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements Just to clarify the deadline issues... The -00 submission deadline was th= is past Monday (2013-10-14). Final submission deadline is this coming Mon= day (2013-10-21). From: sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of David Harrington Sent: Tuesday, October 15, 2013 1:32 PM To: Nancy Cam-Winget (ncamwing); sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements Hi Nancy, The deadline is next Monday: 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, in= cluding -00) by UTC 24:00, upload using IETF ID Submission Tool. I chopped section 4 from the use-cases document, with the understanding yo= u would incorporate that content into the requirements doc. -- David Harrington dbharrington@comcast.net +1-603-828-1401 From: Nancy Cam-Winger > Date: Monday, October 14, 2013 2:43 PM To: "sacm@ietf.org" > Subject: [sacm] Rough work in progress for Requirements Folks, As the submission deadline is today, I've posted a skeleton draft to help = us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget= -sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@iet= f.org https://www.ietf.org/mailman/listinfo/sacm ... . . . ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D689AE29CISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen just pointed th= is out to me as well.  I, apparently, have an out-of-date set of data= in my calendar, which I probably retrieved from IETF a while back, before the change.

 

Apologies.

 

Adam<= /p>

 

From: Ste= phen Hanna [mailto:shanna@juniper.net]
Sent: Wednesday, October 16, 2013 10:04 AM
To: Adam Montville; David Harrington; Nancy Cam-Winget (ncamwing); = sacm@ietf.org
Subject: RE: [sacm] Rough work in progress for Requirements

 

Adam wrote:<= /span>

> Just to clarify th= e deadline issues…  The -00 submission deadline was this past M= onday (2013-10-14).  Final submission deadline is this coming Monday = (2013-10-21).

 

I don’t think tha= t’s correct. Here’s the info from the IETF web site:

 

·&= nbsp; 2013-10-07 (Monday): Working Group Chair approval for initial= document (Version -00) submissions appreciated by UTC 24:00.

·&= nbsp; 2013-10-11 (Friday): Final agenda to be published.

·&= nbsp; 2013-10-21 (Monday): Internet Draft submission cut-off (for a= ll drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool.

 

Nowhere is October 14 m= entioned as a deadline. October 7 is mentioned as a date by which WG chair= s should provide approval for -00 WG drafts. I don’t think that applies here since we won’t have any -00 WG drafts coming in t= his time. So October 21 is the real deadline for drafts in this case. If y= ou have some information that supports your contention that the -00 deadli= ne was October 14, could you please point me to it? I got my info from this web page:

 

http://www.ietf.org/meeting= /cutoff-dates-2013.html#IETF88

 

The IETF used to have a= -00 deadline one week before the non-00 deadline but that practice was di= scontinued for IETF 87 and IETF 88.

 

Thanks,

 

Steve=

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, October 16, 2013 10:40 AM
To: David Harrington; Nancy Cam-Winget (ncamwing); sacm@ietf.org
Subject: Re: [sacm] Rough work in progress for Requirements

 

Just to clarify the dea= dline issues…  The -00 submission deadline was this past Monday= (2013-10-14).  Final submission deadline is this coming Monday (2013= -10-21).

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
Sent: Tuesday, October 15, 2013 1:32 PM
To: Nancy Cam-Winget (ncamwing); s= acm@ietf.org
Subject: Re: [sacm] Rough work in progress for Requirements

 

Hi Nancy,

 <= /p>

The deadline is next Mond= ay:

= 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, up= load using IETF ID Submission Tool.

 <= /p>

I chopped section 4 from the use-cases document, with the u= nderstanding you would incorporate that content into the require= ments doc.

-- 

David Harrington

+1-603-828-1401<= /o:p>

 <= /p>

 <= /p>

 <= /p>

From: Nancy Cam-Winger <ncamwing@cisco.com>
Date: Monday, October 14, 2013 2:43 PM
To: "sac= m@ietf.org" <sacm@ietf.org>
Subject: [sacm] Rough work in progress for Requirements<= /span>

 <= /p>

Folks,<= /p>

 <= /p>

As the submission deadlin= e is today, I've posted a skeleton draft to help us drive the Requirements= just now: http://www.ietf.org/id/draft-camwin= get-sacm-requirements-00.txt

 <= /p>

There's plenty to discuss= !

 <= /p>

Thanks, Nancy.=

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


. . .


...


. . .
--_000_05BCCEB107AF88469B9F99783D47C1D689AE29CISEXCHANGE1msisa_-- From Adam.Montville@cisecurity.org Wed Oct 16 08:41: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 17F0811E82FD for ; Wed, 16 Oct 2013 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrtnvWWFU78G for ; Wed, 16 Oct 2013 08:41:09 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id A561A11E8255 for ; Wed, 16 Oct 2013 08:41:08 -0700 (PDT) Received: from [216.82.253.227:13168] by server-11.bemta-7.messagelabs.com id 79/51-13883-393BE525; Wed, 16 Oct 2013 15:41:07 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-3.tower-170.messagelabs.com!1381938065!26032013!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 9034 invoked from network); 16 Oct 2013 15:41:06 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-3.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 16 Oct 2013 15:41:06 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Wed, 16 Oct 2013 11:40:50 -0400 From: Adam Montville To: "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Thread-Topic: Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn3cUug Date: Wed, 16 Oct 2013 15:40:50 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D689AE8F@CISEXCHANGE1.msisac.org.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D689AE8FCISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:41:15 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D689AE8FCISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nancy, thank you for working on this! I very much like your Architectural= Design Tenets section, which I believe support our Use Cases well. I would prefer to see a Requirements document free from any architectural = assumptions, such that we are able to conceive an architecture that is tru= ly derived from requirements - in other words, let's let the requirements = drive the architecture, not the other way around (I fully recognize that n= etwork architectural constraints will affect our solution in the end). By my read, we have the following Use Cases present in the -02 Use Case dr= aft: 2.1 - Definition and Publication of Automatable Configuration Guides 2.2 - Automated Checklist Verification 2.3 - Organizational Software Policy Compliance 2.4 - Detection of Posture Deviation 2.5 - Search for Signs of Infection 2.6 - Remediation and Mitigation 2.7 - Endpoint Information Analysis and Reporting Endpoint Posture Assessment (Section 2) starts out with "collecting the po= sture of a given endpoint." I want to limit=20this example to that partic= ular statement in the -02 Use Case draft, because it applies generally to = the specific Use Cases contained in that section. >From my perspective, requirements pertaining to that statement might read = something like the following: 1. The system must be capable of expressing configuration items acro= ss technology platforms as necessary. 2. The expression of configuration items across technology platforms= must be extensible to account for changes to existing platforms as well a= s new platforms. 3. The system must be capable of expressing a "platform" or "technol= ogy" instance 4. The system must be capable of harvesting (collecting) configurati= on state >From the other Use Cases, we might be able to add further requirements, su= ch as: 1. The system must be capable of expressing a class of platforms or = technologies 2. The system must be capable of performing assessment over a limite= d bandwidth network 3. The system must be able to compare expected state against actual = state for initial analysis It seems that the question to ask about each of the Use Cases in the -02 d= raft is: "What needs to be true of the system we envision to realize the U= se Cases we wish to meet?" This might be an exercise for each of the bull= eted items in Section 2 proper, and then further for each subsection there= in. Any thoughts or comments on taking this approach to the requirements? Regards, Adam From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Na= ncy Cam-Winget (ncamwing) Sent: Monday, October 14, 2013 1:43 PM To: sacm@ietf.org Subject: [sacm] Rough work in progress for Requirements Folks, As the submission deadline is today, I've posted a skeleton draft to help = us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget= -sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D689AE8FCISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nancy, thank you for wo= rking on this!  I very much like your Architectural Design Tenets sec= tion, which I believe support our Use Cases well.

 

I would prefer to see a= Requirements document free from any architectural assumptions, such that = we are able to conceive an architecture that is truly derived from requirements – in other words, let’s let the requirement= s drive the architecture, not the other way around (I fully recognize that= network architectural constraints will affect our solution in the end).

 

By my read, we have the= following Use Cases present in the -02 Use Case draft:<= /p>

 

2.1 - Definition and Pu= blication of Automatable Configuration Guides

2.2 - Automated Checkli= st Verification

2.3 - Organizational So= ftware Policy Compliance

2.4 - Detection of Post= ure Deviation

2.5 - Search for Signs = of Infection

2.6 - Remediation and M= itigation

2.7 - Endpoint Informat= ion Analysis and Reporting

 

Endpoint Posture Assess= ment (Section 2) starts out with “collecting the posture of a given = endpoint.”  I want to limit this example to that particular sta= tement in the -02 Use Case draft, because it applies generally to the specific U= se Cases contained in that section.

 

From my perspective, re= quirements pertaining to that statement might read something like the foll= owing:

 

1.&= nbsp;      The system must= be capable of expressing configuration items across technology platforms = as necessary.

2.&= nbsp;      The expression = of configuration items across technology platforms must be extensible to a= ccount for changes to existing platforms as well as new platforms.

3.&= nbsp;      The system must= be capable of expressing a “platform” or “technology= 221; instance

4.&= nbsp;      The system must= be capable of harvesting (collecting) configuration state

 

From the other Use Case= s, we might be able to add further requirements, such as:

 

1.&= nbsp;      The system must= be capable of expressing a class of platforms or technologies<= /span>

2.&= nbsp;      The system must= be capable of performing assessment over a limited bandwidth network=

3.&= nbsp;      The system must= be able to compare expected state against actual state for initial analys= is

 

It seems that the quest= ion to ask about each of the Use Cases in the -02 draft is: “What ne= eds to be true of the system we envision to realize the Use Cases we wish to meet?”  This might be an exercise for each of the b= ulleted items in Section 2 proper, and then further for each subsection th= erein. 

 

Any thoughts or comment= s on taking this approach to the requirements? 

 

Regards,

 

Adam<= /p>

 

 

 

 

 

 

 

From: sac= m-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, October 14, 2013 1:43 PM
To: sacm@ietf.org
Subject: [sacm] Rough work in progress for Requirements<= /span>

 

Folks,<= /p>

 <= /p>

As the submission deadlin= e is today, I've posted a skeleton draft to help us drive the Requirements= just now: http://www.ietf.org/id/draft-camwin= get-sacm-requirements-00.txt

 <= /p>

There's plenty to discuss= !

 <= /p>

Thanks, Nancy.=


...


. . .
--_000_05BCCEB107AF88469B9F99783D47C1D689AE8FCISEXCHANGE1msisa_-- From gunnar.engelbach@threatguard.com Wed Oct 16 09:06:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD0621F9FD7 for ; Wed, 16 Oct 2013 09:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8d6ScBvjfNLp for ; Wed, 16 Oct 2013 09:06:01 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3798921F9DD0 for ; Wed, 16 Oct 2013 09:05:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=oYW2iLhM2Ss3iWzE8fYX8hp6nXbmCKx01bGYdOF1Go7+s9E1sJJdYPx/D3mcoMQrYWr3B4vQ1dJRvgB65Wc2oWNvOihaJiPkmibiQ4Fx/SviLR6kv/IGKUye7AJBLrAa; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 18406 invoked from network); 16 Oct 2013 09:07:39 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Oct 2013 09:07:39 -0700 Message-ID: <525EB962.9070209@ThreatGuard.com> Date: Wed, 16 Oct 2013 12:05:54 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adam Montville , "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" References: <05BCCEB107AF88469B9F99783D47C1D689AE8F@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D689AE8F@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 16:06:13 -0000 Look out below... On 10/16/2013 11:40 AM, Adam Montville wrote: > Nancy, thank you for working on this! I very much like your > Architectural Design Tenets section, which I believe support our Use > Cases well. > > I would prefer to see a Requirements document free from any > architectural assumptions, such that we are able to conceive an > architecture that is truly derived from requirements – in other words, > let’s let the requirements drive the architecture, not the other way > around (I fully recognize that network architectural constraints will > affect our solution in the end). > > By my read, we have the following Use Cases present in the -02 Use Case > draft: > > 2.1 - Definition and Publication of Automatable Configuration Guides > > 2.2 - Automated Checklist Verification > > 2.3 - Organizational Software Policy Compliance > > 2.4 - Detection of Posture Deviation > > 2.5 - Search for Signs of Infection > > 2.6 - Remediation and Mitigation > > 2.7 - Endpoint Information Analysis and Reporting Let's not forget that the charter also covers interaction with a content repository. Here is a start on use cases covering that: 1 Retrieve materials necessary to perform standardized categorization of an asset (such as determine its CPE) 2 Retrieve all materials necessary to complete an automated assessment to determine the level of compliance of a Windows 7 x64 desktop machine with HIPAA regulations. 3 Retrieve materials necessary to perform evaluation of all potential vulnerabilities for iOS identified since the date xx/xx/xxxx that can yield unauthorized remote access or privilege escalation. 4 Retrieve human audience content associated with a compliance policy (such as the driving regulation, security training videos, etc). 5 Register with repository for immediate notification of new security vulnerability content that match a selection filter (Filter terms could include OSs, applications, severity rating, automated check/vulnerability announcement, original content source, content author rating, etc) > > Endpoint Posture Assessment (Section 2) starts out with “collecting the > posture of a given endpoint.” I want to limit this example to that > particular statement in the -02 Use Case draft, because it applies > generally to the specific Use Cases contained in that section. > > From my perspective, requirements pertaining to that statement might > read something like the following: > > 1.The system must be capable of expressing configuration items across > technology platforms as necessary. > > 2.The expression of configuration items across technology platforms must > be extensible to account for changes to existing platforms as well as > new platforms. > > 3.The system must be capable of expressing a “platform” or “technology” > instance > > 4.The system must be capable of harvesting (collecting) configuration state > > From the other Use Cases, we might be able to add further requirements, > such as: > > 1.The system must be capable of expressing a class of platforms or > technologies > > 2.The system must be capable of performing assessment over a limited > bandwidth network > > 3.The system must be able to compare expected state against actual state > for initial analysis > > It seems that the question to ask about each of the Use Cases in the -02 > draft is: “What needs to be true of the system we envision to realize > the Use Cases we wish to meet?” This might be an exercise for each of > the bulleted items in Section 2 proper, and then further for each > subsection therein. > > Any thoughts or comments on taking this approach to the requirements? > > Regards, > > Adam > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Nancy Cam-Winget (ncamwing) > *Sent:* Monday, October 14, 2013 1:43 PM > *To:* sacm@ietf.org > *Subject:* [sacm] Rough work in progress for Requirements > > Folks, > > As the submission deadline is today, I've posted a skeleton draft to > help us drive the Requirements just now: > http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt > > There's plenty to discuss! > > Thanks, Nancy. > > > ... > > > . . . > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From dromasca@avaya.com Thu Oct 17 07:32: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 A72E121F9D22 for ; Thu, 17 Oct 2013 07:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585, 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 BhhFjXLlXdzY for ; Thu, 17 Oct 2013 07:32:42 -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 2724311E8132 for ; Thu, 17 Oct 2013 07:32:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYHAHn0X1LGmAcV/2dsb2JhbABVBYJmIThSgym6WRiBCxZtB4IlAQEBAQMSCwYRNxoGAQgNBAQBAQMCBh0DAgQwFAEGAQEFBQQTCBqHZAELnneESIo+kjETBIEpjH16PoJkNYEHA55liyWDJIIp X-IronPort-AV: E=Sophos;i="4.93,514,1378872000"; d="scan'208";a="32410132" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Oct 2013 10:32:10 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Oct 2013 10:27:48 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Thu, 17 Oct 2013 16:32:09 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: NOMCOM - Time-Critical - Final Call for Nominations Thread-Index: AQHOy0K+cko6OZy9e0GkJAHVkQ0ZYpn49MNQ Date: Thu, 17 Oct 2013 14:32:08 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1290CC07@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: NOMCOM - Time-Critical - Final Call for Nominations X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 14:32:42 -0000 DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0Zi1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTMNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3 LCAyMDEzIDU6MDkgUE0NClRvOiBJRVRGIEFubm91bmNlbWVudCBMaXN0DQpDYzogSUVURiBEaXNj dXNzDQpTdWJqZWN0OiBOT01DT00gLSBUaW1lLUNyaXRpY2FsIC0gRmluYWwgQ2FsbCBmb3IgTm9t aW5hdGlvbnMNCg0KQSBjcml0aWNhbGx5IGxvdyBudW1iZXIgb2YgcGVvcGxlIGhhdmUgYWNjZXB0 ZWQgbm9taW5hdGlvbnMgZm9yIHNvbWUgb2YgdGhlIElFU0cgb3BlbiBwb3NpdGlvbnMuICBUaGVy ZSBpcyBvbmx5IG9uZSBub21pbmVlIHBlciBzbG90IGluIEFQUCwgT1BTIGFuZCBUU1YsIG9ubHkg dHdvIGluIElOVCBhbmQgUkFJLiAgTWFueSBmb2xrcyBoYXZlIGRlY2xpbmVkIG5vbWluYXRpb25z LiAgDQoNCldoaWxlIHRoZSBOb21jb20gYXBwcmVjaWF0ZXMgdGhhdCBzdXBwb3J0IGZvciB0d28g eWVhcnMgb2YgaW50ZW5zZSBzZXJ2aWNlIGlzIGhhcmQgdG8gYXNzdXJlLCBhbmQgd2hpbGUgd2Ug YXJlIGF3YXJlIHRoYXQgdGhlcmUgaXMgbXVjaCBzdXBwb3J0IGZvciB0aGUgaW5jdW1iZW50cyB3 aG8gYXJlIHN0YW5kaW5nLCB0aGUgSUVURiBzaG91bGQgY29udGludWFsbHkgYmUgY29uc2lkZXJp bmcgd2hpY2ggbmV3IHRhbGVudCBpcyBhdmFpbGFibGUgZm9yIG91ciBsZWFkZXJzaGlwLCBhbmQg dGhlIE5vbWNvbSBwcm9jZXNzIG5lZWRzIGZvciB0aGVyZSB0byBiZSBzb21lIHJldmlldyBhbmQg ZGVsaWJlcmF0aW9uLiANCg0KVGhlcmVmb3JlLCB3ZSB1cmdlbnRseSByZXF1ZXN0IHRoYXQgbW9y ZSBub21pbmVlcyBjb21lIGZvcndhcmQuICANCg0KREVBRExJTkVTDQpOb21pbmF0aW9ucyAtIE9j dG9iZXIgMTgNClF1ZXN0aW9ubmFpcmVzIGZyb20gbm9taW5lZXMgLSBPY3RvYmVyIDI1DQoNCk5v dCBjb2luY2lkZW50YWxseSwgdGhpcyBpcyBhIGdvb2QgdGltZSB0byB0aGluayBvdmVyIGFuZCBz ZW5kIHlvdXIgY29tbWVudHMgYWJvdXQgdGhlIGN1cnJlbnQgc3RhdGVtZW50cyBvZiBkZXNpcmVk IGV4cGVydGlzZSBvZiBwb3NpdGlvbnMgLSB0aGlzIGlzIHBhcnQgb2YgdGhlIE5vbWNvbSdzIGFu bnVhbCByZXZpZXcgcHJvY2VzcyBhcyB3ZWxsLiAgU2VuZCB0aGVtIHRvIG5vbWNvbTEzQGlldGYu b3JnLg0KDQpEZWZpbml0aXZlIGxvY2F0aW9uIFsqXSBvZiB0aGUgY3VycmVudCBzdGF0ZW1lbnRz IG9uIGRlc2lyZWQgZXhwZXJ0aXNlOg0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9ub21jb20vMjAxMy9leHBlcnRpc2UvDQoNCkluc3RydWN0aW9ucyBhbmQgZGV0YWlscyBvbiBu b21pbmF0aW9uIFsqKl06DQogICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Fubi9u b21jb20vNjA2MDIvDQoNClRoYW5rcywgZXZlcnlvbmUsDQoNCkFsbGlzb24gZm9yIHRoZSBOb21j b20NCg0KWypdIFRoaXMgeWVhciB0aGUgTm9tY29tIHRvb2xzIHdlcmUgcmVjb2RlZCwgYW5kIGFs c28gdHJhbnNpdGlvbmVkIGludG8gdGhlIGRhdGF0cmFja2VyLiAgQXBvbG9naWVzIGZvciBhIG51 bWJlciBvZiBwbGFjZXMgd2hlcmUgd2UgZGlkbid0IGNhdGNoIHJlZmVyZW5jZSBlcnJvcnMuDQoN ClsqKl0gWWVzLCBhbGFzLCB0aGUgcHJldmlvdXMgY2FsbCBmb3Igbm9taW5hdGlvbnMgdXNlZCAi T0FNIiBpbnN0ZWFkIG9mICJPUFMsIiBidXQgd2UgaGF2ZSogY29ycmVjdGVkIHRoaXMgKGNoYWly J3MgcGlsb3QpIGVycm9yIHdoZXJlIGl0IG9jY3VycmVkIGluIHRoZSBOb21jb20gcGFnZXMuDQo= From david.waltermire@nist.gov Thu Oct 17 12:01:54 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDDE11E8395 for ; Thu, 17 Oct 2013 12:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiAwz-bTilEm for ; Thu, 17 Oct 2013 12:01:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 2323211E82EA for ; Thu, 17 Oct 2013 12:01:40 -0700 (PDT) Received: from BL2PR09MB036.namprd09.prod.outlook.com (10.255.229.156) by BL2PR09MB034.namprd09.prod.outlook.com (10.255.229.147) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 17 Oct 2013 19:01:32 +0000 Received: from BL2PR09MB036.namprd09.prod.outlook.com ([169.254.3.107]) by BL2PR09MB036.namprd09.prod.outlook.com ([169.254.3.250]) with mapi id 15.00.0785.001; Thu, 17 Oct 2013 19:01:32 +0000 From: "Waltermire, David A." To: "Kent_Landfield@McAfee.com" , "Gunnar.Engelbach@ThreatGuard.com" , "ncamwing@cisco.com" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn0mJqAgAADGICABJF5wA== Date: Thu, 17 Oct 2013 19:01:32 +0000 Message-ID: References: <525C48DF.8050500@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(24454002)(377454003)(199002)(189002)(407274004)(164054003)(19609705001)(80022001)(65816001)(66066001)(46102001)(15202345003)(4396001)(74662001)(74502001)(31966008)(81542001)(81686001)(33646001)(49866001)(54356001)(85306002)(81342001)(63696002)(76796001)(77982001)(76786001)(76576001)(47736001)(19300405004)(19580405001)(56816003)(77096001)(50986001)(47976001)(79102001)(81816001)(76482001)(16236675002)(80976001)(74876001)(74706001)(53806001)(54316002)(15975445006)(59766001)(47446002)(83322001)(19580395003)(56776001)(74366001)(83072001)(69226001)(74316001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR09MB034; H:BL2PR09MB036.namprd09.prod.outlook.com; CLIP:129.6.224.152; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_ac686fd109b244cf999dcd45a1bb97ccBL2PR09MB036namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 19:01:54 -0000 --_000_ac686fd109b244cf999dcd45a1bb97ccBL2PR09MB036namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reading through all the email threads getting caught up on the discuss= ion. A couple things jumped out at me in your email below: 1) First an observation. The term "assessment", as it is commonly used in t= he SACM charter, discussion, and in our drafts, encompasses both posture co= llection (the current RFC5209 definition) and posture evaluation. The wordi= ng of the definition in draft-ietf-sacm-terminology-00 could be improved to= make this more clear. In many discussions it appears that the term "assess= ment" is used interchangeably with collection or evaluation. It might be be= st to use more specific terms like posture collection and posture evaluatio= n to provide greater clarity in discussions. Thoughts? 2) In your email below you raise concerns about NEA being used as the sole = focus for assessment. What aspect of assessment are you referring to? 3) You mentioned that "there are many deployed products today that use othe= r means for assessment". Are you suggesting that there are other transports and data models for post= ure collection? Or for posture evaluation? What are they? Are these methods proprietary or standardized? Do they support use cases that are not addressed in the use case draft? If = so, what are they? Are there important requirements that need to be captured relating to these= methods? If so, what requirements? Thanks, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, October 14, 2013 3:52 PM To: Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.org Subject: Re: [sacm] Rough work in progress for Requirements There are other means to accomplish assessments and NEA was not going to be= the only direction considered. This would be a direction change from what= has been discussed in all the side meetings and BOFs leading up to the SAC= M WG creation. If this is just a document to meet the deadline, ok. I am not aware of any consensus around NEA being the sole focus or the only= assessment methodology. And if that was brought up for consideration I wou= ld vote against it. There are many deployed products today that use other = means for assessment that have proven effective. We do need to get some of= that into this working group but the focus has been on getting the archite= cture document nailed down... Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Gunnar Engelbach > Organization: ThreatGuard, Inc. Date: Monday, October 14, 2013 2:41 PM To: "Nancy Cam-Winget (ncamwing)" >, "sacm@ietf.org" > Subject: Re: [sacm] Rough work in progress for Requirements Nancy, is this just a strawman to meet the document deadline? The role of SACM as you've outlined here has changed considerably from the conversations we've been having for the past 18 months (ish). Most notably is the assumption that NEA will now be the only assessment methodology. Is that the direction SACM has decided to go? If you just need a quick ASCII architecture and text to C&P into your skeleton, how about Dave Waltermire's original draft: http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: Folks, As the submission deadline is today, I've posted a skeleton draft to help us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_ac686fd109b244cf999dcd45a1bb97ccBL2PR09MB036namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am reading through all = the email threads getting caught up on the discussion. A couple things jump= ed out at me in your email below:

 <= /p>

1) First an observation. = The term “assessment”, as it is commonly used in the SACM chart= er, discussion, and in our drafts, encompasses both posture collection (the current RFC5209 definition) and posture evaluation. The wording of th= e definition in draft-ietf-sacm-terminology-00 could be improved to make th= is more clear. In many discussions it appears that the term “assessme= nt” is used interchangeably with collection or evaluation. It might be best to use more specific terms like posture co= llection and posture evaluation to provide greater clarity in discussions. = Thoughts?

 <= /p>

2) In your email below yo= u raise concerns about NEA being used as the sole focus for assessment. Wha= t aspect of assessment are you referring to?

 <= /p>

3) You mentioned that = 220;there are many deployed products today that use other means for assessm= ent”.

 <= /p>

Are you suggesting that t= here are other transports and data models for posture collection? Or for po= sture evaluation?

 <= /p>

What are they? Are these = methods proprietary or standardized?

 <= /p>

Do they support use cases= that are not addressed in the use case draft? If so, what are they?

 <= /p>

Are there important requi= rements that need to be captured relating to these methods? If so, what req= uirements?

 <= /p>

Thanks,=

Dave

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Monday, October 14, 2013 3:52 PM
To: Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.= org
Subject: Re: [sacm] Rough work in progress for Requirements

 

There are other means to= accomplish assessments and NEA was not going to be the only direction cons= idered.  This would be a direction change from what has been discussed= in all the side meetings and BOFs leading up to the SACM WG creation.  If this is just a document to meet the d= eadline, ok. 

 =

I am not aware of any co= nsensus around NEA being the sole focus or the only assessment methodology.= And if that was brought up for consideration I would vote against it. &nbs= p;There are many deployed products today that use other means for assessment that have proven effective.  We d= o need to get some of that into this working group but the focus has been o= n getting the architecture document nailed down…

 =

Kent Landfield

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

 =

From: Gunnar Engelbach <gunnar.engelbach@threatguard.com><= br> Organization: ThreatGuard, Inc.
Date: Monday, October 14, 2013 2:41 PM
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "sacm@ietf.org" <sacm= @ietf.org>
Subject: Re: [sacm] Rough work in progress for Requirements

 =

 =

 =

Nancy, is this just a st= rawman to meet the document deadline?

 =

The role of SACM as you'= ve outlined here has changed considerably from

the conversations we've = been having for the past 18 months (ish).

 =

Most notably is the assu= mption that NEA will now be the only assessment

methodology.  = Is that the direction SACM has decided to go?

 =

 =

If you just need a quick= ASCII architecture and text to C&P into your

skeleton, how about Dave= Waltermire's original draft:

 =

 =

 =

 =

 =

 =

On 10/14/2013 2:43 PM, N= ancy Cam-Winget (ncamwing) wrote:

Folks,=

 =

As the submission deadli= ne is today, I've posted a skeleton draft to

help us drive the Requir= ements just now:

 =

There's plenty to discus= s!

 =

Thanks, Nancy.

 =

 =

________________________= _______________________

sacm mailing list

 =

________________________= _______________________

sacm mailing list

 =

--_000_ac686fd109b244cf999dcd45a1bb97ccBL2PR09MB036namprd09pro_-- From gunnar.engelbach@threatguard.com Thu Oct 17 13:40:25 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B241D11E81E4 for ; Thu, 17 Oct 2013 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 gqvuAY3gLdiZ for ; Thu, 17 Oct 2013 13:40:15 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8E11E8244 for ; Thu, 17 Oct 2013 13:40:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=Cu7falSdQfsMVLgmYE61IGifpnIseg85iQRW4scm+YphA56lfpPa1twKuZIZbCMJSJHWGgF3iwSFajOfPkoajdK4vfqdGV5YlxKg0v3YPDZ/G+x1PqNEscNID3Gp/5hj; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 7873 invoked from network); 17 Oct 2013 13:42:00 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Oct 2013 13:41:59 -0700 Message-ID: <52604B2D.1010500@ThreatGuard.com> Date: Thu, 17 Oct 2013 16:40:13 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Waltermire, David A." , "Kent_Landfield@McAfee.com" , "ncamwing@cisco.com" , "sacm@ietf.org" References: <525C48DF.8050500@ThreatGuard.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 20:40:25 -0000 Hey Dave, welcome back to the world of the working! On 10/17/2013 3:01 PM, Waltermire, David A. wrote: > I am reading through all the email threads getting caught up on the > discussion. A couple things jumped out at me in your email below: > > 1) First an observation. The term “assessment”, as it is commonly used > in the SACM charter, discussion, and in our drafts, encompasses both > posture collection (the current RFC5209 definition) and posture > evaluation. The wording of the definition in > draft-ietf-sacm-terminology-00 could be improved to make this more > clear. In many discussions it appears that the term “assessment” is used > interchangeably with collection or evaluation. It might be best to use > more specific terms like posture collection and posture evaluation to > provide greater clarity in discussions. Thoughts? To me, "assessment" implies that some sort of collection must have occurred. If it helps, I'm all for being more explicit in terminology -- although I'm sure I'll get tired of typing "posture collection and evaluation". "Assessment" and "scanning" are the terms that seem to get used most frequently and might have different meanings to different people. Maybe we should use less common terms that we define for ourselves so that people who don't read the terminology document are less likely to make a faulty interpretation. "Collection" and "evaluation" are good. I don't have any suggestions for the combined action. > > 2) In your email below you raise concerns about NEA being used as the > sole focus for assessment. What aspect of assessment are you referring to? NEA would be doing both collection and evaluation. From the reading I've done on NEA it would make available evaluation results for an endpoint, but could not be used for generic evaluations or arbitrary collection. But I'm hoping we can not worry about what NEA (or SNMP, or WBEM, or whatever) can and can't do. NEA is an existing standard that is being built into existing products -- I'd like to see if what we define can take advantage of what it does provide in the places where it is available. > > 3) You mentioned that “there are many deployed products today that use > other means for assessment”. > > Are you suggesting that there are other transports and data models for > posture collection? Or for posture evaluation? Certainly. Just do a search for security and compliance evaluation tools and most of them are using proprietary means for this. ISS, NetRanger, Nessus, ... Yeah, I'm deliberately picking older ones, but you get the point. > > What are they? Are these methods proprietary or standardized? Most are proprietary, but there are some existing standards for collection (and management) such as SNMP, WBEM, OVAL, (arguably: Puppet) and some standards that add evaluation -- NEA, OVAL, XCCDF. Certainly not an exhaustive list, but the thing is, none of these provide coverage as complete as what I think this working group is looking for. Or maybe I'm just being aspirational. I also think it's very important that the collection and evaluation content -- the automated part of the Content Repository -- should be in a standardized format, but I don't see that as excluding the use of a variety of possible collection techniques. > > Do they support use cases that are not addressed in the use case draft? > If so, what are they? And that also fall within the scope of the SACM charter? Nothing that pops into my head right now but it's a good point -- I'll keep thinking about that. > > Are there important requirements that need to be captured relating to > these methods? If so, what requirements? You mean to enable the use of them? Such as "TCP simple services must be installed and the firewall rules modified appropriately..." in order to use SNMP? > > Thanks, > > Dave > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Kent_Landfield@McAfee.com > *Sent:* Monday, October 14, 2013 3:52 PM > *To:* Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; sacm@ietf.org > *Subject:* Re: [sacm] Rough work in progress for Requirements > > There are other means to accomplish assessments and NEA was not going to > be the only direction considered. This would be a direction change from > what has been discussed in all the side meetings and BOFs leading up to > the SACM WG creation. If this is just a document to meet the deadline, ok. > > I am not aware of any consensus around NEA being the sole focus or the > only assessment methodology. And if that was brought up for > consideration I would vote against it. There are many deployed products > today that use other means for assessment that have proven effective. > We do need to get some of that into this working group but the focus > has been on getting the architecture document nailed down… > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *Gunnar Engelbach > > *Organization: *ThreatGuard, Inc. > *Date: *Monday, October 14, 2013 2:41 PM > *To: *"Nancy Cam-Winget (ncamwing)" >, "sacm@ietf.org " > > > *Subject: *Re: [sacm] Rough work in progress for Requirements > > Nancy, is this just a strawman to meet the document deadline? > > The role of SACM as you've outlined here has changed considerably from > > the conversations we've been having for the past 18 months (ish). > > Most notably is the assumption that NEA will now be the only assessment > > methodology. Is that the direction SACM has decided to go? > > If you just need a quick ASCII architecture and text to C&P into your > > skeleton, how about Dave Waltermire's original draft: > > http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 > > On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: > > Folks, > > As the submission deadline is today, I've posted a skeleton draft to > > help us drive the Requirements just now: > > http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt > > There's plenty to discuss! > > Thanks, Nancy. > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > From Adam.Montville@cisecurity.org Thu Oct 17 14:23:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F3711E8192 for ; Thu, 17 Oct 2013 14:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQdaCIVwqAOL for ; Thu, 17 Oct 2013 14:23:10 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.13]) by ietfa.amsl.com (Postfix) with ESMTP id A5EFA11E8183 for ; Thu, 17 Oct 2013 14:23:09 -0700 (PDT) Received: from [216.82.250.179:44891] by server-13.bemta-12.messagelabs.com id 1D/99-07967-B3550625; Thu, 17 Oct 2013 21:23:07 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-4.tower-210.messagelabs.com!1382044986!9039660!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 3084 invoked from network); 17 Oct 2013 21:23:07 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-4.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 17 Oct 2013 21:23:07 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 17:22:48 -0400 From: Adam Montville To: Gunnar Engelbach , "Waltermire, David A." , "Kent_Landfield@McAfee.com" , "ncamwing@cisco.com" , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn026iAgAADGICABKjJAIAAG5KA///GtGA= Date: Thu, 17 Oct 2013 21:22:48 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D68A1A2E@CISEXCHANGE1.msisac.org.local> References: <525C48DF.8050500@ThreatGuard.com> <52604B2D.1010500@ThreatGuard.com> In-Reply-To: <52604B2D.1010500@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 21:23:15 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Thursday, October 17, 2013 3:40 PM > To: Waltermire, David A.; Kent_Landfield@McAfee.com; > ncamwing@cisco.com; sacm@ietf.org > Subject: Re: [sacm] Rough work in progress for Requirements >=20 > Hey Dave, welcome back to the world of the working! >=20 >=20 > On 10/17/2013 3:01 PM, Waltermire, David A. wrote: > > I am reading through all the email threads getting caught up on the > > discussion. A couple things jumped out at me in your email below: > > > > 1) First an observation. The term "assessment", as it is commonly used= > > in the SACM charter, discussion, and in our drafts, encompasses both > > posture collection (the current RFC5209 definition) and posture > > evaluation. The wording of the definition in > > draft-ietf-sacm-terminology-00 could be improved to make this more > > clear. In many discussions it appears that the term "assessment" is > > used interchangeably with collection or evaluation. It might be best > > to use more specific terms like posture collection and posture > > evaluation to provide greater clarity in discussions. Thoughts? >=20 > To me, "assessment" implies that some sort of collection must have > occurred. If it helps, I'm all for being more explicit in terminology > -- although I'm sure I'll get tired of typing "posture collection and ev= aluation". >=20 To assess is to evaluate, so it seems that comparison of actual to expecte= d values is the "assessment" portion of what we're doing. Before you can assess, you need to have an actual value (or lack thereof),= and that might be termed harvesting, collecting, gathering. > "Assessment" and "scanning" are the terms that seem to get used most > frequently and might have different meanings to different people. Maybe= > we should use less common terms that we define for ourselves so that > people who don't read the terminology document are less likely to make a= > faulty interpretation. >=20 > "Collection" and "evaluation" are good. I don't have any suggestions fo= r the > combined action. There probably isn't a good term that explicitly encompasses both, but I d= o believe that an assessment implies that some sort of harvesting has occu= rred. Perhaps we let "assessment" mean exactly that and when we mean "compare ac= tual vs. expected" we use "evaluate"? >=20 >=20 > > > > 2) In your email below you raise concerns about NEA being used as the > > sole focus for assessment. What aspect of assessment are you referring= > to? >=20 > NEA would be doing both collection and evaluation. From the reading > I've done on NEA it would make available evaluation results for an > endpoint, but could not be used for generic evaluations or arbitrary > collection. >=20 > But I'm hoping we can not worry about what NEA (or SNMP, or WBEM, or > whatever) can and can't do. NEA is an existing standard that is being > built into existing products -- I'd like to see if what we define can > take advantage of what it does provide in the places where it is availab= le. >=20 I tend to agree with your perspective here, Dave. It seems to me that we = should remain as open as possible when it comes to data conveyance and har= vesting mechanisms. >=20 > > > > 3) You mentioned that "there are many deployed products today that use= > > other means for assessment". > > > > Are you suggesting that there are other transports and data models for= > > posture collection? Or for posture evaluation? >=20 > Certainly. Just do a search for security and compliance evaluation > tools and most of them are using proprietary means for this. ISS, > NetRanger, Nessus, ... Yeah, I'm deliberately picking older ones, but > you get the point. >=20 >=20 > > > > What are they? Are these methods proprietary or standardized? >=20 > Most are proprietary, but there are some existing standards for > collection (and management) such as SNMP, WBEM, OVAL, (arguably: > Puppet) > and some standards that add evaluation -- NEA, OVAL, XCCDF. >=20 > Certainly not an exhaustive list, but the thing is, none of these > provide coverage as complete as what I think this working group is > looking for. Or maybe I'm just being aspirational. >=20 > I also think it's very important that the collection and evaluation > content -- the automated part of the Content Repository -- should be in > a standardized format, but I don't see that as excluding the use of a > variety of possible collection techniques. >=20 >=20 > > > > Do they support use cases that are not addressed in the use case draft= ? > > If so, what are they? >=20 > And that also fall within the scope of the SACM charter? Nothing that > pops into my head right now but it's a good point -- I'll keep thinking > about that. >=20 >=20 > > > > Are there important requirements that need to be captured relating to > > these methods? If so, what requirements? >=20 > You mean to enable the use of them? Such as "TCP simple services must > be installed and the firewall rules modified appropriately..." in order > to use SNMP? >=20 >=20 >=20 > > > > Thanks, > > > > Dave > > > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On > Behalf > > Of *Kent_Landfield@McAfee.com > > *Sent:* Monday, October 14, 2013 3:52 PM > > *To:* Gunnar.Engelbach@ThreatGuard.com; ncamwing@cisco.com; > sacm@ietf.org > > *Subject:* Re: [sacm] Rough work in progress for Requirements > > > > There are other means to accomplish assessments and NEA was not going > to > > be the only direction considered. This would be a direction change fr= om > > what has been discussed in all the side meetings and BOFs leading up t= o > > the SACM WG creation. If this is just a document to meet the deadline= , ok. > > > > I am not aware of any consensus around NEA being the sole focus or the= > > only assessment methodology. And if that was brought up for > > consideration I would vote against it. There are many deployed produc= ts > > today that use other means for assessment that have proven effective. > > We do need to get some of that into this working group but the focus= > > has been on getting the architecture document nailed down... > > > > *Kent Landfield* > > > > *McAfee | An Intel Company* > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > *Web: *www.mcafee.com > > > > *From: *Gunnar Engelbach > > > > *Organization: *ThreatGuard, Inc. > > *Date: *Monday, October 14, 2013 2:41 PM > > *To: *"Nancy Cam-Winget (ncamwing)" > >, "sacm@ietf.org " > > > > > *Subject: *Re: [sacm] Rough work in progress for Requirements > > > > Nancy, is this just a strawman to meet the document deadline? > > > > The role of SACM as you've outlined here has changed considerably = from > > > > the conversations we've been having for the past 18 months (ish). > > > > Most notably is the assumption that NEA will now be the only > assessment > > > > methodology. Is that the direction SACM has decided to go? > > > > If you just need a quick ASCII architecture and text to C&P into y= our > > > > skeleton, how about Dave Waltermire's original draft: > > > > http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 > > > > On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote: > > > > Folks, > > > > As the submission deadline is today, I've posted a skeleton dr= aft to > > > > help us drive the Requirements just now: > > > > http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.tx= t > > > > There's plenty to discuss! > > > > Thanks, Nancy. > > > > _______________________________________________ > > > > 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 > ... . . . From ncamwing@cisco.com Sat Oct 19 20:25:54 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8B11E8338 for ; Sat, 19 Oct 2013 20:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY4EL11DkNTw for ; Sat, 19 Oct 2013 20:25:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EE66F11E8127 for ; Sat, 19 Oct 2013 20:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4867; q=dns/txt; s=iport; t=1382239546; x=1383449146; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=0pKF++Yr+3+dcjTirOWtiIo06LwPZUpGfpzihYrt4rs=; b=OcV2C1SkKigtM3791O9c1Ji1x4rHEF7g9iaEj6z70ZNKI9I0S7wCR4Y+ TVSe9UuHLJiEuPoP2dNRU/5BeN24itw/M94isby1aYBUDWHLLaLS4KJjn r+cQHHd5rthsSFtb6L90q1R5gwA39sxS0XnJKQPquBOTF/R3obr0cPrA0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAKVMY1KtJXG+/2dsb2JhbABagwc4VL4zgSAWdIInAQQBAQE3NB0BCA4EEBQ3CxcOAgQBEgiHfg3AAQSOK4EAOIMfgQoDqhCDJIIq X-IronPort-AV: E=Sophos;i="4.93,531,1378857600"; d="scan'208";a="274184970" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 20 Oct 2013 03:25:45 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9K3PjcK025141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Oct 2013 03:25:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sat, 19 Oct 2013 22:25:44 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Stephen Hanna , "sacm@ietf.org" Thread-Topic: [sacm] Three More SACM Use Cases Thread-Index: AQHOzUQPZ47TXqiWc0qBBR+Z20oEMw== Date: Sun, 20 Oct 2013 03:25:44 +0000 Message-ID: In-Reply-To: <226190353816423d9e3d922ee8d978b9@BLUPR05MB323.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <29AA7188B4375C45B7E5AAEBE240132A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Three More SACM Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 03:25:54 -0000 Hi Steve, Thanks for putting these together, I like the general notion of these use cases but have some questions/comments Further below: On 10/15/13 4:21 PM, "Stephen Hanna" wrote: >Here are the additional SACM use cases that I promised. >Comments are most welcome! > >After some thought, I suspect that the Remediation and >Mitigation use case is out of scope for this phase of >SACM. If others agree, we can drop that use case for >now. However, I hope that we design our architecture >and protocols to be sufficiently extensible that future >extensions can add support for that use case. > >Thanks, > >Steve > >------ > >2.5. Search for Signs of Infection > >The Example Corporation carefully manages endpoint security >with tools that implement the SACM standards. One day, the >endpoint security team at Example Corporation learns about >a stealthy malware package. This malware has just been >discovered but has already spread widely around the world. >Certain signs of infection have been identified (e.g. the >presence of certain files). The security team would like >to know which endpoints owned by the Example Corporation >have been infected with this malware. They use their tools >to search for the signs of infection and generate a list of >infected endpoints. > >The search for infected endpoints may be performed by >gathering new endpoint posture information regarding >the presence of the signs of infection. However, this >might miss finding endpoints that were previously >infected but where the infection has now erased itself. >Such previously infected endpoints may be detected >by searching a database of posture information >previously gathered for the signs of infection. >However, this will not work if the malware hides >its presence carefully or if the signs of infection >were not included in previous posture assessments. >In those cases, the database may be used to at least >detect which endpoints previously had software >vulnerable to infection by the malware. [NCW] Its not clear what this paragraph is trying to convey. That is, the example based on the first paragraph leads me to believe that this use case is about an application requesting information of endpoint's current assessments to enumerate the list of endpoints infected. I think the 2nd paragraph is further conveying that the request of an evaluator or assessment repository is to get not just current assessments but also historical ones? > >2.6. Remediation and Mitigation > >When Example Corporation discovers that one of its >endpoints is vulnerable to infection, a process of >mitigation and remediation is triggered. The first >step is mitigating the impact of the vulnerability, >perhaps by placing the endpoint into a safe network >or blocking network traffic that could infect the >endpoint. The second step is remediation: fixing >the vulnerability. In some cases, these steps may >happen automatically and rapidly. In other cases, >they may require human intervention either to >decide what response is most appropriate or to >complete the steps, which are sometimes complex. > >These same steps of mitigation and remediation may >be used when Example Corporation discovers that one >of its endpoints has become infected with some malware. >Alternatively, the infected endpoint may simply be >monitored or even placed into a honeynet or similar >environment to observe the malware's behavior and >lead the attackers astray. [NCW] I think there was consensus in the group that the mitigation/remediation process was out of scope for the charter. However, perhaps this use case can be narrowed to a continuous monitoring of the infected endpoint's assessment vs. the actual remediation action? > >2.7. Endpoint Information Analysis and Reporting > >Freed from the drudgery of manual endpoint compliance >monitoring, one of the security administrators at >Example Corporation notices (not using SACM standards) >that five endpoints have been uploading lots of data >to a suspicious server on the Internet. The administrator >queries the SACM database of endpoint posture to see >what software is installed on those endpoints and >finds that they all have a particular program installed. >She then searches the database to see which other >endpoints have that program installed. All these >endpoints are monitored carefully (not using SACM >standards), which allows the administrator to detect >that the other endpoints are also infected. > >This is just one example of the useful analysis >that a skilled analyst can do using the database >of endpoint posture that SACM can provide. > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From ncamwing@cisco.com Sat Oct 19 20:35: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 7AD0611E814E for ; Sat, 19 Oct 2013 20:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSVjYIUgeY+M for ; Sat, 19 Oct 2013 20:35:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF011E813B for ; Sat, 19 Oct 2013 20:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22737; q=dns/txt; s=iport; t=1382240122; x=1383449722; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=cp84FqTroMFgJZv/beUh13ur0+/H390LAMhsHHGV6Ys=; b=S95zzdhO4kzaakFuwN4xSF1rMdv+W15EjM1uKxR6Mkif/mfvMa7q4p6F Gx9Cn5B6RRJXZXmhRdpyAsc/6SwBbgIFSg+p4Ec9JhJPB0BozGUqrEzTE qh6roFik60vS/29f9IO4E11c5JSCSpXTIu56NougMnar45yLZneLwfY7U Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFACpPY1KtJV2Y/2dsb2JhbABagkNEOFS+M4EgFnSCJQEBAQSBCwEIEQECAQEBCwsLBzkUAwYIAgQBEggBEodrDb97jh0BgQ0GGhcBAgQEgxWBCgOqEIMkgWgBHyI X-IronPort-AV: E=Sophos;i="4.93,531,1378857600"; d="scan'208,217";a="274247328" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 20 Oct 2013 03:35:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9K3ZLqg009521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Oct 2013 03:35:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sat, 19 Oct 2013 22:35:21 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Adam Montville , "sacm@ietf.org" Thread-Topic: Rough work in progress for Requirements Thread-Index: AQHOzUVmVe6TiDAm4kCDF627TolM2Q== Date: Sun, 20 Oct 2013 03:35:20 +0000 Message-ID: In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D689AE8F@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.54] Content-Type: multipart/alternative; boundary="_000_B80278DF1B7C814184086F4A6ECB311532F26DDDxmbalnx02ciscoc_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 03:35:43 -0000 --_000_B80278DF1B7C814184086F4A6ECB311532F26DDDxmbalnx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adam, Please see further comments below: From: Adam Montville > Date: Wednesday, October 16, 2013 8:40 AM To: "ncamwing@cisco.com" >, "sacm@ietf.org" > Subject: RE: Rough work in progress for Requirements Nancy, thank you for working on this! I very much like your Architectural = Design Tenets section, which I believe support our Use Cases well. I would prefer to see a Requirements document free from any architectural a= ssumptions, such that we are able to conceive an architecture that is truly= derived from requirements =96 in other words, let=92s let the requirements= drive the architecture, not the other way around (I fully recognize that n= etwork architectural constraints will affect our solution in the end). [NCW] That is a fair comment, albeit I tend to think of them as being inter= dependent as you also note in the parenthetical note :-) By my read, we have the following Use Cases present in the -02 Use Case dra= ft: 2.1 - Definition and Publication of Automatable Configuration Guides 2.2 - Automated Checklist Verification 2.3 - Organizational Software Policy Compliance 2.4 - Detection of Posture Deviation 2.5 - Search for Signs of Infection 2.6 - Remediation and Mitigation 2.7 - Endpoint Information Analysis and Reporting Endpoint Posture Assessment (Section 2) starts out with =93collecting the p= osture of a given endpoint.=94 I want to limit this example to that partic= ular statement in the -02 Use Case draft, because it applies generally to t= he specific Use Cases contained in that section. >From my perspective, requirements pertaining to that statement might read s= omething like the following: 1. The system must be capable of expressing configuration items acros= s technology platforms as necessary. 2. The expression of configuration items across technology platforms = must be extensible to account for changes to existing platforms as well as = new platforms. 3. The system must be capable of expressing a =93platform=94 or =93te= chnology=94 instance 4. The system must be capable of harvesting (collecting) configuratio= n state [NCW] Given our charter, I am concerned that "configuration items" may be t= oo broad? I like the notions enumerated in #3 and 4=85albeit by expression= , I think you mean a common attribute/schema that allows systems to interpr= et what a "platform" is? (though, I think that is more to "endpoint" defini= tion?) as we'll also have to include characteristics like virtual, hw vs. = sw and the like=85 >From the other Use Cases, we might be able to add further requirements, suc= h as: 1. The system must be capable of expressing a class of platforms or t= echnologies 2. The system must be capable of performing assessment over a limited= bandwidth network 3. The system must be able to compare expected state against actual s= tate for initial analysis [NCW] Yes, I think some of the use cases highlight the means (both in timin= g and filtering) by which the information is to be extracted. It seems that the question to ask about each of the Use Cases in the -02 dr= aft is: =93What needs to be true of the system we envision to realize the U= se Cases we wish to meet?=94 This might be an exercise for each of the bul= leted items in Section 2 proper, and then further for each subsection there= in. Any thoughts or comments on taking this approach to the requirements? [NCW] I'm not sure I'm quite ready to call it a system :-) but I'll try to= see how I can update the draft to include some of the points above Regards, Adam From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Nancy Cam-Winget (ncamwing) Sent: Monday, October 14, 2013 1:43 PM To: sacm@ietf.org Subject: [sacm] Rough work in progress for Requirements Folks, As the submission deadline is today, I've posted a skeleton draft to help u= s drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-s= acm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. . . . --_000_B80278DF1B7C814184086F4A6ECB311532F26DDDxmbalnx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <31A0001058A5EA45988C846455A021F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Adam,

Please see further comments below:

From: Adam Montville <Adam.Montville@cisecurity.org>= ;
Date: Wednesday, October 16, 2013 8= :40 AM
To: "ncamwing@cisco.com" <ncamwing@cisco.com>, "sacm@ietf.org" <sacm@ietf.org= >
Subject: RE: Rough work in progress= for Requirements

Nancy, thank you for working on th= is!  I very much like your Architectural Design Tenets section, which = I believe support our Use Cases well.

 

I would prefer to see a Requiremen= ts document free from any architectural assumptions, such that we are able = to conceive an architecture that is truly derived from requirements =96 in other words, let=92s let the requir= ements drive the architecture, not the other way around (I fully recognize = that network architectural constraints will affect our solution in the end)= .

[NCW] That is a fair comment, albeit I tend to think of them as being = interdependent as you also note in the parenthetical note :-)

 

By my read, we have the following = Use Cases present in the -02 Use Case draft:

 

2.1 - Definition and Publication o= f Automatable Configuration Guides

2.2 - Automated Checklist Verifica= tion

2.3 - Organizational Software Poli= cy Compliance

2.4 - Detection of Posture Deviati= on

2.5 - Search for Signs of Infectio= n

2.6 - Remediation and Mitigation

2.7 - Endpoint Information Analysi= s and Reporting

 

Endpoint Posture Assessment (Secti= on 2) starts out with =93collecting the posture of a given endpoint.=94&nbs= p; I want to limit this example to that particular statement in the -02 Use Case draft, because it applies generally to the s= pecific Use Cases contained in that section.

 

From my perspective, requirements = pertaining to that statement might read something like the following:

 

1.       The system must be capable of expres= sing configuration items across technology platforms as necessary.

2.       The expression of configuration item= s across technology platforms must be extensible to account for changes to = existing platforms as well as new platforms.

3.       The system must be capable of expres= sing a =93platform=94 or =93technology=94 instance

4.       The system must be capable of harves= ting (collecting) configuration state
[NCW] Given our charter, I am concerned that "configuration items= " may be too broad?  I like the notions enumerated in #3 and 4=85= albeit by expression, I think you mean a common attribute/schema that allow= s systems to interpret what a "platform" is? (though, I think that is more to "endpoint" definition?)  as we'll a= lso have to include characteristics like virtual, hw vs. sw and the like=85=

 

From the other Use Cases, we might= be able to add further requirements, such as:

 

1.       The system must be capable of expres= sing a class of platforms or technologies

2.       The system must be capable of perfor= ming assessment over a limited bandwidth network

3.       The system must be able to compare e= xpected state against actual state for initial analysis
[NCW] Yes, I think some of the use cases highlight the means (both in = timing and filtering) by which the information is to be extracted.

 

It seems that the question to ask = about each of the Use Cases in the -02 draft is: =93What needs to be true o= f the system we envision to realize the Use Cases we wish to meet?=94  This might be an exercise for each of = the bulleted items in Section 2 proper, and then further for each subsectio= n therein. 

 

Any thoughts or comments on taking= this approach to the requirements? 
[NCW] I'm not sure I'm quite ready to call it a system :-)  but I= 'll try to see how I can update the draft to include some of the points abo= ve

 

Regards,

 

Adam

 

 

 

 

 

 

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, October 14, 2013 1:43 PM
To: sacm@ietf.org
Subject: [sacm] Rough work in progress for Requirements

 

Folks,

 

As the submission deadline is today, I've p= osted a skeleton draft to help us drive the Requirements just now: = http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri, sans-s= erif; ">

 

There's plenty to discuss!

 

Thanks, Nancy.


...

This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . .
 --_000_B80278DF1B7C814184086F4A6ECB311532F26DDDxmbalnx02ciscoc_-- From ncamwing@cisco.com Sat Oct 19 20:37: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 1033D11E810E for ; Sat, 19 Oct 2013 20:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYIea06ffAlS for ; Sat, 19 Oct 2013 20:36:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 32D2611E8143 for ; Sat, 19 Oct 2013 20:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5104; q=dns/txt; s=iport; t=1382240205; x=1383449805; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Y3H2tMCeXBJAfwT1W6/1u5VMPLtFUTyIAmN78HKsllY=; b=EBOpkbnhthvS9kIVOMaLWsBolVavPFQRuZ7simjw0484aBph5chjMhBC UgUJutYNyulSS2t5xZytezIEFcWPglkLTfmJBDe5ORlFuOzcx8I0t2gJJ 0sZsjh9y4p8h9IHumVciyk4xWbbDchDwJ5tVMr3JUdX1v4/wgR2hkF3um c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFALxOY1KtJXG//2dsb2JhbABagwc4VL4zgSAWdIIlAQEBBAEBAWsdAQgRAQMBAQEKCxIuCxQDAQUIAgQBEggBEgGHag3AB44dAYELAjgCCIMVgQoDqhCDJIFoAR8i X-IronPort-AV: E=Sophos;i="4.93,531,1378857600"; d="scan'208";a="274228813" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 20 Oct 2013 03:36:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9K3aimV016996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Oct 2013 03:36:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sat, 19 Oct 2013 22:36:44 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Gunnar Engelbach , Adam Montville , "sacm@ietf.org" Thread-Topic: [sacm] Rough work in progress for Requirements Thread-Index: AQHOzUWY2+yOH2rkjUS0ZlqBVcMbGQ== Date: Sun, 20 Oct 2013 03:36:43 +0000 Message-ID: In-Reply-To: <525EB962.9070209@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.54] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 03:37:04 -0000 Hi Gunnar, I think what you are calling out is that information could (and should?) be requested to/from not just what I was calling the Evaluators but also from modules that provide interfaces to the posture repositories=8A.so I ca= n try to update to that affect as well. Nancy On 10/16/13 9:05 AM, "Gunnar Engelbach" wrote: > >Look out below... > > >On 10/16/2013 11:40 AM, Adam Montville wrote: >> Nancy, thank you for working on this! I very much like your >> Architectural Design Tenets section, which I believe support our Use >> Cases well. >> >> I would prefer to see a Requirements document free from any >> architectural assumptions, such that we are able to conceive an >> architecture that is truly derived from requirements =AD in other words, >> let=B9s let the requirements drive the architecture, not the other way >> around (I fully recognize that network architectural constraints will >> affect our solution in the end). >> >> By my read, we have the following Use Cases present in the -02 Use Case >> draft: >> >> 2.1 - Definition and Publication of Automatable Configuration Guides >> >> 2.2 - Automated Checklist Verification >> >> 2.3 - Organizational Software Policy Compliance >> >> 2.4 - Detection of Posture Deviation >> >> 2.5 - Search for Signs of Infection >> >> 2.6 - Remediation and Mitigation >> >> 2.7 - Endpoint Information Analysis and Reporting > > >Let's not forget that the charter also covers interaction with a content >repository. Here is a start on use cases covering that: > > >1 Retrieve materials necessary to perform standardized categorization of >an asset (such as determine its CPE) > >2 Retrieve all materials necessary to complete an automated assessment >to determine the level of compliance of a Windows 7 x64 desktop machine >with HIPAA regulations. > >3 Retrieve materials necessary to perform evaluation of all potential >vulnerabilities for iOS identified since the date xx/xx/xxxx that can >yield unauthorized remote access or privilege escalation. > >4 Retrieve human audience content associated with a compliance policy >(such as the driving regulation, security training videos, etc). > >5 Register with repository for immediate notification of new security >vulnerability content that match a selection filter (Filter terms could >include OSs, applications, severity rating, automated >check/vulnerability announcement, original content source, content >author rating, etc) > > >> >> Endpoint Posture Assessment (Section 2) starts out with =B3collecting th= e >> posture of a given endpoint.=B2 I want to limit this example to that >> particular statement in the -02 Use Case draft, because it applies >> generally to the specific Use Cases contained in that section. >> >> From my perspective, requirements pertaining to that statement might >> read something like the following: >> >> 1.The system must be capable of expressing configuration items across >> technology platforms as necessary. >> >> 2.The expression of configuration items across technology platforms must >> be extensible to account for changes to existing platforms as well as >> new platforms. >> >> 3.The system must be capable of expressing a =B3platform=B2 or =B3techno= logy=B2 >> instance >> >> 4.The system must be capable of harvesting (collecting) configuration >>state >> >> From the other Use Cases, we might be able to add further requirements, >> such as: >> >> 1.The system must be capable of expressing a class of platforms or >> technologies >> >> 2.The system must be capable of performing assessment over a limited >> bandwidth network >> >> 3.The system must be able to compare expected state against actual state >> for initial analysis >> >> It seems that the question to ask about each of the Use Cases in the -02 >> draft is: =B3What needs to be true of the system we envision to realize >> the Use Cases we wish to meet?=B2 This might be an exercise for each of >> the bulleted items in Section 2 proper, and then further for each >> subsection therein. >> >> Any thoughts or comments on taking this approach to the requirements? >> >> Regards, >> >> Adam >> >> *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf >> Of *Nancy Cam-Winget (ncamwing) >> *Sent:* Monday, October 14, 2013 1:43 PM >> *To:* sacm@ietf.org >> *Subject:* [sacm] Rough work in progress for Requirements >> >> Folks, >> >> As the submission deadline is today, I've posted a skeleton draft to >> help us drive the Requirements just now: >> http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt >> >> There's plenty to discuss! >> >> Thanks, Nancy. >> >> >> ... >> >> >> . . . >> >> >> _______________________________________________ >> 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 internet-drafts@ietf.org Sat Oct 19 04:03:17 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC511E81A9; Sat, 19 Oct 2013 04:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, 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 6lColU2dC+-W; Sat, 19 Oct 2013 04:03:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0111E818E; Sat, 19 Oct 2013 04:03:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019110315.9630.5419.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 04:03:15 -0700 X-Mailman-Approved-At: Sun, 20 Oct 2013 02:02:37 -0700 Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-terminology-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 11:03:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Security Automation and Continuous Monito= ring Working Group of the IETF. Title : Terminology for Security Assessment Author(s) : David Waltermire Adam W. Montville David Harrington Filename : draft-ietf-sacm-terminology-01.txt Pages : 7 Date : 2013-10-19 Abstract: This memo documents terminology used in the documents produced by the SACM WG (Security Automation and Continuous Monitoring). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-terminology-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-terminology-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Oct 19 04: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 0DC4C11E81A4; Sat, 19 Oct 2013 04:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 kBzpSQA2IT7s; Sat, 19 Oct 2013 04:05:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7FE11E813A; Sat, 19 Oct 2013 04:05:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019110527.9565.12996.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 04:05:27 -0700 X-Mailman-Approved-At: Sun, 20 Oct 2013 02:02:37 -0700 Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-use-cases-03.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 11:05:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Security Automation and Continuous Monito= ring Working Group of the IETF. Title : Endpoint Security Posture Assessment - Enterprise Use Ca= ses Author(s) : David Waltermire David Harrington Filename : draft-ietf-sacm-use-cases-03.txt Pages : 17 Date : 2013-10-19 Abstract: This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Adam.Montville@cisecurity.org Mon Oct 21 06:44: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 8D0B211E8544 for ; Mon, 21 Oct 2013 06:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR6l8s+qx0Mp for ; Mon, 21 Oct 2013 06:44:19 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id 4070511E855F for ; Mon, 21 Oct 2013 06:44:08 -0700 (PDT) Received: from [216.82.253.227:63018] by server-14.bemta-7.messagelabs.com id 5E/A1-07572-5AF25625; Mon, 21 Oct 2013 13:44:05 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-7.tower-170.messagelabs.com!1382363044!28338192!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 28804 invoked from network); 21 Oct 2013 13:44:05 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-7.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 21 Oct 2013 13:44:05 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Mon, 21 Oct 2013 09:43:38 -0400 From: Adam Montville To: "Nancy Cam-Winget (ncamwing)" , "sacm@ietf.org" Thread-Topic: Rough work in progress for Requirements Thread-Index: AQHOyQ08t47qIYwNoU2LhvacHOwznpn3cUuggAXKdgCAAfesEA== Date: Mon, 21 Oct 2013 13:43:38 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D68A3748@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D689AE8F@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D68A3748CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [sacm] Rough work in progress for Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:44:28 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D68A3748CISEXCHANGE1msisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Nancy Cam-Winget (ncamwing) [mailto:ncamwing@cisco.com] Sent: Saturday, October 19, 2013 10:35 PM To: Adam Montville; sacm@ietf.org Subject: Re: Rough work in progress for Requirements Hi Adam, Please see further comments below: From: Adam Montville > Date: Wednesday, October 16, 2013 8:40 AM To: "ncamwing@cisco.com" >, "sacm@ietf.org" > Subject: RE: Rough work in progress for Requirements Nancy, thank you for working on this! I very much like your Architectural= Design Tenets section, which I believe support our Use Cases well. I would prefer to see a Requirements document free from any architectural = assumptions, such that we are able to conceive an architecture that is tru= ly derived from requirements - in other words, let's let the requirements = drive the architecture, not the other way around (I fully recognize that n= etwork architectural constraints will affect our solution in the end). [NCW] That is a fair comment, albeit I tend to think of them as being inte= rdependent as you also note in the parenthetical note :-) [AWM] Agreed. Iteration will typically have additional constraints being = discovered as architectures meeting initial requirements are contemplated.= My goal is to be as clean as possible in this first pass - may or may no= t be a reasonable goal from the sacm-community-perspective. By my read, we have the following Use Cases present in the -02 Use Case dr= aft: 2.1 - Definition and Publication of Automatable Configuration Guides 2.2 - Automated Checklist Verification 2.3 - Organizational Software Policy Compliance 2.4 - Detection of Posture Deviation 2.5 - Search for Signs of Infection 2.6 - Remediation and Mitigation 2.7 - Endpoint Information Analysis and Reporting Endpoint Posture Assessment (Section 2) starts out with "collecting the po= sture of a given endpoint." I want to limit this example to that particul= ar statement in the -02 Use Case draft, because it applies generally to th= e specific Use Cases contained in that section. >From my perspective, requirements pertaining to that statement might read = something like the following: 1. The system must be capable of expressing configuration items acro= ss technology platforms as necessary. 2. The expression of configuration items across technology platforms= must be extensible to account for changes to existing platforms as well a= s new platforms. 3. The system must be capable of expressing a "platform" or "technol= ogy" instance 4. The system must be capable of harvesting (collecting) configurati= on state [NCW] Given our charter, I am concerned that "configuration items" may be = too broad? I like the notions enumerated in #3 and 4...albeit by expressi= on, I think you mean a common attribute/schema that allows systems to inte= rpret what a "platform" is? (though, I think that is more to "endpoint" de= finition?) as we'll also have to include characteristics like virtual, hw= vs. sw and the like... [AWM] Scoping will be an ongoing issue. The reality is, I believe, that c= onfiguration items are important as they relate to the security of a given= endpoint, and this changes with time. It might well be that a particular= configuration item is not deemed a "security-relevant-configuration-item"= until tomorrow when it is leveraged in some way by an adversary. So, "co= nfiguration item" is broad, but necessarily so. We need not encompass the= whole set of "configuration items" at the outset, however - the basics sh= ould suffice. Extension and modification are going to be the important pi= eces of this, I think. >From the other Use Cases, we might be able to add further requirements, su= ch as: 1. The system must be capable of expressing a class of platforms or = technologies 2. The system must be capable of performing assessment over a limite= d bandwidth network 3. The system must be able to compare expected state against actual = state for initial analysis [NCW] Yes, I think some of the use cases highlight the means (both in timi= ng and filtering) by which the information is to be extracted. It seems that the question to ask about each of the Use Cases in the -02 d= raft is: "What needs to be true of the system we envision to realize the U= se Cases we wish to meet?" This might be an exercise for each of the bull= eted items in Section 2 proper, and then further for each subsection there= in. Any thoughts or comments on taking this approach to the requirements? [NCW] I'm not sure I'm quite ready to call it a system :-) but I'll try t= o see how I can update the draft to include some of the points above [AWM] Ha! Yes, I agree, but I really didn't know what other term to use i= n reference to the whole. :) Regards, Adam From: sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Nancy Cam-Winget (ncamwing) Sent: Monday, October 14, 2013 1:43 PM To: sacm@ietf.org Subject: [sacm] Rough work in progress for Requirements Folks, As the submission deadline is today, I've posted a skeleton draft to help = us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget= -sacm-requirements-00.txt There's plenty to discuss! Thanks, Nancy. ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissem= ination, distribution or copying of this message and attachments is strict= ly prohibited. Please notify the sender immediately and permanently delete= the message and any attachments. . . . ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D68A3748CISEXCHANGE1msisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Nan= cy Cam-Winget (ncamwing) [mailto:ncamwing@cisco.com]
Sent: Saturday, October 19, 2013 10:35=20PM
To: Adam Montville; sacm@ietf.org
Subject: Re: Rough work in progress for Requirements

 

Hi Adam,

 <= /p>

Please see further commen= ts below:

 <= /p>

From: Adam Montville <Adam.Montville@cisecurity.org>
Date: Wednesday, October 16, 2013 8:40 AM
To: "ncamwing@cisco.com<= /a>" <ncamwing@cisco.com= >, "sacm@ietf.org" <<= a href=3D"mailto:sacm@ietf.org">sacm@ietf.org>
Subject: RE: Rough work in progress for Requirements

 <= /p>

Nancy, thank you for wo= rking on this!  I very much like your Architectural Design Tenets sec= tion, which I believe support our Use Cases well.

 

I would prefer to see a= Requirements document free from any architectural assumptions, such that = we are able to conceive an architecture that is truly derived from requirements – in other words, let’s let the requirement= s drive the architecture, not the other way around (I fully recognize that= network architectural constraints will affect our solution in the end).

[NCW] That is a fair comm= ent, albeit I tend to think of them as being interdependent as you also no= te in the parenthetical note :-)

[AWM] Agreed.&nbs= p; Iteration will typically have additional constraints being discovered a= s architectures meeting initial requirements are contemplated.  My goal is to be as clean as possible in this first pass – may or m= ay not be a reasonable goal from the sacm-community-perspective.

 <= /p>

 

By my read, we have the= following Use Cases present in the -02 Use Case draft:

 

2.1 - Definition and Pu= blication of Automatable Configuration Guides

2.2 - Automated Checkli= st Verification

2.3 - Organizational So= ftware Policy Compliance

2.4 - Detection of Post= ure Deviation

2.5 - Search for Signs = of Infection

2.6 - Remediation and M= itigation

2.7 - Endpoint Informat= ion Analysis and Reporting

 

Endpoint Posture Assess= ment (Section 2) starts out with “collecting the posture of a given = endpoint.”  I want to limit this example to that particular sta= tement in the -02 Use Case draft, because it applies generally to the specific U= se Cases contained in that section.

 

From my perspective, re= quirements pertaining to=20that statement might read something like the fo= llowing:

 

1. =       The system must be capable of expressin= g configuration items across technology platforms as necessary.

2. =       The expression of configuration items a= cross technology platforms must be extensible to account for changes to ex= isting platforms as well as new platforms.

3. =       The system must be capable of expressin= g a “platform” or “technology” instance

4. =       The system must be capable of harvestin= g (collecting) configuration state=

[NCW] Given our charter, = I am concerned that "configuration items" may be too broad? &nbs= p;I like the notions enumerated in #3 and 4…albeit by expression, I = think you mean a common attribute/schema that allows systems to interpret what = a "platform" is? (though, I think that is more to "endpoint= " definition?)  as we'll also have to include characteristics li= ke virtual, hw vs. sw and the like…

[AWM] Scoping wil= l be an ongoing issue.  The reality is, I believe, that configuration= items are important as they relate to the security of a given endpoint, and this changes with time.  It might well be that a particular conf= iguration item is not deemed a “security-relevant-configuration-item= ” until tomorrow when it is leveraged in some way by an adversary.&n= bsp; So, “configuration item” is broad, but necessarily so.&nb= sp; We need not encompass the whole set of “configuration items” = at the outset, however – the basics should suffice.  Extension = and modification are going to be the important pieces of this, I think.

 

From the other Use Case= s, we might be able to add further requirements, such as:

 

1. =       The system must be capable of expressin= g a class of platforms or technologies<= o:p>

2. =       The system must be capable of performin= g assessment over a limited bandwidth network

3. =       The system must be able to compare expe= cted state against actual state for initial analysis

[NCW] Yes, I think some o= f the use cases highlight the means (both in timing and filtering) by whic= h the information is to be extracted.

 

It seems that the quest= ion to ask about each of the Use Cases in the -02 draft is: “What ne= eds to be true of the system we envision to realize the Use Cases we wish to meet?”  This might be an exercise for each of the b= ulleted items in Section 2 proper, and then further for each subsection th= erein. 

 

Any thoughts or comment= s on taking this approach to the requirements? 

[NCW] I'm not sure I'm qu= ite ready to call it a system :-)  but I'll try to see how I can upda= te the draft to include some of the points above

[AWM] Ha!  Y= es, I agree, but I really didn’t know what other term to use in refe= rence to the whole. J

 =

 =

 

 

Regards,

 

Adam

 

 

 

 

 

 

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, October 14, 2013 1:43 PM
To: sacm@ietf.org
Subject: [sacm] Rough work in progress for Requirements

 

Folks,

 

As=20the submission deadl= ine is today, I've posted a skeleton draft to help us drive the Requiremen= ts just now: http:= //www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt=

 

There's plenty to discuss= !

 

Thanks, Nancy.


...

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


...


. . .
--_000_05BCCEB107AF88469B9F99783D47C1D68A3748CISEXCHANGE1msisa_-- From ietfdbh@comcast.net Mon Oct 21 13:50: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 4E45111E8436 for ; Mon, 21 Oct 2013 13:50:45 -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 gwaWT9Wjl1UT for ; Mon, 21 Oct 2013 13:50:40 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id EEABC11E81FD for ; Mon, 21 Oct 2013 13:50:32 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id foUE1m0010xGWP855wqXhX; Mon, 21 Oct 2013 20:50:31 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta12.westchester.pa.mail.comcast.net with comcast id fwqX1m00h2yZEBF3YwqXuA; Mon, 21 Oct 2013 20:50:31 +0000 From: "ietfdbh" To: References: <20131021204316.32561.8487.idtracker@ietfa.amsl.com> In-Reply-To: <20131021204316.32561.8487.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 16:50:29 -0400 Message-ID: <00ff01cece9f$2d9a4550$88cecff0$@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: AQGNB8ynmVnoXC1eJ3Zuez5Pfzv5fJqDLTyw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382388631; bh=bn28PQedisV6bETq7zPzfzufmbBwyUiB7NLPnNaPUUw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=He5F77VMxafg2Kv927BuLt2isITYFq0N7VoAP00n03Bn8MTCb47tXfwUPFAS5HksU srPUsyt2/DdE1RhkajxF8LZEC9it7zTxjXPxGvX2xkPI5UuAL4vQo2+Z9a8Ed0Xktf m6slxVs44e1S3w6O2p28HWCpdN9MZHQEIyCUyEzSvCWUUo1eFffcz4+Q86iDB6qOs6 pFdZ6nZdf4fAoIXGN3dQVDcUNURZBV1a5z/AW2JO3Vpbk1NPonpYq7Nzurc6tDbR7Y DaiCBvfURY6QoScAvc+Rv6pL8GDjO3wscqRdv5R3KiKLZmHYcArBnBTEcT5S3a63nX WoQ8nizrBiwjQ== Subject: [sacm] FW: I-D Action: draft-ietf-sacm-use-cases-04.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:50:45 -0000 Hi, Revision #2 had four use cases. Revision #4 has eighteen use cases. Dave W, Steve and Gunnar have been especially busy ... Please review the use cases and comment. Thanks, David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, October 21, 2013 4:43 PM > To: i-d-announce@ietf.org > Cc: sacm@ietf.org > Subject: I-D Action: draft-ietf-sacm-use-cases-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Security Automation and Continuous > Monitoring Working Group of the IETF. > > Title : Endpoint Security Posture Assessment - Enterprise Use > Cases > Author(s) : David Waltermire > David Harrington > Filename : draft-ietf-sacm-use-cases-04.txt > Pages : 18 > Date : 2013-10-21 > > Abstract: > This memo documents a sampling of use cases for securely aggregating > configuration and operational data and evaluating that data to > determine an organization's security posture. From these operational > use cases, we can derive common functional capabilities and > requirements to guide development of vendor-neutral, interoperable > standards for aggregating and evaluating data relevant to security > posture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Mon Oct 21 13:43:17 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574B611E8214; Mon, 21 Oct 2013 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, 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 59obZDHqb2EX; Mon, 21 Oct 2013 13:43:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E711E8422; Mon, 21 Oct 2013 13:43:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021204316.32561.8487.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 13:43:16 -0700 X-Mailman-Approved-At: Mon, 21 Oct 2013 13:52:59 -0700 Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-use-cases-04.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:43:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Security Automation and Continuous Monito= ring Working Group of the IETF. Title : Endpoint Security Posture Assessment - Enterprise Use Ca= ses Author(s) : David Waltermire David Harrington Filename : draft-ietf-sacm-use-cases-04.txt Pages : 18 Date : 2013-10-21 Abstract: This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfdbh@comcast.net Mon Oct 21 16:17: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 9D1C611E8460 for ; Mon, 21 Oct 2013 16:17:28 -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 orMWqOm-OxdL for ; Mon, 21 Oct 2013 16:17:24 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id C81DA11E844F for ; Mon, 21 Oct 2013 16:17:23 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta06.westchester.pa.mail.comcast.net with comcast id fxi71m0020cZkys56zHP1l; Mon, 21 Oct 2013 23:17:23 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id fzFP1m00E2yZEBF3WzFPzv; Mon, 21 Oct 2013 23:15:23 +0000 From: "ietfdbh" To: Date: Mon, 21 Oct 2013 19:15:21 -0400 Message-ID: <011a01ceceb3$6a6317f0$3f2947d0$@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: Ac7OpSVwj/HG00ZWT7aKJLUVL/1RGQ== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382397443; bh=1M9HX0qz6ISnpiOyHfqMsFd1aMAcfH9rESjm8swVgeY=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=tLWtBc/Gx/OE2ZUFAZCh2H+HObeb/jAB1PhHBpvWCqudZwoQZ1Uxy6O8Pvn1fLbpW B/gH/TU//7C8aTy6CaOEuvETsnCFGK+Xag+6WM0hAuI1iC9FhvaoFBFCQMLJsro0Xz GvIkrQIvf0mfpAz0/dUSkyw71YPxnbGHVrkHVmqq/Z04Pzq3hdMPbj9SbK/FZ3TqXJ PuAJ/oTzSIgBkSlluB7LsS0bh6GDp3kG9opXC7omjaoFoQeXhDvec8EOUDKE17p4zm tXwn9aEgAVJAxCnRTFMI0gPSpY136AyrnAKGpDXLENoyb/FB7lkufOEHjoxez/eOyt NDvltuQdsdfFQ== Subject: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:17:28 -0000 Hi, I have reviewed this document and have some comments. 1) section 2 - update to reference the ietf-sacm-terminology draft. 2) section 3.1 uses Asset in the diagram. Since we are focusing on endpoint assessment, should the diagram utilize endpoint rather than asset? Asset evaluation might be a larger scope than the endpoints we are discussing. 3)"Evaluator is the service that affects ..."; Dave and I have been trying to make the language less ambiguous by using "collects" and "evaluates". I don't know what "affects" means here. There is also the question of whether the collector and the evaluator are necessarily the same entity. 4) section 3.1 states that the focus will be the data models, protocols, and transport for B. I haven't seen WG consensus that this is the limit of our scope. I have recently edited quite a few use cases that cover more scope than B. 5) There is an "Abbreviated Title" on every page. Please edit the xml2rfc field (assuming the source is in xml2rfc format). 6) In 3.3, there are places with "> characters at the end of the lines. 7) We also should run a spellchecker when possible. s/recieve/receive/ See http://tools.ietf.org/tools/idspell/webservice 8) section 3.2 states a number of requirements that I have not seen discussed on the WG mailing list, or in the use cases submitted for inclusion in the use-cases document. I thought the goal was to have the use cases drive the requirements. 9) section 3.3 Discovery says that evaluators and consumers should be registered. I haven't seen use cases that claim a need for such a thing. Is this requirement about a central registration database or something? Who would be responsible for maintaining such a database? I'm not sure we'll get IETF consensus for such a central authority for sacm. Or is this thinking in terms of existing standards, such as dns or dhcp, or something similar? 10) There are requirements for "lightweight representations" and "bulk updates". I wonder if these "requirements" might be better described in use cases, rather than in requirements. Part of the problem I see is that large databases might be repositories used by an evaluator or consumer, where the large database would likely be local to the consumer. But the collector of attributes from an endpoint might utilize one or more lightweight protocol/data model to collect from endpoints, and the large database might represent the aggregation of multiple lightweight queries. Until we begin to look at specific data models, scaling might not become a requirement. For example, SNMP is a lightweight protocol, and MIB modules are typically lightweight data models, but they are often used to manage very large networks, aggregating data into large local databases. Where bulk updates of large collections of attributes, such as routing tables, are needed, protocols such as Netconf might be more effective. Where speed is of the essence, a lightweight notification protocol such a syslog might be effective. But these features are not required of all implementations/deployments (i.e. use cases). So I recommend describing the use cases that require these features, rather than simply declaring them requirements, so we can discuss which "requirements" apply to which use cases, and why. 11) Some of these requirements seem to be "Mom and Apple Pie" types of requirements. We might want to simply build a list of requirements that MUST be met if we expect the IETF/IESG to approve data models or protocols or transports recommended by sacm WG. The thing is, most existing IETF standards already support internationalization (where appropriate), scalability, interoperability, implementation of strong security, deployment of varied levels of security (as applicable to the environment), discovery (when appropriate), extensible data modeling, and so on. So I'm not sure we need to list these, but it might be helpful to readers coming from outside the IETF. These are normal requirements or recommendations for IETF standardization, and are typically documented in some RFCs (BCPs) already. I can help to identify a number of them, such as RFC 3365, 5706, 7013, 6684, 6087, 4290, 4181, 3439, 5405, 6365, and so on. (Some of these are guidelines for using specific protocols or designing data models, but could be applicable to new designs as well). What we really need to work on understanding are requirements of specific use cases, such as endpoints reporting information subject to privacy regulations such as medical databases, or querying attributes from endpoints that have constrained resources like building automation sensors, or querying information from endpoints with slow or intermittent connectivity, such as an arctic research station or a space station. -- Maybe we need to extract the architectural requirements from the use cases to start, then develop a general proposed architecture to model the many-to-many relationships and potential domain crossings, and so on discussed in the use cases. Then we could move onto requirements for the application protocols between architectural entities (e.g., bulk retrieval, asynchronous notifications,etc.), the requirements for the underlying transports (e.g., security, reliability), and the requirements for data models (e.g., internationalization) David Harrington ietfdbh@comcast.net +1-603-828-1401 From Adam.Montville@cisecurity.org Tue Oct 22 07:38:00 2013 Return-Path: <Adam.Montville@cisecurity.org> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A51811E849A for <sacm@ietfa.amsl.com>; Tue, 22 Oct 2013 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyrdqPjvrloK for <sacm@ietfa.amsl.com>; Tue, 22 Oct 2013 07:37:42 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id 84A6E11E81A7 for <sacm@ietf.org>; Tue, 22 Oct 2013 07:37:13 -0700 (PDT) Received: from [216.82.253.243:7644] by server-9.bemta-7.messagelabs.com id 8A/24-08372-69D86625; Tue, 22 Oct 2013 14:37:10 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-171.messagelabs.com!1382452629!24807558!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 23212 invoked from network); 22 Oct 2013 14:37:10 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 22 Oct 2013 14:37:10 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Tue, 22 Oct 2013 10:36:41 -0400 From: Adam Montville <Adam.Montville@cisecurity.org> To: "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: Focusing in Vancouver Thread-Index: Ac7PNBCwvEwLt/AVQ1mPNL3IuEdrYw== Date: Tue, 22 Oct 2013 14:36:42 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D68A8183@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Focusing in Vancouver X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 14:38:00 -0000 Thanks to David and Nancy for getting updated versions of the Use Cases an= d Requirements documents (respectively) submitted! At this point, I think it would be useful to use the Trac system to facili= tate discussions for each of the 18 identified use cases. The sacm Trac = report page is here: http://tools.ietf.org/wg/sacm/trac/report. The goal of trying Trac at this point would be to quickly get to conclusio= n on those use cases where there is clear understanding and consensus and = identify those upon which we will need to focus energy in Vancouver. If there are no strong objections, I can (or perhaps David H. and/or David= W.) create tickets in the system. Adam . . . From kimberly.watson@hq.dhs.gov Tue Oct 22 13:19:01 2013 Return-Path: <kimberly.watson@hq.dhs.gov> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F329E11E8268 for <sacm@ietfa.amsl.com>; Tue, 22 Oct 2013 13:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxrsnzx9ZHFR for <sacm@ietfa.amsl.com>; Tue, 22 Oct 2013 13:18:56 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id EB1C721F9A6D for <sacm@ietf.org>; Tue, 22 Oct 2013 13:18:55 -0700 (PDT) Received: from mail156-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Oct 2013 20:18:55 +0000 Received: from mail156-ch1 (localhost [127.0.0.1]) by mail156-ch1-R.bigfish.com (Postfix) with ESMTP id D8B2F2001FD for <sacm@ietf.org>; Tue, 22 Oct 2013 20:18:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:216.81.82.137; KIP:(null); UIP:(null); IPV:NLI; H:d2iblprhq100.dhs.gov; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zz9371I542I1521Idbf2izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068h1d68deh1b08bcihz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail156-ch1 (localhost.localdomain [127.0.0.1]) by mail156-ch1 (MessageSwitch) id 1382473081916156_4040; Tue, 22 Oct 2013 20:18:01 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail156-ch1.bigfish.com (Postfix) with ESMTP id 0C825201CE for <sacm@ietf.org>; Tue, 22 Oct 2013 20:18:00 +0000 (UTC) Received: from d2iblprhq100.dhs.gov (216.81.82.137) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Oct 2013 20:17:59 +0000 Received: from D2IBLPRHQ105.dhs.gov (192.168.49.135) by D2IBLPRHQ100.dhs.gov (10.82.0.51) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Oct 2013 16:17:34 -0400 Received: from D2ABLPRHQ103.DSA.DHS (10.237.115.14) by D2IBLPRHQ105.dhs.gov (10.82.4.52) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 22 Oct 2013 16:48:48 -0400 Received: from D2ASEPREA006.DSA.DHS ([169.254.10.234]) by D2ABLPRHQ103.DSA.DHS ([fe80::15d4:e9b9:8b5:7449%10]) with mapi id 14.02.0342.003; Tue, 22 Oct 2013 16:17:57 -0400 From: "Watson, Kimberly" <kimberly.watson@hq.dhs.gov> To: "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: AQHOz1mehA5UZiAmaUGOnObhVxkJipoBIPMQ Date: Tue, 22 Oct 2013 20:17:57 +0000 Message-ID: <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> In-Reply-To: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.235.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hq.dhs.gov X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 20:19:01 -0000 I strongly agree with points 3 and 4 below. Once you separate the actions of collection and evaluation - and I think yo= u must to ensure flexibility and scalability in posture assessment processe= s and capabilities - you must extend the scope to data models for A and pos= sibly even C/repository at a minimum. Most of the use cases expound on the = need to evaluate data already collected to assess a newly-defined posture r= equirement/concern. If you do not extend to A (and maybe C - I can't tell i= f defining A is enough to allow for querying/use of data in the evaluator r= epository by other processes) then you can indirectly tie deploying/impleme= nting a new evaluator to collect the information required for a new assess= ment even if you already have collected that data in a different evaluator.= =20 If I look at your simplistic architecture picture, all data collected and s= tored/passed to an evaluator must use standard data models such that all ev= aluators store this data the same for multiple assessment consumers to requ= est evaluation from multiple evaluators and get consistent answers. In my u= nderstanding B is about asking questions/directing evaluation in a standard= ized way and receiving standardized answers. I need to know that the conver= sion of information collected using A has been translated/stored in a stand= ardized fashion to ensure that the evaluation performed by different evalua= tors collecting the same data will produce the same assessment result. Being new to this forum and having read only the three new documents, it is= quite possible that I am misunderstanding something and expressing a conce= rn that isn't valid...but I was very surprised after reading all the use ca= ses to see the architecture picture expressly state evaluation but not coll= ection, and limit scope to just B. my current operational issues are in sta= ndardizing the collection and storage of endpoint posture attributes for re= use by multiple assessment processes that are constantly defining new crite= ria and policy for evaluation and posture validation. Most of the use cases= appear to have this same need at their core. -- Kim Watson Office of Cybersecurity and Communications Federal Network Resilience Blackberry: (202) 494-2534 -----Original Message----- From: ietfdbh [mailto:ietfdbh@comcast.net]=20 Sent: Monday, October 21, 2013 7:15 PM To: sacm@ietf.org Subject: [sacm] review of draft-camwinget-sacm-requirements-01.txt Hi, I have reviewed this document and have some comments. 1) section 2 - update to reference the ietf-sacm-terminology draft. 2) section 3.1 uses Asset in the diagram. Since we are focusing on endpoint= assessment, should the diagram utilize endpoint rather than asset? Asset e= valuation might be a larger scope than the endpoints we are discussing. 3)"Evaluator is the service that affects ..."; Dave and I have been trying = to make the language less ambiguous by using "collects" and "evaluates". I = don't know what "affects" means here. There is also the question of whether= the collector and the evaluator are necessarily the same entity.=20 4) section 3.1 states that the focus will be the data models, protocols, an= d transport for B. I haven't seen WG consensus that this is the limit of ou= r scope. I have recently edited quite a few use cases that cover more scope= than B. 5) There is an "Abbreviated Title" on every page. Please edit the xml2rfc <= title> field (assuming the source is in xml2rfc format). 6) In 3.3, there are places with "> characters at the end of the lines.=20 7) We also should run a spellchecker when possible. s/recieve/receive/ See= http://tools.ietf.org/tools/idspell/webservice 8) section 3.2 states a number of requirements that I have not seen discuss= ed on the WG mailing list, or in the use cases submitted for inclusion in t= he use-cases document. I thought the goal was to have the use cases drive t= he requirements.=20 9) section 3.3 Discovery says that evaluators and consumers should be regis= tered. I haven't seen use cases that claim a need for such a thing. Is this= requirement about a central registration database or something? Who would = be responsible for maintaining such a database? I'm not sure we'll get IETF= consensus for such a central authority for sacm. Or is this thinking in te= rms of existing standards, such as dns or dhcp, or something similar?=20 10) There are requirements for "lightweight representations" and "bulk upda= tes". I wonder if these "requirements" might be better described in use cas= es, rather than in requirements. Part of the problem I see is that large da= tabases might be repositories used by an evaluator or consumer, where the l= arge database would likely be local to the consumer. But the collector of = attributes from an endpoint might utilize one or more lightweight protocol/= data model to collect from endpoints, and the large database might represen= t the aggregation of multiple lightweight queries. Until we begin to look a= t specific data models, scaling might not become a requirement. For example= , SNMP is a lightweight protocol, and MIB modules are typically lightweight= data models, but they are often used to manage very large networks, aggreg= ating data into large local databases. Where bulk updates of large collecti= ons of attributes, such as routing tables, are needed, protocols such as Ne= tconf might be more effective. Where speed is of the essence, a lightweight= notification protocol such a syslog might be effective. But these features= are not required of all implementations/deployments (i.e. use cases). So I= recommend describing the use cases that require these features, rather tha= n simply declaring them requirements, so we can discuss which "requirements= " apply to which use cases, and why. 11) Some of these requirements seem to be "Mom and Apple Pie" types of requ= irements. We might want to simply build a list of requirements that MUST be= met if we expect the IETF/IESG to approve data models or protocols or tran= sports recommended by sacm WG. The thing is, most existing IETF standards a= lready support internationalization (where appropriate), scalability, inter= operability, implementation of strong security, deployment of varied levels= of security (as applicable to the environment), discovery (when appropriat= e), extensible data modeling, and so on. So I'm not sure we need to list th= ese, but it might be helpful to readers coming from outside the IETF. These are normal requirements or recommendations for IETF standardization, = and are typically documented in some RFCs (BCPs) already. I can help to ide= ntify a number of them, such as RFC 3365, 5706, 7013, 6684, 6087, 4290, 418= 1, 3439, 5405, 6365, and so on. (Some of these are guidelines for using spe= cific protocols or designing data models, but could be applicable to new de= signs as well). What we really need to work on understanding are requirements of specific u= se cases, such as endpoints reporting information subject to privacy regula= tions such as medical databases, or querying attributes from endpoints that= have constrained resources like building automation sensors, or querying i= nformation from endpoints with slow or intermittent connectivity, such as a= n arctic research station or a space station. -- Maybe we need to extract the architectural requirements from the use cases = to start, then develop a general proposed architecture to model the many-to= -many relationships and potential domain crossings, and so on discussed in = the use cases. Then we could move onto requirements for the application pro= tocols between architectural entities (e.g., bulk retrieval, asynchronous n= otifications,etc.), the requirements for the underlying transports (e.g., s= ecurity, reliability), and the requirements for data models (e.g., internat= ionalization) David Harrington ietfdbh@comcast.net +1-603-828-1401 From gunnar.engelbach@threatguard.com Tue Oct 22 16:27:41 2013 Return-Path: <gunnar.engelbach@threatguard.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E13E11E828E for <sacm@ietfa.amsl.com>; Tue, 22 Oct 2013 16:27:41 -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 P61eKVztNblq for <sacm@ietfa.amsl.com>; Tue, 22 Oct 2013 16:27:36 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 23FC711E829B for <sacm@ietf.org>; Tue, 22 Oct 2013 16:27:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=LESeVqlWKibmgXw8JKQWusDFamhaf7z9Ldf5DdQf5wisVmJSkNkqQETtHuKrMf9QitLA0SzPPlXlOiLbhfzJ1y6+S5TZUuRRz3RoxEqhFi9deji8mCxjy/IKfYC/bF/D; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 31534 invoked from network); 22 Oct 2013 16:29:36 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Oct 2013 16:29:35 -0700 Message-ID: <526709E6.2090206@ThreatGuard.com> Date: Tue, 22 Oct 2013 19:27:34 -0400 From: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com> Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Watson, Kimberly" <kimberly.watson@hq.dhs.gov>, "sacm@ietf.org" <sacm@ietf.org> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> In-Reply-To: <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 23:27:41 -0000 It sounds like your perspective on this is very close to what most of us have been talking about since the inception of the SACM working group. Some of the early discussions and architecture suggestions might be worth a review. Right now we're trying to not let those initial preconceptions bias us, instead focusing on consensus of the use cases, then letting those drive requirements and the eventual architecture. What Nancy submitted is a necessary placeholder to meet documentation deadlines, but it will change as this requirements process bobs down the waterfall. And with those statements out of the way, I'd like to make special note of two statements you made in particular, paraphrased, because I don't think they are apparent from the existing use cases: 1) Separation of collection, evaluation [, etc.], is key to flexibility and scalability -- and I would add increases the ability to interact with existing software. 2) It's not just standardizing the data flows between components [id est, collector, evaluator, controller, etc.] that is important, but also standardization of the content that drives collection and evaluation. For exactly the reasons you give, among others. I'd also go further and say the content needs to be public -- otherwise it might as well be proprietary. On 10/22/2013 4:17 PM, Watson, Kimberly wrote: > I strongly agree with points 3 and 4 below. > > Once you separate the actions of collection and evaluation - and I think you must to ensure flexibility and scalability in posture assessment processes and capabilities - you must extend the scope to data models for A and possibly even C/repository at a minimum. Most of the use cases expound on the need to evaluate data already collected to assess a newly-defined posture requirement/concern. If you do not extend to A (and maybe C - I can't tell if defining A is enough to allow for querying/use of data in the evaluator repository by other processes) then you can indirectly tie deploying/implementing a new evaluator to collect the information required for a new assessment even if you already have collected that data in a different evaluator. > > If I look at your simplistic architecture picture, all data collected and stored/passed to an evaluator must use standard data models such that all evaluators store this data the same for multiple assessment consumers to request evaluation from multiple evaluators and get consistent answers. In my understanding B is about asking questions/directing evaluation in a standardized way and receiving standardized answers. I need to know that the conversion of information collected using A has been translated/stored in a standardized fashion to ensure that the evaluation performed by different evaluators collecting the same data will produce the same assessment result. > > Being new to this forum and having read only the three new documents, it is quite possible that I am misunderstanding something and expressing a concern that isn't valid...but I was very surprised after reading all the use cases to see the architecture picture expressly state evaluation but not collection, and limit scope to just B. my current operational issues are in standardizing the collection and storage of endpoint posture attributes for reuse by multiple assessment processes that are constantly defining new criteria and policy for evaluation and posture validation. Most of the use cases appear to have this same need at their core. > -- > Kim Watson > Office of Cybersecurity and Communications > Federal Network Resilience > Blackberry: (202) 494-2534 > > > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Monday, October 21, 2013 7:15 PM > To: sacm@ietf.org > Subject: [sacm] review of draft-camwinget-sacm-requirements-01.txt > > Hi, > > I have reviewed this document and have some comments. > > 1) section 2 - update to reference the ietf-sacm-terminology draft. > > 2) section 3.1 uses Asset in the diagram. Since we are focusing on endpoint assessment, should the diagram utilize endpoint rather than asset? Asset evaluation might be a larger scope than the endpoints we are discussing. > > 3)"Evaluator is the service that affects ..."; Dave and I have been trying to make the language less ambiguous by using "collects" and "evaluates". I don't know what "affects" means here. There is also the question of whether the collector and the evaluator are necessarily the same entity. > > 4) section 3.1 states that the focus will be the data models, protocols, and transport for B. I haven't seen WG consensus that this is the limit of our scope. I have recently edited quite a few use cases that cover more scope than B. > > 5) There is an "Abbreviated Title" on every page. Please edit the xml2rfc <title> field (assuming the source is in xml2rfc format). > > 6) In 3.3, there are places with "> characters at the end of the lines. > > 7) We also should run a spellchecker when possible. s/recieve/receive/ See http://tools.ietf.org/tools/idspell/webservice > > 8) section 3.2 states a number of requirements that I have not seen discussed on the WG mailing list, or in the use cases submitted for inclusion in the use-cases document. I thought the goal was to have the use cases drive the requirements. > > 9) section 3.3 Discovery says that evaluators and consumers should be registered. I haven't seen use cases that claim a need for such a thing. Is this requirement about a central registration database or something? Who would be responsible for maintaining such a database? I'm not sure we'll get IETF consensus for such a central authority for sacm. Or is this thinking in terms of existing standards, such as dns or dhcp, or something similar? > > 10) There are requirements for "lightweight representations" and "bulk updates". I wonder if these "requirements" might be better described in use cases, rather than in requirements. Part of the problem I see is that large databases might be repositories used by an evaluator or consumer, where the large database would likely be local to the consumer. But the collector of attributes from an endpoint might utilize one or more lightweight protocol/data model to collect from endpoints, and the large database might represent the aggregation of multiple lightweight queries. Until we begin to look at specific data models, scaling might not become a requirement. For example, SNMP is a lightweight protocol, and MIB modules are typically lightweight data models, but they are often used to manage very large networks, aggregating data into large local databases. Where bulk updates of large collections of attributes, such as routing tables, are needed, protocols such as Netconf might b e > more effective. Where speed is of the essence, a lightweight notification protocol such a syslog might be effective. But these features are not required of all implementations/deployments (i.e. use cases). So I recommend describing the use cases that require these features, rather than simply declaring them requirements, so we can discuss which "requirements" apply to which use cases, and why. > > 11) Some of these requirements seem to be "Mom and Apple Pie" types of requirements. We might want to simply build a list of requirements that MUST be met if we expect the IETF/IESG to approve data models or protocols or transports recommended by sacm WG. The thing is, most existing IETF standards already support internationalization (where appropriate), scalability, interoperability, implementation of strong security, deployment of varied levels of security (as applicable to the environment), discovery (when appropriate), extensible data modeling, and so on. So I'm not sure we need to list these, but it might be helpful to readers coming from outside the IETF. > > These are normal requirements or recommendations for IETF standardization, and are typically documented in some RFCs (BCPs) already. I can help to identify a number of them, such as RFC 3365, 5706, 7013, 6684, 6087, 4290, 4181, 3439, 5405, 6365, and so on. (Some of these are guidelines for using specific protocols or designing data models, but could be applicable to new designs as well). > > What we really need to work on understanding are requirements of specific use cases, such as endpoints reporting information subject to privacy regulations such as medical databases, or querying attributes from endpoints that have constrained resources like building automation sensors, or querying information from endpoints with slow or intermittent connectivity, such as an arctic research station or a space station. > > -- > Maybe we need to extract the architectural requirements from the use cases to start, then develop a general proposed architecture to model the many-to-many relationships and potential domain crossings, and so on discussed in the use cases. Then we could move onto requirements for the application protocols between architectural entities (e.g., bulk retrieval, asynchronous notifications,etc.), the requirements for the underlying transports (e.g., security, reliability), and the requirements for data models (e.g., internationalization) > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From kimberly.watson@hq.dhs.gov Wed Oct 23 12:48:43 2013 Return-Path: <kimberly.watson@hq.dhs.gov> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28211E8233 for <sacm@ietfa.amsl.com>; Wed, 23 Oct 2013 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 401ijVJIIDgD for <sacm@ietfa.amsl.com>; Wed, 23 Oct 2013 12:48:38 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 26FB711E81CA for <sacm@ietf.org>; Wed, 23 Oct 2013 12:48:35 -0700 (PDT) Received: from mail101-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Oct 2013 19:48:35 +0000 Received: from mail101-va3 (localhost [127.0.0.1]) by mail101-va3-R.bigfish.com (Postfix) with ESMTP id 3EBEB3A0272; Wed, 23 Oct 2013 19:48:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:216.81.82.140; KIP:(null); UIP:(null); IPV:NLI; H:D2IBLPRHQ103.dhs.gov; RD:none; EFVD:NLI X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI98dI9371I542I1432I168aJ1521Idbf2izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068h1d68deh1b08bcihz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail101-va3 (localhost.localdomain [127.0.0.1]) by mail101-va3 (MessageSwitch) id 1382557668544430_17973; Wed, 23 Oct 2013 19:47:48 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.233]) by mail101-va3.bigfish.com (Postfix) with ESMTP id 7FAF44A0040; Wed, 23 Oct 2013 19:47:48 +0000 (UTC) Received: from D2IBLPRHQ103.dhs.gov (216.81.82.140) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Oct 2013 19:47:48 +0000 Received: from D2IBLPRHQ107.dhs.gov (192.168.49.137) by D2IBLPRHQ103.dhs.gov (10.82.0.54) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 15:47:37 -0400 Received: from D2ABLPRHQ100.DSA.DHS (10.237.115.11) by D2IBLPRHQ107.dhs.gov (10.82.4.54) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 23 Oct 2013 15:58:44 -0400 Received: from D2ASEPREA006.DSA.DHS ([169.254.10.234]) by D2ABLPRHQ100.DSA.DHS ([fe80::490d:eca6:8d71:b5e0%10]) with mapi id 14.02.0342.003; Wed, 23 Oct 2013 15:47:30 -0400 From: "Watson, Kimberly" <kimberly.watson@hq.dhs.gov> To: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: AQHOz1mehA5UZiAmaUGOnObhVxkJipoBIPMQgAB/+gCAAQtTQA== Date: Wed, 23 Oct 2013 19:47:29 +0000 Message-ID: <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> In-Reply-To: <526709E6.2090206@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.235.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hq.dhs.gov X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Oct 2013 19:48:43 -0000 I think going from use case to requirements to architecture makes sense, an= d in many ways why I didn't read the current architecture draft.=20 As for your comments that my statements are not apparent from the use cases= , I went back to see why I felt they were ...and I noticed that my assumpti= ons/assertions are derived from the discussion and workflow of end point po= sture assessments and not the use cases. Separation of Collection and Evaluation is explicit in the statement about = what an endpoint posture assessment typically includes and in the fact that= the workflow (WF) has 5, 6, & 7 as steps. While the use cases do not ident= ify 3 versions of the same use case where you have them separate (WF 5), co= mbined (WF 6), or accessible by multiple evaluators or other processes (WF = 7), the breakout implied to me that it is a requirement that the two are no= t bound together. When you break that binding, then the expression of: what to collect, how t= o refer to/store posture attributes, what to evaluate against, how to evalu= ate, and how to provide results MUST be standardized and public. I felt tha= t B can handle the last three, but ignored the first two. I'm not sure what= you mean by content (it is a very loaded term in security automation discu= ssions), but I completely agree that it is more than the data flow that nee= ds to be standardized. This appears to be a higher level requirement tied t= o the separation of collection and evaluation, and to serve the purpose as = defined early in the document: Typically, endpoint posture information is g= athered and then published to appropriate data repositories to make collected information av= ailable for further analysis supporting organizational security processes. So neither of these are articulated in the use cases, but are necessary to = support the larger goal of scalable, flexible, and evolvable endpoint postu= re assessment as defined earlier in the document. Do they need to be expressly in the use cases? Or do we just need to agree = that they are necessary characteristics or attributes of solutions to the p= roblem? Can we derive requirements from the description of what endpoint po= sture assessment is or the workflow? Or can they only come from the use cas= es? -- Kim Watson Office of Cybersecurity and Communications Federal Network Resilience Blackberry: (202) 494-2534 -----Original Message----- From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com]=20 Sent: Tuesday, October 22, 2013 7:28 PM To: Watson, Kimberly; sacm@ietf.org Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt It sounds like your perspective on this is very close to what most of us ha= ve been talking about since the inception of the SACM working group.=20 Some of the early discussions and architecture suggestions might be worth a= review. Right now we're trying to not let those initial preconceptions bias us, ins= tead focusing on consensus of the use cases, then letting those drive requi= rements and the eventual architecture. What Nancy submitted is a necessary placeholder to meet documentation deadl= ines, but it will change as this requirements process bobs down the waterfa= ll. And with those statements out of the way, I'd like to make special note of = two statements you made in particular, paraphrased, because I don't think t= hey are apparent from the existing use cases: 1) Separation of collection, evaluation [, etc.], is key to flexibility and= scalability -- and I would add increases the ability to interact with exis= ting software. 2) It's not just standardizing the data flows between components [id est, c= ollector, evaluator, controller, etc.] that is important, but also standard= ization of the content that drives collection and evaluation.=20 For exactly the reasons you give, among others. I'd also go further and sa= y the content needs to be public -- otherwise it might as well be proprieta= ry. On 10/22/2013 4:17 PM, Watson, Kimberly wrote: > I strongly agree with points 3 and 4 below. > > Once you separate the actions of collection and evaluation - and I think = you must to ensure flexibility and scalability in posture assessment proces= ses and capabilities - you must extend the scope to data models for A and p= ossibly even C/repository at a minimum. Most of the use cases expound on th= e need to evaluate data already collected to assess a newly-defined posture= requirement/concern. If you do not extend to A (and maybe C - I can't tell= if defining A is enough to allow for querying/use of data in the evaluator= repository by other processes) then you can indirectly tie deploying/imple= menting a new evaluator to collect the information required for a new asse= ssment even if you already have collected that data in a different evaluato= r. > > If I look at your simplistic architecture picture, all data collected and= stored/passed to an evaluator must use standard data models such that all = evaluators store this data the same for multiple assessment consumers to re= quest evaluation from multiple evaluators and get consistent answers. In my= understanding B is about asking questions/directing evaluation in a standa= rdized way and receiving standardized answers. I need to know that the conv= ersion of information collected using A has been translated/stored in a sta= ndardized fashion to ensure that the evaluation performed by different eval= uators collecting the same data will produce the same assessment result. > > Being new to this forum and having read only the three new documents, it = is quite possible that I am misunderstanding something and expressing a con= cern that isn't valid...but I was very surprised after reading all the use = cases to see the architecture picture expressly state evaluation but not co= llection, and limit scope to just B. my current operational issues are in s= tandardizing the collection and storage of endpoint posture attributes for = reuse by multiple assessment processes that are constantly defining new cri= teria and policy for evaluation and posture validation. Most of the use cas= es appear to have this same need at their core. > -- > Kim Watson > Office of Cybersecurity and Communications Federal Network Resilience > Blackberry: (202) 494-2534 > > > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Monday, October 21, 2013 7:15 PM > To: sacm@ietf.org > Subject: [sacm] review of draft-camwinget-sacm-requirements-01.txt > > Hi, > > I have reviewed this document and have some comments. > > 1) section 2 - update to reference the ietf-sacm-terminology draft. > > 2) section 3.1 uses Asset in the diagram. Since we are focusing on endpoi= nt assessment, should the diagram utilize endpoint rather than asset? Asset= evaluation might be a larger scope than the endpoints we are discussing. > > 3)"Evaluator is the service that affects ..."; Dave and I have been tryin= g to make the language less ambiguous by using "collects" and "evaluates". = I don't know what "affects" means here. There is also the question of wheth= er the collector and the evaluator are necessarily the same entity. > > 4) section 3.1 states that the focus will be the data models, protocols, = and transport for B. I haven't seen WG consensus that this is the limit of = our scope. I have recently edited quite a few use cases that cover more sco= pe than B. > > 5) There is an "Abbreviated Title" on every page. Please edit the xml2rfc= <title> field (assuming the source is in xml2rfc format). > > 6) In 3.3, there are places with "> characters at the end of the lines. > > 7) We also should run a spellchecker when possible. s/recieve/receive/ S= ee http://tools.ietf.org/tools/idspell/webservice > > 8) section 3.2 states a number of requirements that I have not seen discu= ssed on the WG mailing list, or in the use cases submitted for inclusion in= the use-cases document. I thought the goal was to have the use cases drive= the requirements. > > 9) section 3.3 Discovery says that evaluators and consumers should be reg= istered. I haven't seen use cases that claim a need for such a thing. Is th= is requirement about a central registration database or something? Who woul= d be responsible for maintaining such a database? I'm not sure we'll get IE= TF consensus for such a central authority for sacm. Or is this thinking in = terms of existing standards, such as dns or dhcp, or something similar? > > 10) There are requirements for "lightweight representations" and "bulk up= dates". I wonder if these "requirements" might be better described in use c= ases, rather than in requirements. Part of the problem I see is that large = databases might be repositories used by an evaluator or consumer, where the= large database would likely be local to the consumer. But the collector o= f attributes from an endpoint might utilize one or more lightweight protoco= l/data model to collect from endpoints, and the large database might repres= ent the aggregation of multiple lightweight queries. Until we begin to look= at specific data models, scaling might not become a requirement. For examp= le, SNMP is a lightweight protocol, and MIB modules are typically lightweig= ht data models, but they are often used to manage very large networks, aggr= egating data into large local databases. Where bulk updates of large collec= tions of attributes, such as routing tables, are needed, protocols such as = Netconf might be > more effective. Where speed is of the essence, a lightweight notificati= on protocol such a syslog might be effective. But these features are not re= quired of all implementations/deployments (i.e. use cases). So I recommend = describing the use cases that require these features, rather than simply de= claring them requirements, so we can discuss which "requirements" apply to = which use cases, and why. > > 11) Some of these requirements seem to be "Mom and Apple Pie" types of re= quirements. We might want to simply build a list of requirements that MUST = be met if we expect the IETF/IESG to approve data models or protocols or tr= ansports recommended by sacm WG. The thing is, most existing IETF standards= already support internationalization (where appropriate), scalability, int= eroperability, implementation of strong security, deployment of varied leve= ls of security (as applicable to the environment), discovery (when appropri= ate), extensible data modeling, and so on. So I'm not sure we need to list = these, but it might be helpful to readers coming from outside the IETF. > > These are normal requirements or recommendations for IETF standardization= , and are typically documented in some RFCs (BCPs) already. I can help to i= dentify a number of them, such as RFC 3365, 5706, 7013, 6684, 6087, 4290, 4= 181, 3439, 5405, 6365, and so on. (Some of these are guidelines for using s= pecific protocols or designing data models, but could be applicable to new = designs as well). > > What we really need to work on understanding are requirements of specific= use cases, such as endpoints reporting information subject to privacy regu= lations such as medical databases, or querying attributes from endpoints th= at have constrained resources like building automation sensors, or querying= information from endpoints with slow or intermittent connectivity, such as= an arctic research station or a space station. > > -- > Maybe we need to extract the architectural requirements from the use case= s to start, then develop a general proposed architecture to model the many-= to-many relationships and potential domain crossings, and so on discussed i= n the use cases. Then we could move onto requirements for the application p= rotocols between architectural entities (e.g., bulk retrieval, asynchronous= notifications,etc.), the requirements for the underlying transports (e.g.,= security, reliability), and the requirements for data models (e.g., intern= ationalization) > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From gunnar.engelbach@threatguard.com Wed Oct 23 14:30:31 2013 Return-Path: <gunnar.engelbach@threatguard.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3D111E824A for <sacm@ietfa.amsl.com>; Wed, 23 Oct 2013 14:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWPbtb7hLapS for <sacm@ietfa.amsl.com>; Wed, 23 Oct 2013 14:30:16 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 82DDE11E81C8 for <sacm@ietf.org>; Wed, 23 Oct 2013 14:30:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=mV2Sr3cLNqF0+1JMlzY+0qZ+X6H2kLhFXlroKAVN6e76Fk30bmn4Xt3w+meQFs2MFiIQPbG5zWb1t34L4L9qLeb4LnamaJ/5e4j3qg/7C75bzeMZrKCF4wrg+LcovCOg; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 10228 invoked from network); 23 Oct 2013 14:32:22 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Oct 2013 14:32:21 -0700 Message-ID: <52683FEB.2010703@ThreatGuard.com> Date: Wed, 23 Oct 2013 17:30:19 -0400 From: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com> Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Watson, Kimberly" <kimberly.watson@hq.dhs.gov>, "sacm@ietf.org" <sacm@ietf.org> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> In-Reply-To: <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Oct 2013 21:30:31 -0000 Comments inline... On 10/23/2013 3:47 PM, Watson, Kimberly wrote: > I think going from use case to requirements to architecture makes sense, and in many ways why I didn't read the current architecture draft. > > As for your comments that my statements are not apparent from the use cases, I went back to see why I felt they were ...and I noticed that my assumptions/assertions are derived from the discussion and workflow of end point posture assessments and not the use cases. > > Separation of Collection and Evaluation is explicit in the statement about what an endpoint posture assessment typically includes and in the fact that the workflow (WF) has 5, 6, & 7 as steps. While the use cases do not identify 3 versions of the same use case where you have them separate (WF 5), combined (WF 6), or accessible by multiple evaluators or other processes (WF 7), the breakout implied to me that it is a requirement that the two are not bound together. > > When you break that binding, then the expression of: what to collect, how to refer to/store posture attributes, what to evaluate against, how to evaluate, and how to provide results MUST be standardized and public. I felt that B can handle the last three, but ignored the first two. I'm not sure what you mean by content (it is a very loaded term in security automation discussions), but I completely agree that it is more than the data flow that needs to be standardized. This appears to be a higher level requirement tied to the separation of collection and evaluation, and to serve the purpose as defined early in the document: Typically, endpoint posture information is gathered and then > published to appropriate data repositories to make collected information available for further analysis supporting organizational security processes. For now, how about we say that content is the document or documents that provide the instructions for an automated assessment to occur -- generally organized to implement a discrete action such as compliance policy adherence or a vulnerability assessment. But this makes me wonder if it is necessary to know the disposition of the content in order to define the data flows and components in SACM. Are they interdependent, or will the SACM data flows be effective while treating the content as generic payload? Further, I indicated earlier my impression that most of the active participants have a similar view of what SACM looks like. I would like to hear more from others who do not because I think that's where were more likely to find considerations that have thus far escaped notice. > > So neither of these are articulated in the use cases, but are necessary to support the larger goal of scalable, flexible, and evolvable endpoint posture assessment as defined earlier in the document. > > Do they need to be expressly in the use cases? Or do we just need to agree that they are necessary characteristics or attributes of solutions to the problem? Can we derive requirements from the description of what endpoint posture assessment is or the workflow? Or can they only come from the use cases? That works for me, but that's easy for me to say because I already agree with them as requirements. Having a use case exemplifying the need would be useful. Would you care to submit one? > -- > Kim Watson > Office of Cybersecurity and Communications > Federal Network Resilience > Blackberry: (202) 494-2534 > > > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Tuesday, October 22, 2013 7:28 PM > To: Watson, Kimberly; sacm@ietf.org > Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt > > > It sounds like your perspective on this is very close to what most of us have been talking about since the inception of the SACM working group. > Some of the early discussions and architecture suggestions might be worth a review. > > Right now we're trying to not let those initial preconceptions bias us, instead focusing on consensus of the use cases, then letting those drive requirements and the eventual architecture. > > What Nancy submitted is a necessary placeholder to meet documentation deadlines, but it will change as this requirements process bobs down the waterfall. > > And with those statements out of the way, I'd like to make special note of two statements you made in particular, paraphrased, because I don't think they are apparent from the existing use cases: > > 1) Separation of collection, evaluation [, etc.], is key to flexibility and scalability -- and I would add increases the ability to interact with existing software. > > 2) It's not just standardizing the data flows between components [id est, collector, evaluator, controller, etc.] that is important, but also standardization of the content that drives collection and evaluation. > For exactly the reasons you give, among others. I'd also go further and say the content needs to be public -- otherwise it might as well be proprietary. > > > > > > > On 10/22/2013 4:17 PM, Watson, Kimberly wrote: >> I strongly agree with points 3 and 4 below. >> >> Once you separate the actions of collection and evaluation - and I think you must to ensure flexibility and scalability in posture assessment processes and capabilities - you must extend the scope to data models for A and possibly even C/repository at a minimum. Most of the use cases expound on the need to evaluate data already collected to assess a newly-defined posture requirement/concern. If you do not extend to A (and maybe C - I can't tell if defining A is enough to allow for querying/use of data in the evaluator repository by other processes) then you can indirectly tie deploying/implementing a new evaluator to collect the information required for a new assessment even if you already have collected that data in a different evaluator. >> >> If I look at your simplistic architecture picture, all data collected and stored/passed to an evaluator must use standard data models such that all evaluators store this data the same for multiple assessment consumers to request evaluation from multiple evaluators and get consistent answers. In my understanding B is about asking questions/directing evaluation in a standardized way and receiving standardized answers. I need to know that the conversion of information collected using A has been translated/stored in a standardized fashion to ensure that the evaluation performed by different evaluators collecting the same data will produce the same assessment result. >> >> Being new to this forum and having read only the three new documents, it is quite possible that I am misunderstanding something and expressing a concern that isn't valid...but I was very surprised after reading all the use cases to see the architecture picture expressly state evaluation but not collection, and limit scope to just B. my current operational issues are in standardizing the collection and storage of endpoint posture attributes for reuse by multiple assessment processes that are constantly defining new criteria and policy for evaluation and posture validation. Most of the use cases appear to have this same need at their core. >> -- >> Kim Watson >> Office of Cybersecurity and Communications Federal Network Resilience >> Blackberry: (202) 494-2534 >> >> >> -----Original Message----- >> From: ietfdbh [mailto:ietfdbh@comcast.net] >> Sent: Monday, October 21, 2013 7:15 PM >> To: sacm@ietf.org >> Subject: [sacm] review of draft-camwinget-sacm-requirements-01.txt >> >> Hi, >> >> I have reviewed this document and have some comments. >> >> 1) section 2 - update to reference the ietf-sacm-terminology draft. >> >> 2) section 3.1 uses Asset in the diagram. Since we are focusing on endpoint assessment, should the diagram utilize endpoint rather than asset? Asset evaluation might be a larger scope than the endpoints we are discussing. >> >> 3)"Evaluator is the service that affects ..."; Dave and I have been trying to make the language less ambiguous by using "collects" and "evaluates". I don't know what "affects" means here. There is also the question of whether the collector and the evaluator are necessarily the same entity. >> >> 4) section 3.1 states that the focus will be the data models, protocols, and transport for B. I haven't seen WG consensus that this is the limit of our scope. I have recently edited quite a few use cases that cover more scope than B. >> >> 5) There is an "Abbreviated Title" on every page. Please edit the xml2rfc <title> field (assuming the source is in xml2rfc format). >> >> 6) In 3.3, there are places with "> characters at the end of the lines. >> >> 7) We also should run a spellchecker when possible. s/recieve/receive/ See http://tools.ietf.org/tools/idspell/webservice >> >> 8) section 3.2 states a number of requirements that I have not seen discussed on the WG mailing list, or in the use cases submitted for inclusion in the use-cases document. I thought the goal was to have the use cases drive the requirements. >> >> 9) section 3.3 Discovery says that evaluators and consumers should be registered. I haven't seen use cases that claim a need for such a thing. Is this requirement about a central registration database or something? Who would be responsible for maintaining such a database? I'm not sure we'll get IETF consensus for such a central authority for sacm. Or is this thinking in terms of existing standards, such as dns or dhcp, or something similar? >> >> 10) There are requirements for "lightweight representations" and "bulk updates". I wonder if these "requirements" might be better described in use cases, rather than in requirements. Part of the problem I see is that large databases might be repositories used by an evaluator or consumer, where the large database would likely be local to the consumer. But the collector of attributes from an endpoint might utilize one or more lightweight protocol/data model to collect from endpoints, and the large database might represent the aggregation of multiple lightweight queries. Until we begin to look at specific data models, scaling might not become a requirement. For example, SNMP is a lightweight protocol, and MIB modules are typically lightweight data models, but they are often used to manage very large networks, aggregating data into large local databases. Where bulk updates of large collections of attributes, such as routing tables, are needed, protocols such as Netconf might be >> more effective. Where speed is of the essence, a lightweight notification protocol such a syslog might be effective. But these features are not required of all implementations/deployments (i.e. use cases). So I recommend describing the use cases that require these features, rather than simply declaring them requirements, so we can discuss which "requirements" apply to which use cases, and why. >> >> 11) Some of these requirements seem to be "Mom and Apple Pie" types of requirements. We might want to simply build a list of requirements that MUST be met if we expect the IETF/IESG to approve data models or protocols or transports recommended by sacm WG. The thing is, most existing IETF standards already support internationalization (where appropriate), scalability, interoperability, implementation of strong security, deployment of varied levels of security (as applicable to the environment), discovery (when appropriate), extensible data modeling, and so on. So I'm not sure we need to list these, but it might be helpful to readers coming from outside the IETF. >> >> These are normal requirements or recommendations for IETF standardization, and are typically documented in some RFCs (BCPs) already. I can help to identify a number of them, such as RFC 3365, 5706, 7013, 6684, 6087, 4290, 4181, 3439, 5405, 6365, and so on. (Some of these are guidelines for using specific protocols or designing data models, but could be applicable to new designs as well). >> >> What we really need to work on understanding are requirements of specific use cases, such as endpoints reporting information subject to privacy regulations such as medical databases, or querying attributes from endpoints that have constrained resources like building automation sensors, or querying information from endpoints with slow or intermittent connectivity, such as an arctic research station or a space station. >> >> -- >> Maybe we need to extract the architectural requirements from the use cases to start, then develop a general proposed architecture to model the many-to-many relationships and potential domain crossings, and so on discussed in the use cases. Then we could move onto requirements for the application protocols between architectural entities (e.g., bulk retrieval, asynchronous notifications,etc.), the requirements for the underlying transports (e.g., security, reliability), and the requirements for data models (e.g., internationalization) >> >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> > > From kimberly.watson@hq.dhs.gov Thu Oct 24 06:25:09 2013 Return-Path: <kimberly.watson@hq.dhs.gov> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DEC11E8153 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 06:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpCM9qPplyX7 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 06:25:00 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 34F7B11E8189 for <sacm@ietf.org>; Thu, 24 Oct 2013 06:25:00 -0700 (PDT) Received: from mail192-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Thu, 24 Oct 2013 13:24:59 +0000 Received: from mail192-ch1 (localhost [127.0.0.1]) by mail192-ch1-R.bigfish.com (Postfix) with ESMTP id 62EA21800D9; Thu, 24 Oct 2013 13:24:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:216.81.82.137; KIP:(null); UIP:(null); IPV:NLI; H:d2iblprhq100.dhs.gov; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371I542I1432I168aJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail192-ch1 (localhost.localdomain [127.0.0.1]) by mail192-ch1 (MessageSwitch) id 1382621098124190_29235; Thu, 24 Oct 2013 13:24:58 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail192-ch1.bigfish.com (Postfix) with ESMTP id 1AD744E007A; Thu, 24 Oct 2013 13:24:58 +0000 (UTC) Received: from d2iblprhq100.dhs.gov (216.81.82.137) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 24 Oct 2013 13:24:57 +0000 Received: from D2IBLPRHQ107.dhs.gov (192.168.49.137) by D2IBLPRHQ100.dhs.gov (10.82.0.51) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 09:24:29 -0400 Received: from D2ABLPRHQ101.DSA.DHS (10.237.115.12) by D2IBLPRHQ107.dhs.gov (10.82.4.54) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 24 Oct 2013 09:36:09 -0400 Received: from D2ASEPREA006.DSA.DHS ([169.254.10.234]) by D2ABLPRHQ101.DSA.DHS ([fe80::a955:d320:5946:ba7c%18]) with mapi id 14.02.0342.003; Thu, 24 Oct 2013 09:24:56 -0400 From: "Watson, Kimberly" <kimberly.watson@hq.dhs.gov> To: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: AQHOz1mehA5UZiAmaUGOnObhVxkJipoBIPMQgAB/+gCAAQtTQIAAZj+AgADAUQA= Date: Thu, 24 Oct 2013 13:24:55 +0000 Message-ID: <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> In-Reply-To: <52683FEB.2010703@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.235.238] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hq.dhs.gov X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 13:25:09 -0000 I can try to develop a use case...but what I realized last night is that a = use case that would highlight these requirements will be expressing a "How"= not a "What" which is normally a bad thing because it can bias the require= ments/architecture derived from those use cases to a particular solution.=20 I personally think it is best to keep the "How" part out of the use cases, = but define characteristics that any/all solutions must have to ensure scala= bility, flexibility, and support incremental improvement without redesign (= what I tend to call evolution). If we specify that any solution to a use case must be able to:=20 1. perform the assessment from collection to evaluation in one request 2. perform the collection at a previous point in time and then have the ass= ociated evaluator assess upon request 3. perform the collection at a previous point in time and then have ANY eva= luator assess upon request This creates 2 high level requirements (probably more, but we are talking a= bout these two): 1. Collection and Evaluation are decoupled 2. there must be standardization and transparency in the expression of coll= ection as well as in the expression of evaluation At this point it is probably best to find out if anyone disagrees with the = assertion that separating collection from evaluation is a necessary charact= eristic of solutions that address the use cases. -- Kim Watson Office of Cybersecurity and Communications Federal Network Resilience Blackberry: (202) 494-2534 -----Original Message----- From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com]=20 Sent: Wednesday, October 23, 2013 5:30 PM To: Watson, Kimberly; sacm@ietf.org Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt Comments inline... On 10/23/2013 3:47 PM, Watson, Kimberly wrote: > So neither of these are articulated in the use cases, but are necessary t= o support the larger goal of scalable, flexible, and evolvable endpoint pos= ture assessment as defined earlier in the document. > > Do they need to be expressly in the use cases? Or do we just need to agre= e that they are necessary characteristics or attributes of solutions to the= problem? Can we derive requirements from the description of what endpoint = posture assessment is or the workflow? Or can they only come from the use c= ases? That works for me, but that's easy for me to say because I already agree wi= th them as requirements. Having a use case exemplifying the need would be useful. Would you care to= submit one? > -- > Kim Watson > Office of Cybersecurity and Communications > Federal Network Resilience > Blackberry: (202) 494-2534 > From Adam.Montville@cisecurity.org Thu Oct 24 07:09:15 2013 Return-Path: <Adam.Montville@cisecurity.org> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899E11E8279 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 07:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9YJgNTQfL1l for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 07:09:10 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.6]) by ietfa.amsl.com (Postfix) with ESMTP id DDE4E11E8351 for <sacm@ietf.org>; Thu, 24 Oct 2013 07:08:26 -0700 (PDT) Received: from [216.82.250.179:13000] by server-6.bemta-12.messagelabs.com id DE/14-06818-AD929625; Thu, 24 Oct 2013 14:08:26 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-12.tower-210.messagelabs.com!1382623705!10418185!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 19516 invoked from network); 24 Oct 2013 14:08:26 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-12.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 24 Oct 2013 14:08:26 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c]) by CISEXCHANGE1.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 24 Oct 2013 10:07:54 -0400 From: Adam Montville <Adam.Montville@cisecurity.org> To: "Watson, Kimberly" <kimberly.watson@hq.dhs.gov>, Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: Ac7OpSVwj/HG00ZWT7aKJLUVL/1RGQA4C2KAAAafTgAAKprogAADl2aAACFWyoAAByQ7kA== Date: Thu, 24 Oct 2013 14:07:52 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> In-Reply-To: <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 14:09:15 -0000 This has been a very good discussion to track. I agree with the notion th= at use cases shouldn't really consider the "how" (and, IMO, the use case d= ocument could stand to be cleaned up a bit in this way, though it may not = be necessary at this point). Perhaps a use case that would (seem to) clea= rly require would be one that considers assessment of embedded devices whi= ch may have the ability to report configuration but not necessarily perfor= m evaluation on-board. I'm thinking in terms of the "Internet of things."= The Ice Station Zebra use case might be another, where an evaluation com= ponent may not be permissible in the environment (separation of duties, le= ast priv, that sort of thing), but the collection still has to happen. Ju= st throwing out ideas. Either way, the Requirements document is one where we're going to see most= of this stuff shake out, and I think it will serve to help us refine the = use cases. At present, I'm working on a detailed review of the Use Case document and = trying to derive some potential requirements from it. Once I'm done with = that, I'll float it to the list here as something to complement the existi= ng Requirements draft and kindle some discussion. Adam > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Watson, Kimberly > Sent: Thursday, October 24, 2013 8:25 AM > To: Gunnar Engelbach; sacm@ietf.org > Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt >=20 > I can try to develop a use case...but what I realized last night is that= a use case > that would highlight these requirements will be expressing a "How" not a= > "What" which is normally a bad thing because it can bias the > requirements/architecture derived from those use cases to a particular > solution. >=20 > I personally think it is best to keep the "How" part out of the use case= s, but > define characteristics that any/all solutions must have to ensure scalab= ility, > flexibility, and support incremental improvement without redesign (what = I > tend to call evolution). >=20 > If we specify that any solution to a use case must be able to: > 1. perform the assessment from collection to evaluation in one request 2= . > perform the collection at a previous point in time and then have the > associated evaluator assess upon request 3. perform the collection at a > previous point in time and then have ANY evaluator assess upon request >=20 > This creates 2 high level requirements (probably more, but we are talkin= g > about these two): >=20 > 1. Collection and Evaluation are decoupled 2. there must be standardizat= ion > and transparency in the expression of collection as well as in the expre= ssion > of evaluation >=20 > At this point it is probably best to find out if anyone disagrees with t= he > assertion that separating collection from evaluation is a necessary > characteristic of solutions that address the use cases. >=20 > -- > Kim Watson > Office of Cybersecurity and Communications Federal Network Resilience > Blackberry: (202) 494-2534 >=20 >=20 > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Wednesday, October 23, 2013 5:30 PM > To: Watson, Kimberly; sacm@ietf.org > Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt >=20 >=20 > Comments inline... >=20 >=20 > On 10/23/2013 3:47 PM, Watson, Kimberly wrote: > > So neither of these are articulated in the use cases, but are necessar= y to > support the larger goal of scalable, flexible, and evolvable endpoint po= sture > assessment as defined earlier in the document. > > > > Do they need to be expressly in the use cases? Or do we just need to a= gree > that they are necessary characteristics or attributes of solutions to th= e > problem? Can we derive requirements from the description of what > endpoint posture assessment is or the workflow? Or can they only come > from the use cases? >=20 > That works for me, but that's easy for me to say because I already agree= with > them as requirements. >=20 > Having a use case exemplifying the need would be useful. Would you care= to > submit one? >=20 >=20 >=20 >=20 > > -- > > Kim Watson > > Office of Cybersecurity and Communications > > Federal Network Resilience > > Blackberry: (202) 494-2534 > > >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... . . . From Adam.Montville@cisecurity.org Thu Oct 24 08:01:40 2013 Return-Path: <Adam.Montville@cisecurity.org> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6393A11E8217 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3pQc2XBgyVf for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 08:01:34 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) by ietfa.amsl.com (Postfix) with ESMTP id 290F311E8315 for <sacm@ietf.org>; Thu, 24 Oct 2013 08:00:03 -0700 (PDT) Received: from [216.82.241.211:61537] by server-9.bemta-8.messagelabs.com id C2/3E-07613-2F539625; Thu, 24 Oct 2013 15:00:02 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-15.tower-85.messagelabs.com!1382626801!42717312!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 32457 invoked from network); 24 Oct 2013 15:00:02 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-15.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 24 Oct 2013 15:00:02 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c]) by CISEXCHANGE1.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 24 Oct 2013 10:59:31 -0400 From: Adam Montville <Adam.Montville@cisecurity.org> To: "Watson, Kimberly" <kimberly.watson@hq.dhs.gov>, Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: Ac7OpSVwj/HG00ZWT7aKJLUVL/1RGQA4C2KAAAafTgAAKprogAADl2aAACFWyoAAByQ7kAAMpgHQ Date: Thu, 24 Oct 2013 14:59:29 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 15:01:40 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, October 24, 2013 9:09 AM > To: Watson, Kimberly; Gunnar Engelbach; sacm@ietf.org > Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt >=20 > This has been a very good discussion to track. I agree with the notion = that > use cases shouldn't really consider the "how" (and, IMO, the use case > document could stand to be cleaned up a bit in this way, though it may n= ot > be necessary at this point).=20 For the sake of providing an example with respect to my comment about how = the use case document could be cleaned up a bit, I happened to be reviewin= g 2.12 (Traditional Endpoint Assessment with Stored Results) just now. It= reads: "An external trigger initiates an assessment of an endpoint. The Controller uses the data in the Datastore to look up authentication information for the endpoint and passes that along with the assessment request details=20to the Evaluator. The Evaluator uses the Endpoint information to request taxonomy information from the Collector on the endpoint, which responds with those attributes. The Evaluator uses that taxonomy information along with the information in the original request from the Controller to request the appropriate content from the Content Repository. The Evaluator uses the content to derive the minimal set of endpoint attributes needed to perform the assessment and makes that request. The Evaluator uses the Collector response to do the assessment and returns the results to the Controller. The Controller puts the results in the Datastore." IMO, there should probably be no discussion in this use case of a Datastor= e, Controller, Content Repository. By my read, this use case intends to s= ay: "The system, triggered externally, targets an endpoint for characteriz= ation (inventory?), so that the system can determine the minimal set of en= dpoint attributes to collect and store for subsequent use." >From here, we can derive requirements such as: - The system must support assessment triggers from external sources - The system should support authentication for external assessment trigger= s - The system should support authorization for external assessment triggers= - The system must support target endpoint inventory (I think this is what = was intended by requesting "taxonomy") - The system must support checklist composition based on target endpoint i= nventory - The system must support composite checklist optimization (i.e. remove du= plicate collection expressions) - The system must make assessment results available for subsequent use Architectures would then get into the "how" of it all, which is where I wo= uld see Collectors, Datastores, Evaluators, etc. come into play. There's = more than one way to satisfy the requirements which are derived from this = particular use case.=20 The Use Case, as written, gets the point across, but I think it does so su= perfluously. Maybe it's just a matter of personal taste or preference, bu= t I think a sentence or two would capture the intent of this use case with= out implying or assuming any particular architectural solution. This may = or may not be the case with each other use case, though from what I've bee= n through so far, I think most could stand to be pruned. Adam . . . From gunnar.engelbach@threatguard.com Thu Oct 24 09:11:49 2013 Return-Path: <gunnar.engelbach@threatguard.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC8121E80A5 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 C9K1ry7KK+bC for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 09:11:34 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id A342511E8354 for <sacm@ietf.org>; Thu, 24 Oct 2013 09:05:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=YpdJrWN9AXejex5pGmK/O78u2eucHZnTHzRe+B/ZKEQQ1JyQf3gQp/zOCkPhd4fuPII9hpp0GakT2DYzY/31rEHQTPz0hu8g20b5EvKq/tvtyATj+zUL1/YQeVrThncE; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 21909 invoked from network); 24 Oct 2013 09:07:13 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Oct 2013 09:07:12 -0700 Message-ID: <52694534.8040007@ThreatGuard.com> Date: Thu, 24 Oct 2013 12:05:08 -0400 From: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com> Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adam Montville <Adam.Montville@cisecurity.org>, "Watson, Kimberly" <kimberly.watson@hq.dhs.gov>, "sacm@ietf.org" <sacm@ietf.org> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 16:11:50 -0000 We've been getting a bit pedantic lately in having use cases drive requirements -- a step backward into the old waterfall development model, but a reasonable regression given the unique way development progresses in this working group. But, bottom line, even without a use case we can come up with reasonable examples showing the need for these requirements. It's just a matter of consensus on whether these examples/requirements fall within the scope of this working group. Still, I'd like to see the progression documented in some manner and not have new things appearing parthenogenically in the requirements document. Perhaps a section in the use cases document for expected usage scenarios not already covered by the use cases? On 10/24/2013 10:07 AM, Adam Montville wrote: > This has been a very good discussion to track. I agree with the notion that use cases shouldn't really consider the "how" (and, IMO, the use case document could stand to be cleaned up a bit in this way, though it may not be necessary at this point). Perhaps a use case that would (seem to) clearly require would be one that considers assessment of embedded devices which may have the ability to report configuration but not necessarily perform evaluation on-board. I'm thinking in terms of the "Internet of things." The Ice Station Zebra use case might be another, where an evaluation component may not be permissible in the environment (separation of duties, least priv, that sort of thing), but the collection still has to happen. Just throwing out ideas. > > Either way, the Requirements document is one where we're going to see most of this stuff shake out, and I think it will serve to help us refine the use cases. > > At present, I'm working on a detailed review of the Use Case document and trying to derive some potential requirements from it. Once I'm done with that, I'll float it to the list here as something to complement the existing Requirements draft and kindle some discussion. > > Adam > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Watson, Kimberly >> Sent: Thursday, October 24, 2013 8:25 AM >> To: Gunnar Engelbach; sacm@ietf.org >> Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt >> >> I can try to develop a use case...but what I realized last night is that a use case >> that would highlight these requirements will be expressing a "How" not a >> "What" which is normally a bad thing because it can bias the >> requirements/architecture derived from those use cases to a particular >> solution. >> >> I personally think it is best to keep the "How" part out of the use cases, but >> define characteristics that any/all solutions must have to ensure scalability, >> flexibility, and support incremental improvement without redesign (what I >> tend to call evolution). >> >> If we specify that any solution to a use case must be able to: >> 1. perform the assessment from collection to evaluation in one request 2. >> perform the collection at a previous point in time and then have the >> associated evaluator assess upon request 3. perform the collection at a >> previous point in time and then have ANY evaluator assess upon request >> >> This creates 2 high level requirements (probably more, but we are talking >> about these two): >> >> 1. Collection and Evaluation are decoupled 2. there must be standardization >> and transparency in the expression of collection as well as in the expression >> of evaluation >> >> At this point it is probably best to find out if anyone disagrees with the >> assertion that separating collection from evaluation is a necessary >> characteristic of solutions that address the use cases. >> >> -- >> Kim Watson >> Office of Cybersecurity and Communications Federal Network Resilience >> Blackberry: (202) 494-2534 >> >> >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Wednesday, October 23, 2013 5:30 PM >> To: Watson, Kimberly; sacm@ietf.org >> Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt >> >> >> Comments inline... >> >> >> On 10/23/2013 3:47 PM, Watson, Kimberly wrote: >>> So neither of these are articulated in the use cases, but are necessary to >> support the larger goal of scalable, flexible, and evolvable endpoint posture >> assessment as defined earlier in the document. >>> >>> Do they need to be expressly in the use cases? Or do we just need to agree >> that they are necessary characteristics or attributes of solutions to the >> problem? Can we derive requirements from the description of what >> endpoint posture assessment is or the workflow? Or can they only come >> from the use cases? >> >> That works for me, but that's easy for me to say because I already agree with >> them as requirements. >> >> Having a use case exemplifying the need would be useful. Would you care to >> submit one? >> >> >> >> >>> -- >>> Kim Watson >>> Office of Cybersecurity and Communications >>> Federal Network Resilience >>> Blackberry: (202) 494-2534 >>> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> ... > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > > . . . > From ietfdbh@comcast.net Thu Oct 24 09:31:24 2013 Return-Path: <ietfdbh@comcast.net> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A171011E81D9 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 09:31:24 -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 NCoKsxfWyplW for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 09:31:18 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 29F4011E8349 for <sacm@ietf.org>; Thu, 24 Oct 2013 09:31:13 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta15.westchester.pa.mail.comcast.net with comcast id h0PT1m0040bG4ec5F4XCwj; Thu, 24 Oct 2013 16:31:12 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta03.westchester.pa.mail.comcast.net with comcast id h4XB1m00K2yZEBF3P4XBa8; Thu, 24 Oct 2013 16:31:12 +0000 From: "ietfdbh" <ietfdbh@comcast.net> To: "'Adam Montville'" <Adam.Montville@cisecurity.org>, "'Watson, Kimberly'" <kimberly.watson@hq.dhs.gov>, "'Gunnar Engelbach'" <Gunnar.Engelbach@ThreatGuard.com>, <sacm@ietf.org> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> Date: Thu, 24 Oct 2013 12:31:07 -0400 Message-ID: <021301ced0d6$71742960$545c7c20$@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: AQJcn/HSg5VADtshI8M2LY/Abam39AHfg5iIAbg+SlYC3cMzAwKmQlnIAYuXt1YBUPQXRwEygql3mH8L5IA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382632272; bh=bXEaDvJSdFKOBfdN1eKbaW9m9saLLTnFGOivLlXWghY=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Z9ShHhVV70/bFbW4LcvH+/Jp95/Ysm0uTyqeJZs20XwlvJT7c3wlPfx6z369A41lf 2iJjiXB9qzEHZ2Z6iKsItTt1Ukuiva9OqrSf/oXbIW553crPjX8M76H0LF9G5n3+ke wmf7yWgQsimLa4Opf4x1lnXVsWk5ZRhCTDeZVBmWItPlkcuNOrDKPZ/ZEneerQQCS0 fhFgYZiqUzyWC57IqsjrYkYrmRVeWSQDqpkL3pzv0AVk9Qpu7N6FpdI/ijeYmNg7MY biCDk0HFJeEYo4lGKVx6HrCyYKSFC7xwVY6itieT1pi7LAT1OrGoEL4PdLol2QxXxp UaZWc8FpWkg2A== Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 16:31:24 -0000 Hi, >From the Intro to use-cases: Our goal with this document is to improve our agreement on which problems we're trying to solve. We need to start with short, simple problem statements and discuss those by email and in person. Once we agree on which problems we're trying to solve, we can move on to propose various solutions and decide which ones to use. So one of the issues I faced as editor of use-cases was whether to prune and rewrite use cases. The use cases have been submitted to describe how somebody uses security automation. If I rewrite the use case to remove concepts such as repository, controller, collectors, etc., then I am basically changing the use case. I slightly modified one of Gunnar's use cases to use the terms collect and evaluate, rather than assess, because I thought we had something of a WG consensus to break those concepts out, and avoid the ambiguous "assess". See my QUESTION in 2.13. If somebody has an application/system that automates an assessment process, and divides that process into a collection aspect, an evaluation aspect, and a reporting aspect, and uses another process to coordinate those aspects, and I rewrote the use case to describe it from my point of view as "well, it did an assessment" or "the system collects, evaluates, and reports on an assessment", I could be hiding the important details of the use case - that these might be separate entities in the network, produced by different vendors, and might need standardized protocols and standardized data models to transport the information between entities. I don't think such an editorial rewrite is to anybody's benefit, because when we design a sacm solution, we better take into considerations that, in some use cases, these aspects may need to be separated and coordinated, and we may need standardized protocols and data models between them. For the most part, I decided that as an editor, I should allow the use cases to be published mostly as-submitted, to ensure that the contributors' description of *their* use case isn't mangled by editing. Gunnar's use cases tend to use his preferred terminology because they represent important aspects of his usage. We can try to coalesce the terminology and architectural entities as we extract the requirements. Some of those requirements will be architectural requirements, and I think we want to understand the use cases that might drive certain architectural requirements. Certainly, if the WG would prefer to use "collect", "evaluate", and "report" rather than the all-inclusive "assess", we can ask the contributors to rewrite their use cases (or the editors can rewrite them and ask the contributor to agree it is still an accurate representation). I think it is important to capture the original in at least one revision, so it is clear what we changed from the original submissions. It might be a good idea to identify who submitted each use case, so we know who to discuss that particular use case with, to better understand that person's usage. We might also allow "me too" statements, if an existing use case already describes another's use case. I think at this point in time, we should be looking at the original use cases and trying to understand the important aspects of the use case, so we can extract requirements for sacm, without rewriting the use cases, so we can try to better understand the requirements. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Thursday, October 24, 2013 10:59 AM > To: Watson, Kimberly; Gunnar Engelbach; sacm@ietf.org > Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt > > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > > Adam Montville > > Sent: Thursday, October 24, 2013 9:09 AM > > To: Watson, Kimberly; Gunnar Engelbach; sacm@ietf.org > > Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt > > > > This has been a very good discussion to track. I agree with the notion that > > use cases shouldn't really consider the "how" (and, IMO, the use case > > document could stand to be cleaned up a bit in this way, though it may not > > be necessary at this point). > > > For the sake of providing an example with respect to my comment about > how the use case document could be cleaned up a bit, I happened to be > reviewing 2.12 (Traditional Endpoint Assessment with Stored Results) just > now. It reads: > > "An external trigger initiates an assessment of an endpoint. The > Controller uses the data in the Datastore to look up authentication > information for the endpoint and passes that along with the > assessment request details to the Evaluator. The Evaluator uses the > Endpoint information to request taxonomy information from the > Collector on the endpoint, which responds with those attributes. The > Evaluator uses that taxonomy information along with the information > in the original request from the Controller to request the > appropriate content from the Content Repository. The Evaluator uses > the content to derive the minimal set of endpoint attributes needed > to perform the assessment and makes that request. The Evaluator uses > the Collector response to do the assessment and returns the results > to the Controller. The Controller puts the results in the Datastore." > > IMO, there should probably be no discussion in this use case of a Datastore, > Controller, Content Repository. By my read, this use case intends to say: > "The system, triggered externally, targets an endpoint for characterization > (inventory?), so that the system can determine the minimal set of endpoint > attributes to collect and store for subsequent use." > > From here, we can derive requirements such as: > > - The system must support assessment triggers from external sources > - The system should support authentication for external assessment triggers > - The system should support authorization for external assessment triggers > - The system must support target endpoint inventory (I think this is what was > intended by requesting "taxonomy") > - The system must support checklist composition based on target endpoint > inventory > - The system must support composite checklist optimization (i.e. remove > duplicate collection expressions) > - The system must make assessment results available for subsequent use > > Architectures would then get into the "how" of it all, which is where I would > see Collectors, Datastores, Evaluators, etc. come into play. There's more > than one way to satisfy the requirements which are derived from this > particular use case. > > The Use Case, as written, gets the point across, but I think it does so > superfluously. Maybe it's just a matter of personal taste or preference, but I > think a sentence or two would capture the intent of this use case without > implying or assuming any particular architectural solution. This may or may > not be the case with each other use case, though from what I've been > through so far, I think most could stand to be pruned. > > Adam > > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Thu Oct 24 09:48:04 2013 Return-Path: <gunnar.engelbach@threatguard.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE7E11E8189 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 09:48: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=[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 t+8DhzbY+LS0 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 09:47:43 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id C04DE11E8351 for <sacm@ietf.org>; Thu, 24 Oct 2013 09:47:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=LmLkKfRzAJr6CAbKsFQtZWzogJQJzj7W5olOH9IW5/oBcxCeASvNM1f78J3IQZEjzjgveMJTq6dU05EJ5QqG8xNZxseZ6PhSpYYR/B3cVmnpeEzSptt65HGZBgA6ULNT; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23339 invoked from network); 24 Oct 2013 09:48:53 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Oct 2013 09:48:53 -0700 Message-ID: <52694EF9.4080308@ThreatGuard.com> Date: Thu, 24 Oct 2013 12:46:49 -0400 From: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com> Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adam Montville <Adam.Montville@cisecurity.org>, "Watson, Kimberly" <kimberly.watson@hq.dhs.gov>, "sacm@ietf.org" <sacm@ietf.org> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 16:48:05 -0000 X-List-Received-Date: Thu, 24 Oct 2013 16:48:05 -0000 On 10/24/2013 10:59 AM, Adam Montville wrote: > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Thursday, October 24, 2013 9:09 AM >> To: Watson, Kimberly; Gunnar Engelbach; sacm@ietf.org >> Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt >> >> This has been a very good discussion to track. I agree with the notion that >> use cases shouldn't really consider the "how" (and, IMO, the use case >> document could stand to be cleaned up a bit in this way, though it may not >> be necessary at this point). > > > For the sake of providing an example with respect to my comment about how the use case document could be cleaned up a bit, I happened to be reviewing 2.12 (Traditional Endpoint Assessment with Stored Results) just now. It reads: > > "An external trigger initiates an assessment of an endpoint. The > Controller uses the data in the Datastore to look up authentication > information for the endpoint and passes that along with the > assessment request details to the Evaluator. The Evaluator uses the > Endpoint information to request taxonomy information from the > Collector on the endpoint, which responds with those attributes. The > Evaluator uses that taxonomy information along with the information > in the original request from the Controller to request the > appropriate content from the Content Repository. The Evaluator uses > the content to derive the minimal set of endpoint attributes needed > to perform the assessment and makes that request. The Evaluator uses > the Collector response to do the assessment and returns the results > to the Controller. The Controller puts the results in the Datastore." > > IMO, there should probably be no discussion in this use case of a Datastore, Controller, Content Repository. > By my read, this use case intends to say: "The system, triggered externally, targets an endpoint for characterization (inventory?), so that the system can determine the minimal set of endpoint attributes to collect and store for subsequent use." +1 With the exception of the taxonomy step, this use case is covered in others such as 2.2. Taxonomy wouldn't be a full inventory. Just enough to determine what content applies to an endpoint. CPE vice AI. Similarly, 2.13 and 2.14 can be merged with the understanding that the system might trust the connecting endpoint to submit its own self-evaluation results, whereas others might only request specific system characteristics and do the evaluation internally. > > From here, we can derive requirements such as: > > - The system must support assessment triggers from external sources > - The system should support authentication for external assessment triggers > - The system should support authorization for external assessment triggers > - The system must support target endpoint inventory (I think this is what was intended by requesting "taxonomy") > - The system must support checklist composition based on target endpoint inventory > - The system must support composite checklist optimization (i.e. remove duplicate collection expressions) > - The system must make assessment results available for subsequent use > > Architectures would then get into the "how" of it all, which is where I would see Collectors, Datastores, Evaluators, etc. come into play. There's more than one way to satisfy the requirements which are derived from this particular use case. > > The Use Case, as written, gets the point across, but I think it does so superfluously. Maybe it's just a matter of personal taste or preference, but I think a sentence or two would capture the intent of this use case without implying or assuming any particular architectural solution. This may or may not be the case with each other use case, though from what I've been through so far, I think most could stand to be pruned. Brevity is good. Then again, compression means data loss. > > Adam > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > > . . . > From Adam.Montville@cisecurity.org Thu Oct 24 10:08:46 2013 Return-Path: <Adam.Montville@cisecurity.org> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9222B11E81B9 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 10:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RneduCrkEGX for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 10:08:30 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id F19CC11E837F for <sacm@ietf.org>; Thu, 24 Oct 2013 10:07:34 -0700 (PDT) Received: from [216.82.253.227:24971] by server-13.bemta-7.messagelabs.com id 8C/9D-18139-CC359625; Thu, 24 Oct 2013 17:07:24 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-170.messagelabs.com!1382634443!22868285!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 18618 invoked from network); 24 Oct 2013 17:07:24 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 24 Oct 2013 17:07:24 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c]) by CISEXCHANGE1.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 24 Oct 2013 13:06:52 -0400 From: Adam Montville <Adam.Montville@cisecurity.org> To: ietfdbh <ietfdbh@comcast.net>, "'Watson, Kimberly'" <kimberly.watson@hq.dhs.gov>, 'Gunnar Engelbach' <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: Ac7OpSVwj/HG00ZWT7aKJLUVL/1RGQA4C2KAAAafTgAAKprogAADl2aAACFWyoAAByQ7kAAMpgHQ//+VtICAADmgMA== Date: Thu, 24 Oct 2013 17:06:50 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D606257095@CISEXCHANGE2.msisac.org.local> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> <021301ced0d6$71742960$545c7c20$@comcast.net> In-Reply-To: <021301ced0d6$71742960$545c7c20$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 17:08:47 -0000 > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Thursday, October 24, 2013 11:31 AM > To: Adam Montville; 'Watson, Kimberly'; 'Gunnar Engelbach'; sacm@ietf.or= g > Subject: RE: [sacm] review of draft-camwinget-sacm-requirements-01.txt >=20 > Hi, >=20 > From the Intro to use-cases: > Our goal with this document is to improve our agreement on which > problems we're trying to solve. We need to start with short, simple > problem statements and discuss those by email and in person. Once we= > agree on which problems we're trying to solve, we can move on to > propose various solutions and decide which ones to use. >=20 > So one of the issues I faced as editor of use-cases was whether to prune= and > rewrite use cases. > The use cases have been submitted to describe how somebody uses security= > automation. > If I rewrite the use case to remove concepts such as repository, control= ler, > collectors, etc., then I am basically changing the use case. >=20 > I slightly modified one of Gunnar's use cases to use the terms collect a= nd > evaluate, rather than assess, because I thought we had something of a WG= > consensus to break those concepts out, and avoid the ambiguous "assess".= > See my QUESTION in 2.13. >=20 > If somebody has an application/system that automates an assessment > process, and divides that process into a collection aspect, an evaluatio= n > aspect, and a reporting aspect, and uses another process to coordinate t= hose > aspects, and I rewrote the use case to describe it from my point of vie= w as > "well, it did an assessment" or "the system collects, evaluates, and rep= orts > on an assessment", I could be hiding the important details of the use ca= se - > that these might be separate entities in the network, produced by differ= ent > vendors, and might need standardized protocols and standardized data > models to transport the information between entities. I don't think such= an > editorial rewrite is to anybody's benefit, because when we design a sacm= > solution, we better take=20into considerations that, in some use cases, = these > aspects may need to be separated and coordinated, and we may need > standardized protocols and data models between them. >=20 > For the most part, I decided that as an editor, I should allow the use c= ases to > be published mostly as-submitted, to ensure that the contributors' > description of *their* use case isn't mangled by editing. Gunnar's use c= ases > tend to use his preferred terminology because they represent important > aspects of his usage. We can try to coalesce the terminology and archite= ctural > entities as we extract the requirements. Some of those requirements will= be > architectural requirements, and I think we want to understand the use ca= ses > that might drive certain architectural requirements. >=20 > Certainly, if the WG would prefer to use "collect", "evaluate", and "rep= ort" > rather than the all-inclusive "assess", we can ask the contributors to r= ewrite > their use cases (or the editors can rewrite them and ask the contributor= to > agree it is still an accurate representation). I think it is important t= o capture > the original in at least one revision, so it is clear what we changed fr= om the > original submissions. >=20 > It might be a good idea to identify who submitted each use case, so we k= now > who to discuss that particular use case with, to better understand that > person's usage. We might also allow "me too" statements, if an existing = use > case already describes another's use case. Good idea. Here's a list of the use cases. Can the submitter of each use case indica= te so? 2.1=09Definition and Publication of Automatable Configuration Guides 2.2=09Automated Checklist Verification 2.3=09Organizational Software Policy Compliance 2.4=09Detection of Posture Deviations 2.5=09Search of Signs of Infection 2.6=09Remediation and Mitigation 2.7=09Endpoint Information Analysis and Reporting 2.8=09Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebr= a 2.9=09Vulnerable Endpoint Identification 2.10=09Compromised Endnpoint Identification 2.11=09Suspicious Endpoint Behavior 2.12=09Traditional endpoint assessment with stored results 2.13=09NAC/NAP connection with no stored results using an endpoint evaluat= or 2.14=09NAC/NAP connection with no stored results using a third-party evalu= ator 2.15=09Repository Interaction - A Full Assessment 2.16=09Repository Interaction - Filtered Delta Assessment 2.17=09Direct Human Retrieval of Ancillary Materials 2.18=09Register with repository for immediate notification of new security= vulnerability content that match a selection filter >=20 > I think at this point in time, we should be looking at the original use = cases and > trying to understand the important aspects of the use case, so we can ex= tract > requirements for sacm, without rewriting the use cases, so we can try to= > better understand the requirements. I agree. It may be helpful to understand the important aspects by getting= the use cases to be a bit more concise. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Thursday, October 24, 2013 10:59 AM > > To: Watson, Kimberly; Gunnar Engelbach; sacm@ietf.org > > Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt= > > > > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > Of > > > Adam Montville > > > Sent: Thursday, October 24, 2013 9:09 AM > > > To: Watson, Kimberly; Gunnar Engelbach; sacm@ietf.org > > > Subject: Re: [sacm] review of > > > draft-camwinget-sacm-requirements-01.txt > > > > > > This has been a very good discussion to track. I agree with the > > > notion > that > > > use cases shouldn't really consider the "how" (and, IMO, the use > > > case document could stand to be cleaned up a bit in this way, though= > > > it may > not > > > be necessary at this point). > > > > > > For the sake of providing an example with respect to my comment about > > how the use case document could be cleaned up a bit, I happened to be > > reviewing 2.12 (Traditional Endpoint Assessment with Stored Results) > > just now. It reads: > > > > "An external trigger initiates an assessment of an endpoint. The > > Controller uses the data in the Datastore to look up authentication= > > information for the endpoint and passes that along with the > > assessment request details to the Evaluator. The Evaluator uses th= e > > Endpoint information to request taxonomy information from the > > Collector on the endpoint, which responds with those attributes. T= he > > Evaluator uses that taxonomy information along with the information= > > in the original request from the Controller to request the > > appropriate content from the Content Repository. The Evaluator use= s > > the content to derive the minimal set of endpoint attributes needed= > > to perform the assessment and makes that request. The Evaluator us= es > > the Collector response to do the assessment and returns the results= > > to the Controller. The Controller puts the results in the Datastor= e." > > > > IMO, there should probably be no discussion in this use case of a > Datastore, > > Controller, Content Repository. By my read, this use case intends to = say: > > "The system, triggered externally, targets an endpoint for > characterization > > (inventory?), so that the system can determine the minimal set of > > endpoint attributes to collect and store for subsequent use." > > > > From here, we can derive requirements such as: > > > > - The system must support assessment triggers from external sources > > - The system should support authentication for external assessment > triggers > > - The system should support authorization for external assessment > > triggers > > - The system must support target endpoint inventory (I think this is > > what > was > > intended by requesting "taxonomy") > > - The system must support checklist composition based on target > > endpoint inventory > > - The system must support composite checklist optimization (i.e. > > remove duplicate collection expressions) > > - The system must make assessment results available for subsequent use= > > > > Architectures would then get into the "how" of it all, which is where > > I > would > > see Collectors, Datastores, Evaluators, etc. come into play. There's > > more than one way to satisfy the requirements which are derived from > > this particular use case. > > > > The Use Case, as written, gets the point across, but I think it does > > so superfluously. Maybe it's just a matter of personal taste or > > preference, > but I > > think a sentence or two would capture the intent of this use case > > without implying or assuming any particular architectural solution. > > This may or > may > > not be the case with each other use case, though from what I've been > > through so far, I think most could stand to be pruned. > > > > Adam > > > > . . . > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 > ... . . . From gunnar.engelbach@threatguard.com Thu Oct 24 11:26:40 2013 Return-Path: <gunnar.engelbach@threatguard.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1979311E837B for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 11:26:40 -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 iD-ThJDYB9aW for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 11:26:34 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 447A811E82F9 for <sacm@ietf.org>; Thu, 24 Oct 2013 11:26:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=AEfMSly0cc/FxKO2emxVzQOsLV2NuhNTimzbd5RbHVbG8uUo5LXsI102W4IlGrd2o6AgJFRzhckg+HX8qESSil26qSpxdUDBcHpHDKw/KzjageV9Hl7XgfZnrU9riN6N; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 765 invoked from network); 24 Oct 2013 11:28:40 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Oct 2013 11:28:40 -0700 Message-ID: <5269665C.8050706@ThreatGuard.com> Date: Thu, 24 Oct 2013 14:26:36 -0400 From: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com> Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adam Montville <Adam.Montville@cisecurity.org>, ietfdbh <ietfdbh@comcast.net>, "'Watson, Kimberly'" <kimberly.watson@hq.dhs.gov>, "sacm@ietf.org" <sacm@ietf.org> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> <021301ced0d6$71742960$545c7c20$@comcast.net> <05BCCEB107AF88469B9F99783D47C1D606257095@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D606257095@CISEXCHANGE2.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 18:26:40 -0000 On 10/24/2013 1:06 PM, Adam Montville wrote: > > >> >> It might be a good idea to identify who submitted each use case, so we know >> who to discuss that particular use case with, to better understand that >> person's usage. We might also allow "me too" statements, if an existing use >> case already describes another's use case. > > Good idea. > > Here's a list of the use cases. Can the submitter of each use case indicate so? > 2.1 Definition and Publication of Automatable Configuration Guides 2.2 Automated Checklist Verification 2.3 Organizational Software Policy Compliance 2.4 Detection of Posture Deviations 2.5 Search of Signs of Infection 2.6 Remediation and Mitigation 2.7 Endpoint Information Analysis and Reporting * 2.8 Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra 2.9 Vulnerable Endpoint Identification 2.10 Compromised Endnpoint Identification 2.11 Suspicious Endpoint Behavior * 2.12 Traditional endpoint assessment with stored results * 2.13 NAC/NAP connection with no stored results using an endpoint evaluator * 2.14 NAC/NAP connection with no stored results using a third-party evaluator * 2.15 Repository Interaction - A Full Assessment * 2.16 Repository Interaction - Filtered Delta Assessment * 2.17 Direct Human Retrieval of Ancillary Materials * 2.18 Register with repository for immediate notification of new security vulnerability content that match a selection filter * These are the ones that I remember. From david.waltermire@nist.gov Thu Oct 24 11:35:12 2013 Return-Path: <david.waltermire@nist.gov> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3BF11E83A0 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 11:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WJLSKoPs-jl for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 11:34:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id E445411E81D1 for <sacm@ietf.org>; Thu, 24 Oct 2013 11:34:45 -0700 (PDT) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.800.7; Thu, 24 Oct 2013 18:34:41 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.209]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.209]) with mapi id 15.00.0800.005; Thu, 24 Oct 2013 18:34:41 +0000 From: "Waltermire, David A." <david.waltermire@nist.gov> To: Adam Montville <Adam.Montville@cisecurity.org>, ietfdbh <ietfdbh@comcast.net>, "'Watson, Kimberly'" <kimberly.watson@hq.dhs.gov>, 'Gunnar Engelbach' <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: Ac7OpSVwj/HG00ZWT7aKJLUVL/1RGQAvqZ2AAAafTwAAKprngAADl2eAACFWyoAAAYABAAABzX2AAAMzRIAAAT9VAAAC5oKA Date: Thu, 24 Oct 2013 18:34:40 +0000 Message-ID: <06bfbe141c134469804a44fdd8ac0fa3@BLUPR09MB038.namprd09.prod.outlook.com> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> <021301ced0d6$71742960$545c7c20$@comcast.net> <05BCCEB107AF88469B9F99783D47C1D606257095@CISEXCHANGE2.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D606257095@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(59766001)(77982001)(77096001)(56816003)(79102001)(63696002)(76576001)(74366001)(56776001)(54316002)(81542001)(83322001)(33646001)(76482001)(51856001)(80976001)(76796001)(81342001)(66066001)(76786001)(65816001)(80022001)(74502001)(69226001)(74662001)(47446002)(81686001)(31966008)(47976001)(47736001)(50986001)(83072001)(53806001)(85306002)(74876001)(4396001)(49866001)(74706001)(54356001)(74316001)(46102001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 18:35:12 -0000 > Here's a list of the use cases. Can the submitter of each use case indic= ate so? I wrote or refined use cases 2.1 - 2.4. Much of this was based on feedback = and discussion from the list so I hesitate to take full credit for submissi= on. > 2.1 Definition and Publication of Automatable Configuration Guides > 2.2 Automated Checklist Verification > 2.3 Organizational Software Policy Compliance > 2.4 Detection of Posture Deviations > 2.5 Search of Signs of Infection > 2.6 Remediation and Mitigation > 2.7 Endpoint Information Analysis and Reporting > 2.8 Asynchronous Compliance/Vulnerability Assessment at Ice Station > Zebra > 2.9 Vulnerable Endpoint Identification > 2.10 Compromised Endnpoint Identification > 2.11 Suspicious Endpoint Behavior > 2.12 Traditional endpoint assessment with stored results > 2.13 NAC/NAP connection with no stored results using an endpoint > evaluator > 2.14 NAC/NAP connection with no stored results using a third-party > evaluator > 2.15 Repository Interaction - A Full Assessment > 2.16 Repository Interaction - Filtered Delta Assessment > 2.17 Direct Human Retrieval of Ancillary Materials > 2.18 Register with repository for immediate notification of new security > vulnerability content that match a selection filter From shanna@juniper.net Thu Oct 24 13:40:07 2013 Return-Path: <shanna@juniper.net> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49311E8228 for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 13:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=-0.594, 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 7vAqQnF465rK for <sacm@ietfa.amsl.com>; Thu, 24 Oct 2013 13:40:00 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id AC9B211E83A9 for <sacm@ietf.org>; Thu, 24 Oct 2013 13:39:50 -0700 (PDT) Received: from mail48-db8-R.bigfish.com (10.174.8.229) by DB8EHSOBE009.bigfish.com (10.174.4.72) with Microsoft SMTP Server id 14.1.225.22; Thu, 24 Oct 2013 20:39:40 +0000 Received: from mail48-db8 (localhost [127.0.0.1]) by mail48-db8-R.bigfish.com (Postfix) with ESMTP id C264CA00102 for <sacm@ietf.org>; Thu, 24 Oct 2013 20:39:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zz98dI4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail48-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(24454002)(54356001)(49866001)(47736001)(47976001)(50986001)(80976001)(76482001)(63696002)(81816001)(76796001)(76786001)(83072001)(56776001)(54316002)(74876001)(47446002)(65816001)(74706001)(74502001)(31966008)(66066001)(80022001)(74366001)(74662001)(33646001)(77982001)(79102001)(53806001)(4396001)(83322001)(59766001)(51856001)(46102001)(77096001)(81686001)(74316001)(76576001)(69226001)(81342001)(81542001)(56816003)(85306002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB326; H:BN1PR05MB326.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail48-db8 (localhost.localdomain [127.0.0.1]) by mail48-db8 (MessageSwitch) id 1382647178622911_27457; Thu, 24 Oct 2013 20:39:38 +0000 (UTC) Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.238]) by mail48-db8.bigfish.com (Postfix) with ESMTP id 8AC78340040 for <sacm@ietf.org>; Thu, 24 Oct 2013 20:39:38 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 24 Oct 2013 20:39:38 +0000 Received: from BN1PR05MB326.namprd05.prod.outlook.com (10.141.62.147) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 24 Oct 2013 20:39:38 +0000 Received: from BN1PR05MB326.namprd05.prod.outlook.com (10.141.62.147) by BN1PR05MB326.namprd05.prod.outlook.com (10.141.62.147) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 24 Oct 2013 20:39:36 +0000 Received: from BN1PR05MB326.namprd05.prod.outlook.com ([169.254.2.180]) by BN1PR05MB326.namprd05.prod.outlook.com ([169.254.2.215]) with mapi id 15.00.0785.001; Thu, 24 Oct 2013 20:39:36 +0000 From: Stephen Hanna <shanna@juniper.net> To: "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] review of draft-camwinget-sacm-requirements-01.txt Thread-Index: Ac7OpSVwj/HG00ZWT7aKJLUVL/1RGQAvqZ2AAAafTwAAKprngAADl2eAACFWyoAAAYABAAABzX2AAAMzRIAAAT9VAAAC5oKAAANJqLA= Date: Thu, 24 Oct 2013 20:39:35 +0000 Message-ID: <acb4ccfeba194b39ae40b5c3f5224a59@BN1PR05MB326.namprd05.prod.outlook.com> References: <011a01ceceb3$6a6317f0$3f2947d0$@comcast.net> <E96AF2CDB5A3BF4E8F88AC07C83560B11D7D6C@D2ASEPREA006.DSA.DHS> <526709E6.2090206@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11D84CE@D2ASEPREA006.DSA.DHS> <52683FEB.2010703@ThreatGuard.com> <E96AF2CDB5A3BF4E8F88AC07C83560B11DA773@D2ASEPREA006.DSA.DHS> <05BCCEB107AF88469B9F99783D47C1D606253FC7@CISEXCHANGE2.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D606254FE8@CISEXCHANGE2.msisac.org.local> <021301ced0d6$71742960$545c7c20$@comcast.net> <05BCCEB107AF88469B9F99783D47C1D606257095@CISEXCHANGE2.msisac.org.local> <06bfbe141c134469804a44fdd8ac0fa3@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <06bfbe141c134469804a44fdd8ac0fa3@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 000947967F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] review of draft-camwinget-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Oct 2013 20:40:07 -0000 Adam Montville wrote: > Here's a list of the use cases. Can the submitter of each > use case indicate so? I wrote use cases 2.5 - 2.7. Let me say that I completely endorse Adam's suggestion to pare the use cases down to a small set of brief ones that succinctly spans and explains the problems we must address. Dave Harrington expressed concern that editing use cases involves changing the use cases. True but that's OK. The goal here should not be to preserve intact every person's ideas but to arrive at a short, understandable document that spans and explains the essential use cases. Some of the current use case text refers to architectural components like Datastore, Controller, and Registry. Again, I agree with Adam who said those do not belong in a use case. The use case should describe the problem not how it's solved. Thanks, Steve From david.waltermire@nist.gov Fri Oct 25 10:18:18 2013 Return-Path: <david.waltermire@nist.gov> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209A311E831A for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 10:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxnK+2xlrcDP for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 10:18:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 26EBF11E81AC for <sacm@ietf.org>; Fri, 25 Oct 2013 10:18:07 -0700 (PDT) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 25 Oct 2013 17:18:05 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.209]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.209]) with mapi id 15.00.0800.005; Fri, 25 Oct 2013 17:18:04 +0000 From: "Waltermire, David A." <david.waltermire@nist.gov> To: "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: Cyber Physical Systems Thread-Index: Ac7Ro/i6dKQsj3s9Rhm8Lg+vu/wFaw== Date: Fri, 25 Oct 2013 17:18:04 +0000 Message-ID: <8ccfe87ef1054ad9982804663a41cbaa@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(85306002)(81542001)(65816001)(80022001)(66066001)(74706001)(74876001)(69226001)(63696002)(74366001)(81342001)(81686001)(77982001)(59766001)(81816001)(76176001)(83072001)(76482001)(4396001)(83322001)(33646001)(19580395003)(80976001)(54316002)(56776001)(31966008)(74662001)(74502001)(47446002)(47736001)(50986001)(49866001)(47976001)(19300405004)(76796001)(74316001)(19609705001)(15975445006)(76786001)(16236675002)(46102001)(76576001)(79102001)(15202345003)(54356001)(56816003)(77096001)(51856001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_8ccfe87ef1054ad9982804663a41cbaaBLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [sacm] Cyber Physical Systems X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Oct 2013 17:18:18 -0000 --_000_8ccfe87ef1054ad9982804663a41cbaaBLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One other area to consider defining as a use case or two around is monitori= ng expected vs. actual state for cyber physical systems. Another option is = to provide some discussion around how the current use cases apply to this d= omain. Control systems and sensors used to manage and monitor manufacturing, commu= nications, power, medical, and many other critical infrastructure areas fit= into our definition of endpoints. The have many of the same properties as = classical IT devices. They are networked, configurable, and have software a= nd firmware that need to be managed. They also often provide high-velocity = sensor data that reflects the current operational posture of the device or = a mechanism that they manage. It seems like the availability and integrity = over the operational state of these devices represent a security concern th= at is relevant to our charter. I am working to get some participation from individuals involved more intim= ately in this space. Thoughts? Dave --_000_8ccfe87ef1054ad9982804663a41cbaaBLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">One other area to consider defining as a use case or= two around is monitoring expected vs. actual state for cyber physical syst= ems. Another option is to provide some discussion around how the current us= e cases apply to this domain.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Control systems and sensors used to manage and monit= or manufacturing, communications, power, medical, and many other critical i= nfrastructure areas fit into our definition of endpoints. The have many of = the same properties as classical IT devices. They are networked, configurable, and have software and firmware = that need to be managed. They also often provide high-velocity sensor data = that reflects the current operational posture of the device or a mechanism = that they manage. It seems like the availability and integrity over the operational state of these devices= represent a security concern that is relevant to our charter.<o:p></o:p></= p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I am working to get some participation from individu= als involved more intimately in this space.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Thoughts?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Dave<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_8ccfe87ef1054ad9982804663a41cbaaBLUPR09MB038namprd09pro_-- From gunnar.engelbach@threatguard.com Fri Oct 25 10:26:52 2013 Return-Path: <gunnar.engelbach@threatguard.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD8311E8356 for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 10:26:51 -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 kvaGsBMi6Ose for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 10:26:36 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1886711E81AD for <sacm@ietf.org>; Fri, 25 Oct 2013 10:26:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=BvjQuYpfH8WbYsSRvEWlxYhkKB7WNRWZf/GXUwSxblxfFsm1sfcM0eekWqVDXrp2Zya+FSDjW9Taqd3fiLqDftMFD21Fct302WkGx8nkiqNCwBZx0Tw84ROYnArm48JV; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 9044 invoked from network); 25 Oct 2013 10:28:44 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Oct 2013 10:28:44 -0700 Message-ID: <526AA9CF.5020507@ThreatGuard.com> Date: Fri, 25 Oct 2013 13:26:39 -0400 From: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com> Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Waltermire, David A." <david.waltermire@nist.gov>, "sacm@ietf.org" <sacm@ietf.org> References: <8ccfe87ef1054ad9982804663a41cbaa@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <8ccfe87ef1054ad9982804663a41cbaa@BLUPR09MB038.namprd09.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] Cyber Physical Systems X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Oct 2013 17:26:52 -0000 Such use cases would help show the breadth of SACM applicability, but would they create any new requirements? Worth a try just to see. On 10/25/2013 1:18 PM, Waltermire, David A. wrote: > One other area to consider defining as a use case or two around is > monitoring expected vs. actual state for cyber physical systems. Another > option is to provide some discussion around how the current use cases > apply to this domain. > > Control systems and sensors used to manage and monitor manufacturing, > communications, power, medical, and many other critical infrastructure > areas fit into our definition of endpoints. The have many of the same > properties as classical IT devices. They are networked, configurable, > and have software and firmware that need to be managed. They also often > provide high-velocity sensor data that reflects the current operational > posture of the device or a mechanism that they manage. It seems like the > availability and integrity over the operational state of these devices > represent a security concern that is relevant to our charter. > > I am working to get some participation from individuals involved more > intimately in this space. > > Thoughts? > > Dave > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From david.waltermire@nist.gov Fri Oct 25 12:23:59 2013 Return-Path: <david.waltermire@nist.gov> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053F911E81AB for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 12:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsi+9XEAdPuU for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 12:23:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id A919511E810C for <sacm@ietf.org>; Fri, 25 Oct 2013 12:23:49 -0700 (PDT) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 25 Oct 2013 19:23:48 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.209]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.209]) with mapi id 15.00.0800.005; Fri, 25 Oct 2013 19:23:47 +0000 From: "Waltermire, David A." <david.waltermire@nist.gov> To: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] Cyber Physical Systems Thread-Index: Ac7Ro/i6dKQsj3s9Rhm8Lg+vu/wFawAA2RCAAAQSQTA= Date: Fri, 25 Oct 2013 19:23:47 +0000 Message-ID: <13d4ba6b956a41e1a6341a5233b14875@BLUPR09MB038.namprd09.prod.outlook.com> References: <8ccfe87ef1054ad9982804663a41cbaa@BLUPR09MB038.namprd09.prod.outlook.com> <526AA9CF.5020507@ThreatGuard.com> In-Reply-To: <526AA9CF.5020507@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(33646001)(74316001)(76482001)(81816001)(81542001)(74366001)(81686001)(69226001)(76576001)(56816003)(76786001)(76796001)(77096001)(74706001)(81342001)(51856001)(74876001)(85306002)(54356001)(79102001)(53806001)(47736001)(49866001)(66066001)(80022001)(83072001)(65816001)(63696002)(80976001)(558084003)(31966008)(74662001)(83322001)(59766001)(77982001)(74502001)(47446002)(4396001)(54316002)(56776001)(47976001)(50986001)(46102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Cyber Physical Systems X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Oct 2013 19:23:59 -0000 > Such use cases would help show the breadth of SACM applicability, but > would they create any new requirements? Worth a try just to see. I think so too. Dave From Adam.Montville@cisecurity.org Fri Oct 25 12:58:31 2013 Return-Path: <Adam.Montville@cisecurity.org> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D3711E81F5 for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 12:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28TmUmMidunX for <sacm@ietfa.amsl.com>; Fri, 25 Oct 2013 12:58:17 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.6]) by ietfa.amsl.com (Postfix) with ESMTP id A687E11E8191 for <sacm@ietf.org>; Fri, 25 Oct 2013 12:58:17 -0700 (PDT) Received: from [216.82.250.19:37676] by server-6.bemta-12.messagelabs.com id 19/DC-06818-65DCA625; Fri, 25 Oct 2013 19:58:14 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-12.tower-87.messagelabs.com!1382731085!16232259!3 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 7627 invoked from network); 25 Oct 2013 19:58:14 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-12.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 25 Oct 2013 19:58:14 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c%12]) with mapi id 14.02.0347.000; Fri, 25 Oct 2013 15:57:36 -0400 From: Adam Montville <Adam.Montville@cisecurity.org> To: "Waltermire, David A." <david.waltermire@nist.gov>, Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] Cyber Physical Systems Thread-Index: Ac7Ro/i6dKQsj3s9Rhm8Lg+vu/wFawAJOtSAAAQXQYAAB0pa8A== Date: Fri, 25 Oct 2013 19:57:36 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065A388D@CISEXCHANGE1.msisac.org.local> References: <8ccfe87ef1054ad9982804663a41cbaa@BLUPR09MB038.namprd09.prod.outlook.com> <526AA9CF.5020507@ThreatGuard.com> <13d4ba6b956a41e1a6341a5233b14875@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <13d4ba6b956a41e1a6341a5233b14875@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Cyber Physical Systems X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Oct 2013 19:58:31 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Friday, October 25, 2013 2:23 PM > To: Gunnar Engelbach; sacm@ietf.org > Subject: Re: [sacm] Cyber Physical Systems >=20 > > Such use cases would help show the breadth of SACM applicability, but > > would they create any new requirements? Worth a try just to see. >=20 > I think so too. I actually believe we'll find some requirements in there, but mainly in te= rms of environmental constraints. The "Ice Station Zebra" Use Case touche= s on some of these by describing the reliance on a satellite link, but emb= edded device and other "Internet of Things" environments may present addit= ional environmental constraints we might need to consider in terms of inte= rmittent connectivity, acceptable collection windows, network latency, and= so on. =20 >=20 > Dave > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... . . . From Adam.Montville@cisecurity.org Mon Oct 28 09:08:13 2013 Return-Path: <Adam.Montville@cisecurity.org> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046D021E8095 for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcInGqCpiV9h for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 09:08:05 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.13]) by ietfa.amsl.com (Postfix) with ESMTP id D646D21E8087 for <sacm@ietf.org>; Mon, 28 Oct 2013 09:07:49 -0700 (PDT) Received: from [216.82.250.179:51225] by server-13.bemta-12.messagelabs.com id 7F/EA-07967-5DB8E625; Mon, 28 Oct 2013 16:07:49 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-3.tower-210.messagelabs.com!1382976468!1345208!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 887 invoked from network); 28 Oct 2013 16:07:48 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-3.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 28 Oct 2013 16:07:48 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Mon, 28 Oct 2013 12:07:05 -0400 From: Adam Montville <Adam.Montville@cisecurity.org> To: "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: Use Case Examination and Potential Requirements Thread-Index: Ac7T9yQpdS7qs1iOTQWQfu1O41i/QQ== Date: Mon, 28 Oct 2013 16:07:07 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065B3BD8@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/mixed; boundary="_002_05BCCEB107AF88469B9F99783D47C1D6065B3BD8CISEXCHANGE1msi_" MIME-Version: 1.0 Subject: [sacm] Use Case Examination and Potential Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Oct 2013 16:08:13 -0000 --_002_05BCCEB107AF88469B9F99783D47C1D6065B3BD8CISEXCHANGE1msi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: I've gone through the use cases and examined them for what I might initial= ly extract as requirements. In anticipation of some UC removal and additi= on, I've given each UC a reference ID of the form UC-nn, where n is a digi= t from 0-9. Similarly, each requirement is given an ID of the form REQ-nn= n, again where n is a digit from 0-9. I've attached the analysis in csv form to this note. Should it go up on a= wiki instead? Please note that my analysis is based on a fairly quick pass and makes no = attempt to weed out duplicate requirements. My intent in sharing this is = to kindle discussion and gain additional clarity on where we're going with= this work. Regards, Adam . . . --_002_05BCCEB107AF88469B9F99783D47C1D6065B3BD8CISEXCHANGE1msi_ Content-Type: application/octet-stream; name="initial_requirements_pass.csv" Content-Description: initial_requirements_pass.csv Content-Disposition: attachment; filename="initial_requirements_pass.csv"; size=9911; creation-date="Mon, 28 Oct 2013 16:07:27 GMT"; modification-date="Mon, 28 Oct 2013 16:07:02 GMT" Content-Transfer-Encoding: base64 UmVxLiAjLFVDICMsRGVzY3JpcHRpb24sTm90ZXMNUkVRLTAwMSxVQy0wMCxNdXN0IGNvbGxlY3Qg YXR0cmlidXRlcyBvZiBhIGdpdmVuIGVuZHBvaW50LCJIYXZlIHdlIHN1ZmZpY2llbnRseSBkZWZp bmVkICIiYXR0cmJ1dGUiIj8iDVJFUS0wMDIsVUMtMDAsQXR0cmlidXRlcyBtdXN0IGJlIG1hZGUg YXZhaWxhYmxlIGZvciBldmFsdWF0aW9uLCJIYXZlIHdlIHN1ZmZpY2llbnRseSBkZWZpbmVkICIi ZXZhbHVhdGlvbiIiPyINUkVRLTAwMyxVQy0wMCwiQXR0cmlidXRlcyBtdXN0IGJlIG1hZGUgYXZh aWxhYmxlIGZvciAiImFjdGlvbiIiIiwiSGF2ZSB3ZSBzdWZmaWNpZW50bHkgZGVmaW5lZCAiImFj dGlvbiIiPyINUkVRLTAwNCxVQy0wMCxNdXN0IGVpdGhlciByZXByZXNlbnQvZW1ib2R5IG9yIGJl IGNvbXBhcmFibGUgdG8gZW50ZXJwcmlzZSBzdGFuZGFyZHMsIkhhdmUgd2Ugc3VmZmljaWVudHkg ZGVmaW5lZCAiInN0YW5kYXJkcyIiPyINUkVRLTAwNSxVQy0wMCxNdXN0IGVpdGhlciByZXByZXNl bnQvZW1ib2R5IG9yIGJlIGNvbXBhcmFibGUgdG8gZW50ZXJwcmllc2UgcG9saWN5LCJIYXZlIHdl IHN1ZmZpY2llbnRseSBkZWZpbmVkICIicG9saWN5IiI/Ig1SRVEtMDA2LFVDLTAwLCJNdXN0IHN1 cHBvcnQgdHJpZ2dlci1iYXNlZCB3b3JrZmxvdyBpbml0aWF0aW9uIChpLmUuIG9wZXJhdG9yIHJl cXVlc3QsIGV2ZW50LWRyaXZlbikiLCJIYXZlIHdlIHN1ZmZpY2llbnRseSBkZWZpbmVkICIid29y a2Zsb3ciIiBvciBpcyB0aGVyZSBhIGJldHRlciB0ZXJtIHRvIHVzZT8iDVJFUS0wMDcsVUMtMDAs TXVzdCBzdXBwb3J0IHRhcmdldGluZyBvZiBhbiBlbmRwb2ludCwiVGhlIGJhc2UgY2FzZSBvZiBV Qy0wMCBkb2Vzbid0IHNlZW0gdG8gYWRkcmVzcyB0aGUgaW5ldml0YWJsZSBuZWVkIHRvIHRhcmdl dCBjbGFzc2VzIG9yIGxpc3RzIG9mIGVuZHBvaW50cywgd2hpY2ggd291bGQgbWVhbiB0YXJnZXRp bmcgbW9yZSB0aGFuIG9uZSBlbmRwb2ludC4iDVJFUS0wMDgsVUMtMDAsTXVzdCBzdXBwb3J0IGF1 dG9tYXRlZCBwb2xpY3kgc2VsZWN0aW9uIGJhc2VkIG9uIHRhcmdldGVkIGVuZHBvaW50LCJJIGFz c3VtZWQgdGhlICIiYXV0b21hdGVkIiIgYml0LiINUkVRLTAwOSxVQy0wMCxNdXN0IHN1cHBvcnQg b3B0aW1pemF0aW9uIG9mIGF0dHJpYnV0ZSBjb2xsZWN0aW9uLEkgYXNzdW1lZCB0aGF0IFVDLTAw IHdhcyBzcGVha2luZyB0byBvcHRpbWl6YXRpb24gb2YgYXR0cmlidXRlIGNvbGxlY3Rpb24uDVJF US0wMTAsVUMtMDAsTWF5IHN1cHBvcnQgdXNlIG9mIHByZXZpb3VzbHktY29sbGVjdGVkIGF0dHJp YnV0ZSBkYXRhLA1SRVEtMDExLFVDLTAwLE11c3Qgc3VwcG9ydCBtdWx0aXBsZSBzb3VyY2VzIG9m IHByZXZpb3VzbHktY29sbGVjdGVkIGF0dHJpYnV0ZSBkYXRhLA1SRVEtMDEyLFVDLTAwLE1heSBz dXBwb3J0IG11dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRoIHRhcmdldCwNUkVRLTAxMyxVQy0wMCxN YXkgc3VwcG9ydCBhdXRob3JpemF0aW9uIHdpdGggdGFyZ2V0LFdpdGggd2hhdCBpcyBzdWNoIGF1 dGhvcml6YXRpb24gY29uY2VybmVkPyAgSXMgaXQgdGhlIGF1dGhvcml6YXRpb24gb2YgdGhlIGNv bGxlY3Rpb24vZXZhbHVhdGlvbiByZXF1ZXN0IGFnYWluc3QgdGhlIHRhcmdldD8gIFRoZSB0cmln Z2VyIG1ha2luZyB0aGUgcmVxdWVzdD8gIFNvbWV0aGluZyBlbHNlPw1SRVEtMDE0LFVDLTAwLE11 c3Qgc3VwcG9ydCBjb21tdW5pY2F0aW9uIG9mIGNvbGxlY3RlZCBhdHRyaWJ1dGVzIHRvIGFuIGV2 YWx1YXRvcixTZWVtcyBhcmNoaXRlY3R1cmFsbHkgc3BlY2lmaWMNUkVRLTAxNSxVQy0wMCxNdXN0 IHN1cHBvcnQgY29tbXVuaWNhdGlvbiBvZiB0YXJnZXQgaWRlbnRpdHkgdG8gYW4gZXZhbHVhdG9y LFNlZW1zIGFyY2hpdGVjdHVyYWxseSBzcGVjaWZpYw1SRVEtMDE2LFVDLTAwLE11c3Qgc3VwcG9y dCBldmFsdWF0aW9uIG9mIGV4cGVjdGVkIGF0dHJpYnV0ZSB2YWx1ZSBhZ2FpbnN0IGFjdHVhbCBh dHRyaWJ1dGUgdmFsdWUsDVJFUS0wMTcsVUMtMDEsIk11c3QgcmVsYXRlICIiZ3VpZGUiIiBvciAi ImNoZWNrbGlzdCIiIHRvIGEgcGFydGljdWxhciBlbmRwb2ludCBkZXZpY2UgYW5kIHZlcnNpb24g b2Ygb3BlcmF0aW5nIHN5c3RlbS4iLCJJcyAiImd1aWRlIiIgb3IgIiJjaGVja2xpc3QiIiB0aGUg c2FtZSBhcyAiInN0YW5kYXJkIiIgYW5kL29yICIicG9saWN5IiI/ICBEbyB3ZSB3YW50IHRvIGNv dXBsZSBlbmRwb2ludCBkZXZpY2UgYW5kIG9wZXJhdGluZyBzeXN0ZW0gdmVyc2lvbj8iDVJFUS0w MTgsVUMtMDEsIk11c3QgcmVsYXRlICIiZ3VpZGUiIiBvciAiImNoZWNrbGlzdCIiIHRvIGEgcGFy dGljdWxhciBvcGVyYXRpbmcgc3lzdGVtIiwNUkVRLTAxOSxVQy0wMSxNdXN0IHJlbGF0ZSBjb25m aWd1cmF0aW9uIGd1aWRhbmNlIGJhc2VkIG9uIGVuZHBvaW50IGNvbmZpZ3VyYXRpb24sDVJFUS0w MjAsVUMtMDEsTXVzdCByZWxhdGUgY29uZmlndXJhdGlvbiBndWlkYW5jZSB0byBlbmRwb2ludCdz IGludGVuZGVkIHJvbGUsDVJFUS0wMjEsVUMtMDEsTXVzdCByZWxhdGUgY29uZmlndXJhdGlvbiBn dWlkYW5jZSB0byBoYXJkd2FyZSBwcmVzZW5jZSwNUkVRLTAyMixVQy0wMSxNdXN0IHJlbGF0ZSBj b25maWd1cmF0aW9uIGd1aWRhbmNlIHRvIGluc3RhbGxlZCBzb2Z0d2FyZSwNUkVRLTAyMyxVQy0w MSxQdWJsaWNseSBhdmFpbGFibGUgY29udGVudCByZXBvc2l0b3J5IGNhbiBiZSBwdWJsaXNoZWQg dG8gYnkgb3duZXIsIkknZCBsaWtlIHRvIGdldCBhIGJldHRlciBpZGVhIG9mIHdoYXQgaXMgbWVh bnQgYnkgIiJwdWJsaWNseSBhdmFpbGFibGUiIiBpbiB0aGlzIGNvbnRleHQuICBBcmUgd2UgdGFs a2luZyBhYm91dCBhIHRydWx5IHB1YmxpYyBzb3VyY2UsIG9yICIicHVibGljIiIgaW4gdGVybXMg b2YgZW50ZXJwcmlzZSBhdmFpbGFiaWxpdHkuIg1SRVEtMDI0LFVDLTAxLFB1YmxpY2x5IGF2YWls YWJsZSBjb250ZW50IHJlcG9zaXRvcnkgY2FuIGJlIHF1ZXJpZWQsDVJFUS0wMjUsVUMtMDEsUHVi bGljbHkgYXZhaWxhYmxlIGNvbnRlbnQgcmVwb3NpdG9yeSBjYW4gYmUgcHVibGlzaGVkIHRvIGJ5 IHRoaXJkLXBhcnRpZXMsVGhlIGxhbmd1YWdlIG9mIHRoZSBsYXN0IHNlbnRlbmNlIG9yIHNvIGFs bG93cyBvbmUgdG8gaW5mZXIgdGhpcy4NUkVRLTAyNixVQy0wMixNdXN0IHN1cHBvcnQgaGV0ZXJv Z2VuZW91cyBjb25maWd1cmF0aW9uIGl0ZW1zIC0gaS5lLiBhY3Jvc3MgdmVuZG9ycy90ZWNobm9s b2dpZXMsDVJFUS0wMjcsVUMtMDIsTXVzdCBwZXJmb3JtIHNvZnR3YXJlIGludmVudG9yeSwNUkVR LTAyOCxVQy0wMixNdXN0IHF1ZXJ5IGV4aXN0aW5nIGRhdGEgc3RvcmVzIGZvciBjb25maWd1cmF0 aW9uIGRhdGEsDVJFUS0wMjksVUMtMDIsTXVzdCBhY3RpdmVseSBjb2xsZWN0IGNvbmZpZ3VyYXRp b24gZGF0YSBmcm9tIGVuZHBvaW50cywNUkVRLTAzMCxVQy0wMixNdXN0IHRhcmdldCBlbmRwb2lu dHMgYmFzZWQgb24gdHlwZSBvciBjbGFzcywNUkVRLTAzMSxVQy0wMixNdXN0IHN1cHBvcnQgb3Jn YW5pemF0aW9uYWxseS1kZWZpbmVkIGVuZHBvaW50IGZ1bmN0aW9ucyBvciByb2xlcywNUkVRLTAz MixVQy0wMixNdXN0IHN1cHBvcnQgbG9jYWwgY2FjaGluZyBvZiBjb25maWd1cmF0aW9uIGNoZWNr bGlzdHMsDVJFUS0wMzMsVUMtMDIsTXVzdCBzdXBwb3J0IGNvbWJpbmF0aW9uIG9mIHF1ZXJ5aW5n IGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgYWN0aXZlIGNvbmZpZ3VyYXRpb24gZGF0 YSBjb2xsZWN0aW9uLA1SRVEtMDM0LFVDLTAyLERhdGEgY29sbGVjdGlvbiBtdXN0IGJlIGRyaXZl biBieSBlbmRwb2ludCByb2xlIGFuZCBzb2Z0d2FyZSBpbnZlbnRvcnkgb2YgdGhlIGVuZHBvaW50 LA1SRVEtMDM1LFVDLTAyLE11c3Qgc3VwcG9ydCBjb21wYXJpc29uIG9mIGFjdHVhbCBjb25maWd1 cmF0aW9uIHN0YXRlIGFnYWluc3QgZXhwZWN0ZWQgY29uZmlndXJhdGlvbiBzdGF0ZSwNUkVRLTAz NixVQy0wMixNdXN0IGlkZW50aWZ5IGNvbXBhcmlzb24gZGVmaWNpZW5jaWVzLA1SRVEtMDM3LFVD LTAyLE11c3QgcmVwb3J0IGNvbXBhcmlzb24gZGVmaWNpZW5jaWVzIHRvIGFwcHJvcHJpYXRlIGVu ZHBvaW50IG9wZXJhdG9ycywNUkVRLTAzOCxVQy0wMixWZW5kb3IgcmVwb3NpdG9yeSByZXF1aXJl bWVudCwNUkVRLTAzOSxVQy0wMixUaGlyZC1wYXJ0eSBwdWJsaWNhdGlvbiB0byB2ZW5kb3IgcmVw b3NpdG9yeSxUaGUgbGFuZ3VhZ2Ugb2YgdGhlIGxhc3Qgc2VudGVuY2Ugb3Igc28gYWxsb3dzIG9u ZSB0byBpbmZlciB0aGlzLg1SRVEtMDQwLFVDLTAzLE11c3Qgc3VwcG9ydCBlbmRwb2ludCB0YXJn ZXRpbmcgYmFzZWQgb24gZW5kcG9pbnQgZnVuY3Rpb24gKHJvbGUpLA1SRVEtMDQxLFVDLTAzLEJh c2VsaW5lIChjaGVja2xpc3QpIG11c3QgaWRlbnRpZnkgZXhwZWN0ZWQgaGFyZHdhcmUsDVJFUS0w NDIsVUMtMDMsQ2hlY2tsaXN0IG11c3QgaWRlbnRpZnkgZXhwZWN0ZWQgc29mdHdhcmUsDVJFUS0w NDMsVUMtMDMsQ2hlY2tsaXN0IG11c3QgaWRlbnRpZnkgZXhwZWN0ZWQgcGF0Y2hlcywNUkVRLTA0 NCxVQy0wMyxDaGVja2xpc3QgbXVzdCBpZGVudGlmeSBleHBlY3RlZCBzb2Z0d2FyZSBjb25maWd1 cmF0aW9uIHZhbHVlcywNUkVRLTA0NSxVQy0wMyxDaGVja2xpc3QgbXVzdCBiZSBhc3Nlc3NlZCBh Z2FpbnN0IGVuZHBvaW50cyB3aGVuZXZlciB0aGV5IGNvbm5lY3QgdG8gdGhlIG5ldHdvcmssDVJF US0wNDYsVUMtMDMsQ2hlY2tsaXN0IG11c3QgYmUgYXNzZXNzZWQgYXQgbGVhc3Qgb25jZSBhIGRh eSBkdXJpbmcgY29udGlndW91cyBuZXR3b3JrIGNvbm5lY3Rpb24sDVJFUS0wNDcsVUMtMDMsRGFp bHkgY2hlY2tzIG11c3QgYmUgcmVwb3J0ZWQsdG8gd2hvbT8NUkVRLTA0OCxVQy0wNCwiT24gbmV0 d29yayBjb25uZWN0aW9uLCBhcHByb3ByaWF0ZSBiYXNlbGluZSBtdXN0IGJlIGNvbW11bmljYXRl ZCB0byB0aGUgZW5kcG9pbnQgYmFzZWQgb24gaXRzIGxvY2F0aW9uIGluIHRoZSBuZXR3b3JrIiwN UkVRLTA0OSxVQy0wNCwiT24gbmV0d29yayBjb25uZWN0aW9uLCBhcHByb3ByaWF0ZSBiYXNlbGlu ZSBtdXN0IGJlIGNvbW11bmljYXRlZCB0byB0aGUgZW5kcG9pbnQgYmFzZWQgb24gZXhwZWN0ZWQg KGludGVuZGVkPykgcm9sZSIsDVJFUS0wNTAsVUMtMDQsIk9uIG5ldHdvcmsgY29ubmVjdGlvbiwg YXBwcm9wcmlhdGUgYmFzZWxpbmUgbXVzdCBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIGVuZHBvaW50 IGJhc2VkIG9uICIib3RoZXIgYXNzZXQgbWFuYWdlbWVudCBkYXRhIiIiLA1SRVEtMDUxLFVDLTA0 LCJNdXN0IGRlZmluZSBhbmQvb3IgdW5kZXJzdGFuZCAiImFzc2V0IG1hbmFnZW1lbnQgZGF0YSIi IiwNUkVRLTA1MixVQy0wNCwiTXVzdCBzdXBwb3J0IGNsYXNzaWZpY2F0aW9uIG9mIGVuZHBvaW50 cyBpbmNsdWRpbmc6IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUsIG1vYmlsZSwgY2xpZW50LCBhbmQg c2VydmVyLiIsRXh0ZW5zaWJsZT8gKGkuZS4gbm90IGxpbWl0ZWQgdG/JKQ1SRVEtMDUzLFVDLTA0 LEJhc2VsaW5lcyBtdXN0IGRlZmluZSBhbiBhcHByb3ZlZCBsaXN0IG9mIGhhcmR3YXJlLA1SRVEt MDU0LFVDLTA0LEJhc2VsaW5lcyBtdXN0IGRlZmluZSBhbiBhcHByb3ZlZCBsaXN0IG9mIHNvZnR3 YXJlLA1SRVEtMDU1LFVDLTA0LEJhc2VsaW5lcyBtdXN0IGRlZmluZSBhbiBhcHByb3ZlZCBsaXN0 IG9mIHJlcXVpcmVkIGNvbmZpZ3VyYXRpb25zLA1SRVEtMDU2LFVDLTA0LE11c3Qgc3VwcG9ydCBw b3N0dXJlIGNoYW5nZSBkZXRlY3Rpb24sDVJFUS0wNTcsVUMtMDQsIk9uIGRldGVjdGlvbiBvZiBw b3N0dXJlIGNoYW5nZSwgbXVzdCB1cGRhdGUgcG9zdHVyZSBpbmZvcm1hdGlvbiIsDVJFUS0wNTgs VUMtMDQsT24gcG9zdHVyZSBpbmZvcm1hdGlvbiB1cGRhdGUgbWF5IG5vdGlmaXkgb3BlcmF0b3Is DVJFUS0wNTksVUMtMDQsT24gcG9zdHVyZSBpbmZvcm1hdGlvbiB1cGRhdGUgbWF5IHBlcmZvcm0g YXV0b21hdGVkIGFjdGlvbixwcmUtZGV0ZXJtaW5lZCBvciBpbmZlcnJlZD8NUkVRLTA2MCxVQy0w NSxNdXN0IGNvbGxlY3QgcG9zdHVyZSBpbmZvcm1hdGlvbiBvbiBkZW1hbmQsDVJFUS0wNjEsVUMt MDUsTXVzdCBjYWNoZSBwcmV2aW91c2x5IGtub3duIHBvc3R1cmUgb2YgYW4gZW5kcG9pbnQsDVJF US0wNjIsVUMtMDUsTXVzdCBiZSBhYmxlIHRvIHF1ZXJ5IHRoZSBwcmV2aW91c2x5IGtub3duIHBv c3R1cmUgb2YgYW4gZW5kcG9pbnQsDVJFUS0wNjMsVUMtMDUsTXVzdCBiZSBhYmxlIHRvIGlkZW50 aWZ5IGZpbGUgcHJlc2VuY2UsDVJFUS0wNjQsVUMtMDcsTXVzdCBtYWludGFpbiBhIGRhdGFiYXNl IG9mIGVuZHBvaW50IHBvc3V0cmUsDVJFUS0wNjUsVUMtMDcsTXVzdCBlbmFibGUgcXVlcnkgb2Yg ZW5kcG9pbnQgcG9zdHVyZSBmcm9tIGRhdGFiYXNlIGZvciBzb2Z0d2FyZSBpbnZlbnRvcnksDVJF US0wNjYsVUMtMDcsTXVzdCBlbmFibGUgcXVlcnkgb2Ygc29mdHdhcmUgb24gZW5kcG9pbnRzIGZy b20gZGF0YWJhc2UsDVJFUS0wNjcsVUMtMDgsTXVzdCBvcGVyYXRlIG92ZXIgbG93LXNwZWVkIGNv bm5lY3Rpb25zLA1SRVEtMDY4LFVDLTA4LE11c3Qgb3BlYXJ0ZSBvdmVyIGhpZ2gtbGF0ZW5jeSBj b25uZWN0aW9ucywNUkVRLTA2OSxVQy0wOCxNdXN0IGFjY2VwdCByZWdpc3RyYXRpb24gb2YgaW50 ZXJtaXR0ZW50bHkgY29ubmVjdGVkIGVuZHBvaW50cywNUkVRLTA3MCxVQy0wOCxUaGUgZW5kcG9p bnQgcmVnaXN0cmFyIG11c3QgaW5pdGlhdGUgYXNzZXNzbWVudHMsDVJFUS0wNzEsVUMtMDgsVGhl IGVuZHBvaW50IHJlZ2lzdHJhciBtdXN0IHRyYWNrIGFzc2Vzc21lbnRzLA1SRVEtMDcyLFVDLTA4 LE11c3QgY29tcG9zZSBhIGNvbGxlY3Rpb24gcmVxdWVzdCBmb3Igbm9uLWNvbm5lY3RlZCBlbmRw b2ludHMsDVJFUS0wNzMsVUMtMDgsQ29sbGVjdGlvbiByZXF1ZXN0IG1heSBiZSBiYXNlZCBvbiB0 aW1lIHBlcmlvZCwNUkVRLTA3NCxVQy0wOCxDb2xsZWN0aW9uIHJlcXVlc3QgbWF5IGJlIGJhc2Vk IG9uIHZ1bG5lcmFiaWxpdHkgY291bnQgdGhyZXNob2xkLA1SRVEtMDc1LFVDLTA4LE11c3QgZW5h YmxlIGJhc2VsaW5lIGNvbXBvc2l0aW9uIChpLmUuIG1lcmdpbmcgb2YgYmFzZWxpbmVzIHRvIGVs aW1pbmF0ZSByZWR1bmRhbnQgYXNzZXNzbWVudCksDVJFUS0wNzYsVUMtMDgsTXVzdCBlbmFibGUg dnVsbmVyYWJpbGl0eS1vbmx5IGFzc2Vzc21lbnQsDVJFUS0wNzcsVUMtMDgsTWF5IGxldmVyYWdl IGRpc3BhcmF0ZSBDTURCcyAoaS5lLiBjZW50cmFsIGFuZCBsb2NhbCksDVJFUS0wNzgsVUMtMDgs TWF5IGxldmVyYWdlIGZyZXNobmVzcyBvZiBkYXRhIGluIHRoZSBkYXRhYmFzZSB0byBkZXRlcm1p bmUgaWYgbmV3IGFzc2Vzc21lbnQgaXMgcmVxdWlyZWQsDVJFUS0wNzksVUMtMDgsTXVzdCBlbmFi bGUgcXVlaW5nIGZvciBjb25uZWN0aXZpdHkgd2luZG93cywNUkVRLTA4MCxVQy0wOCxNdXN0IGVu YWJsZSBjb25uZWN0aXZpdHkgd2luZG93cyAoaS5lLiBpbnRlcm1pdHRlbnQgY29ubmVjdGlvbnMp LA1SRVEtMDgxLFVDLTA4LENvbGxlY3Rpb24gbWF5IGJlIHF1ZXVlZCBmb3IgcmV0dXJuIGNvbm5l Y3Rpdml0eSB3aW5kb3csDVJFUS0wODIsVUMtMDgsTXVzdCBjb21wYXJlIGVuZHBvaW50IGNoYXJh Y3RlcmlzdGljcyBhZ2FpbnN0IHdoYXQgaXMgcHJlc2VudGx5IGtub3duIGFib3V0IHRoZSBlbmRw b2ludCxUaGlzIGRpZmZlcnMgZnJvbSBhc3Nlc3NtZW50IGluIHRoYXQgdGhlIGV4cGVjdGVkIHZh bHVlIGNvbWVzIG5vdCBmcm9tIGEgZ3VpZGVsaW5lIGJ1dCBmcm9tIHRoZSBwcmV2aW91cyBhc3Nl c3NtZW50IGN5Y2xlLg1SRVEtMDgzLFVDLTA5LE11c3QgaWRlbnRpZnkgdnVsbmVyYWJsZSBlbmRw b2ludHMsDVJFUS0wODQsVUMtMDksTXVzdCBzdXBwb3J0IG5ldHdvcmsgYXdhcmVuZXNzIGZvciBl bmRwb2ludHMgKGkuZS4gd2hlcmUgdGhlIGVuZHBvaW50IGlzIGluIHRoZSBuZXR3b3JrIGFuZCBo b3cgYSBnaXZlbiB2dWxuZXJhYmlsaXR5IG1heSBiZSBtaXRpZ2F0ZWQgYnkgdGhhdCBsb2NhdGlv biksDVJFUS0wODUsVUMtMDksTXVzdCBzdXBwb3J0IHZ1bG5lcmFiaWxpdHkgc2V2ZXJpdHkgZXhw cmVzc2lvbiwNUkVRLTA4NixVQy0wOSxNdXN0IHN1cHBvcnQgdnVsbmVyYWJpbGl0eSBpbXBhY3Qg ZXhwcmVzc2lvbiwNUkVRLTA4NyxVQy0xMCwiTXVzdCBzdXBwb3J0IHVuZGVyc3RhbmRpbmcgb2Yg IiJpbmRpY2F0b3JzIG9mIGNvbXByb21pc2UiIiIsDVJFUS0wODgsVUMtMTAsTXVzdCBzdXBwb3J0 IGZpbGUgaGFzaGVzLA1SRVEtMDg5LFVDLTEwLE11c3Qgc3VwcG9ydCB1bmRlcnN0YWluZGluZyBv ZiBjb21tYW5kIGFuZCBjb250cm9sIHRyYWZmaWMsDVJFUS0wOTAsVUMtMTAsIk11c3Qgc3VwcG9y dCAiIm90aGVyIGluZGljYXRvcnMiIiIsQnkgYWRkaXRpb24gb3IgZXh0ZW5zaW9uLg1SRVEtMDkx LFVDLTExLE11c3Qgc3VwcG9ydCBibGFja2xpc3QgKGtub3duLWJhZCBJUCkgdW5kZXJzdGFuZGlu ZywNUkVRLTA5MixVQy0xMiwiTXVzdCBzdXBwb3J0ICIiZXh0ZXJuYWwgdHJpZ2dlcnMiIiBmb3Ig YXNzZXNzbWVudCIsV2hhdCB0eXBlcyBvZiBleHRlcm5hbCB0cmlnZ2Vycz8NUkVRLTA5MyxVQy0x MiwiTXVzdCBzdXBwb3J0IGRldGVybWluYXRpb24gb2YgIiJtaW5pbWFsIHNldCBvZiBlbmRwb2lu dCBhdHRyaWJ1dGVzIG5lZWRlZCB0byBwZXJmb3JtIGFzc2Vzc21lbnQiIiIsIk5PVEU6IFVDLTEy IGRlZmluaXRlbHkgZ2V0cyBpbnRvIHRoZSAiImhvdyIiLiINUkVRLTA5NCxVQy0xMyxNdXN0IHN1 cHBvcnQgZW5kcG9pbnQgYXNzZXNzbWVudCwNUkVRLTA5NSxVQy0xMyxNdXN0IHN1cHBvcnQgZXh0 ZXJuYWwgYXNzZXNzbWVudCByZXF1ZXN0cywNUkVRLTA5NixVQy0xMyxNdXN0IHN1cHBvcnQgY29s bGVjdGlvbiBvZiBWUE4gYXR0cmlidXRlcywNUkVRLTA5NyxVQy0xMyxNdXN0IHN1cHBvcnQgZXZh bHVhdGlvbiBvZiBWUE4gYXR0cmlidXRlcyBhZ2FpbnN0IGV4cGVjdGVkIHZhbHVlcywNUkVRLTA5 OCxVQy0xNCxNdXN0IHN1cHBvcnQgc2VncmVnYXRlZCBjb2xsZWN0aW9uIGFuZCBldmFsdWF0aW9u IGFuZCBjb250cm9sbGluZywiSSdtIG5vdCBzdXJlIEkgcmVhbGx5IHNlZSBhbnl0aGluZyB2ZXJ5 IG5ldyBpbiB0aGlzIHVzZSBjYXNlLCBlc3BlY2lhbGx5IGJlY2F1c2UgaXQgaXMgZXNzZW50aWFs bHkgYSBzdHJhdy1tYW4gZm9yIGFuIGFyY2hpdGVjdHVyYWwgcHJlZmVyZW5jZS4iDVJFUS0wOTks VUMtMTUsTXVzdCBzdXBwb3J0IGVudGVycHJpc2Utd2lkZSBhc3Nlc3NtZW50LA1SRVEtMTAwLFVD LTE1LE11c3Qgc3VwcG9ydCBlbmRwb2ludCBjbGFzc2lmaWNhdGlvbiwNUkVRLTEwMSxVQy0xNSxN dXN0IHN1cHBvcnQga25vd24gYXNzZXNzbWVudCBpbnN0cnVjdGlvbiByZXRyaWV2YWwgZnJvbSBj b21tb24gbG9jYXRpb24vc2VydmljZSwNUkVRLTEwMixVQy0xNSxNdXN0IHN1cHBvcnQgIGVudW1l cmF0aW9uIG9mIHZ1bG5lcmFiaWxpdHkgcmVzdWx0cywNUkVRLTEwMyxVQy0xNixNdXN0IHN1cHBv cnQgYXNzZXNzbWVudCBieSBjaGVjayBjbGFzc2lmaWNhdGlvbiAoaS5lLiBsb2NhbCBwcml2aWxl Z2UgZXNjYWxhdGlvbiB2dWxuZXJhYmlsaXR5KSwNUkVRLTEwNCxVQy0xNyxNdXN0IHN1cHBvcnQg aHVtYW4tcmVhZGFibGUgY29udGVudCBmb3IgYXNzZXNzbWVudC1yZWxhdGVkIG1hdGVyaWFscywN UkVRLTEwNSxVQy0xOCxNdXN0IHN1cHBvcnQgdnVsbmVyYWJpbGl0eSBjb250ZW50IG5vdGlmaWNh dGlvbiwNUkVRLTEwNixVQy0xOCxNdXN0IHN1cHBvcnQgdnVsbmVyYWJpbGl0eSBjb250ZW50IG5v dGlmaWNhdGlvbiByZWdpc3RyYXRpb24sDVJFUS0xMDcsVUMtMTgsTXVzdCBzdXBwb3J0IHZ1bG5l cmFiaWx0eS1jb250ZW50LW5vdGlmaWNhdGlvbi10cmlnZ2VyZWQgYXNzZXNzbWVudCw= --_002_05BCCEB107AF88469B9F99783D47C1D6065B3BD8CISEXCHANGE1msi_-- From dromasca@avaya.com Mon Oct 28 09:16:50 2013 Return-Path: <dromasca@avaya.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADBD11E8192 for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 09:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.288 X-Spam-Level: X-Spam-Status: No, score=-103.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 5HnFV3Ox4+Th for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 09:16:45 -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 AB05211E8170 for <sacm@ietf.org>; Mon, 28 Oct 2013 09:16:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAGAJmMblLGmAcV/2dsb2JhbABZgmYhOFS+ZIEmFm0HgicBAQMSKFEBFRUUQiYBBBsah2UBDJcUhEicegSPJINXgQ0DnmyLJYMmgio X-IronPort-AV: E=Sophos;i="4.93,586,1378872000"; d="scan'208";a="29358949" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Oct 2013 12:16:34 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Oct 2013 12:11:32 -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.03.0146.000; Mon, 28 Oct 2013 17:16:33 +0100 From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> To: "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: final agenda? Thread-Index: Ac7T+RDBHSSocYN7TCmJckilzXROVQ== Date: Mon, 28 Oct 2013 16:16:33 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291A7EE@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] final agenda? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Oct 2013 16:16:50 -0000 Today is the cut-off date for submitting the revised WG agendas for IETF-88= . Are there any changes and additions required relative to the agenda now a= vailable at https://datatracker.ietf.org/meeting/88/agenda/sacm/?=20 Thanks and Regards, Dan From ietfdbh@comcast.net Mon Oct 28 11:27:58 2013 Return-Path: <ietfdbh@comcast.net> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866F21E80BF for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 11:27:58 -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 vWbl5oo3Lbp1 for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 11:27:52 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACA621E80B7 for <sacm@ietf.org>; Mon, 28 Oct 2013 11:27:47 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta02.westchester.pa.mail.comcast.net with comcast id iboy1m00217dt5G51iTXxF; Mon, 28 Oct 2013 18:27:31 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta13.westchester.pa.mail.comcast.net with comcast id iiTX1m00V2yZEBF3ZiTXcX; Mon, 28 Oct 2013 18:27:31 +0000 From: "ietfdbh" <ietfdbh@comcast.net> To: "'Adam Montville'" <Adam.Montville@cisecurity.org>, <sacm@ietf.org> References: <05BCCEB107AF88469B9F99783D47C1D6065B3BD8@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065B3BD8@CISEXCHANGE1.msisac.org.local> Date: Mon, 28 Oct 2013 14:27:28 -0400 Message-ID: <03c601ced40b$5b79c9c0$126d5d40$@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: AQH9UsDAjKxP0hY/SoYO3EtaoX7Uy5mtWdPQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382984851; bh=yERVgRWP52Qu52dcnGaIASKiKLAuYz5r30E2V/dWhIE=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=P8nIfXc/DDIKy/ljZ8gJdZjdC2vRmyEYMewAd7SoZsz809c2ZY76qIRlaq6tRE6Fk LG5TENTGov4d5Fw5p0cdx8jGU30P6QheEexz6kP3s/owx/aCLF0jBqDXqjLmUf67AP MS12kshCcx2BWqOB2GAYdMugXnnP/aIuvZ90SV72Y74Gd4UlRkox/q+r3A8TE8XcXI yER4BTWXDMH2Hf1MQJWK1QN1ZNtVbxq7/sOmDLDa/qWn7sMTiNV2ZhHlMrYhxp9oTc tBi5BZjpHf8cmBFeQubr0oren7GwxoQNwPBgwjMRK2VCMuHpnX6zxZseupz1JYEmxa P6ZFaBmMQmDUg== Subject: Re: [sacm] Use Case Examination and Potential Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Oct 2013 18:27:58 -0000 Hi Adam, The venue for official discussion is the mailing list. I recommend discussing these on the mailing list rather than on a wiki. I would be careful about using MUST (or any RFC2119 keywords) in your list of requirements. We need to turn these into a document that will likely use RFC2119 keywords. I would recommend using complete sentences rather than just bulleted requirements. I would recommend using active voice rather than passive voice. The IESG often pushes back on passive voice; using active voice makes it clearer who must do what to be compliant to a standard. For example, WHO must collect attributes from a given endpoint? WHO must make attributes available for evaluation? Assume we standardize an architecture with endpoints, collectors, evaluators, data stores, and so on. Are all of these entities REQUIRED to make attributes available for evaluation? You seem to be making security optional, with "MAY support mutual authentication" etc. Please look at RFC3365, which specifies an IETF requirement for IETF standards. The IESG will consider the RFC3365 requirements when deciding whether to approve our documents. If we are going to talk about "policy", we should make sure our terminology is consistent with previous IETF publications related to policy. I'd start with RFC4949, since we are a SEC area WG. We should probably at least look at: RFC2753 - A Framework for Policy-based Admission Control RFC2768 - Network Policy and Services: A Report of a Workshop on Middleware RFC3060 - Policy Core Information Model -- Version 1 Specification RFC3198 - Terminology for Policy-Based Management RFC3571 - Framework Policy Information Base for Usage Feedback Policy-based management, of which at least part of SACM appears to be a subset, has been discussed in the IETF. There are a number of IETF standards and documents that resulted from prior efforts. A great deal of thought went into the work, and we should not ignore what has already been done. RFC3060 has a data model (and an inherent information model) for describing policies, including policies, groups, rules, properties of rules (enabled, priority, etc.), conditions, periods, actions, constraints, repository, associations, aggregations, components, and so on. They may not apply directly to the work we are doing, but the discussions we have been having certainly seem to be related to this prior work. RFC3571 has an information model for monitoring the usage of policies. This includes allowing one architectural entity (I'll be glad when we reach consensus on some terms we can use to talk about these things) To query another architectural entity (such as an evaluator) to determine which policies (evaluations) are supported, intervals for periodic reporting, actions, thresholds, etc. Much of the work on policy was a joint effort with people from DMTF. The resulting standards have not been widely adopted to my knowledge. But much of the work probably still deserves study so we don't try to reinvent the same wheels. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, October 28, 2013 12:07 PM > To: sacm@ietf.org > Subject: [sacm] Use Case Examination and Potential Requirements > > All: > > I've gone through the use cases and examined them for what I might initially > extract as requirements. In anticipation of some UC removal and addition, > I've given each UC a reference ID of the form UC-nn, where n is a digit from > 0-9. Similarly, each requirement is given an ID of the form REQ-nnn, again > where n is a digit from 0-9. > > I've attached the analysis in csv form to this note. Should it go up on a wiki > instead? > > Please note that my analysis is based on a fairly quick pass and makes no > attempt to weed out duplicate requirements. My intent in sharing this is to > kindle discussion and gain additional clarity on where we're going with this > work. > > Regards, > > Adam > > . . . From Adam.Montville@cisecurity.org Mon Oct 28 11:51:53 2013 Return-Path: <Adam.Montville@cisecurity.org> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6A721E80C2 for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 11:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4zgXcxtxtss for <sacm@ietfa.amsl.com>; Mon, 28 Oct 2013 11:51:47 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) by ietfa.amsl.com (Postfix) with ESMTP id E0DB321E80CB for <sacm@ietf.org>; Mon, 28 Oct 2013 11:51:46 -0700 (PDT) Received: from [216.82.242.179:50041] by server-2.bemta-8.messagelabs.com id 73/DB-29744-242BE625; Mon, 28 Oct 2013 18:51:46 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-2.tower-86.messagelabs.com!1382986305!43161717!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 25852 invoked from network); 28 Oct 2013 18:51:45 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-2.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 28 Oct 2013 18:51:45 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Mon, 28 Oct 2013 14:51:03 -0400 From: Adam Montville <Adam.Montville@cisecurity.org> To: ietfdbh <ietfdbh@comcast.net>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] Use Case Examination and Potential Requirements Thread-Index: Ac7T9yQpdS7qs1iOTQWQfu1O41i/QQANb4YAAAf8R5A= Date: Mon, 28 Oct 2013 18:51:04 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065B5CC9@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D6065B3BD8@CISEXCHANGE1.msisac.org.local> <03c601ced40b$5b79c9c0$126d5d40$@comcast.net> In-Reply-To: <03c601ced40b$5b79c9c0$126d5d40$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Use Case Examination and Potential Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Oct 2013 18:51:53 -0000 > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Monday, October 28, 2013 1:27 PM > To: Adam Montville; sacm@ietf.org > Subject: RE: [sacm] Use Case Examination and Potential Requirements >=20 > Hi Adam, >=20 > The venue for official discussion is the mailing list. > I recommend discussing these on the mailing list rather than on a wiki. >=20 My suggestion was where to put the csv file and not about where to conduct= a discussion. > I would be careful about using MUST (or any RFC2119 keywords) in your li= st > of requirements. > We need to turn these into a document that will likely use RFC2119 > keywords. >=20 All of the WG documents will use appropriate language. You'll note that I= did not claim to be compliant with RFC2119 in the requirements I (very qu= ickly) extracted from the use cases. > I would recommend using complete sentences rather than just bulleted > requirements. Did I mention I did this quickly? ;-) And, this work is not intended to b= e anything other than a discussion piece to assist the WG in extracting re= quirements from the Use Cases. > I would recommend using active voice rather than passive voice. > The IESG often pushes back on passive voice; using active voice makes it= > clearer who must do what to be compliant to a standard. > For example, WHO must collect attributes from a given endpoint? >=20 > WHO must make attributes available for evaluation? > Assume we standardize an architecture with endpoints, collectors, > evaluators, data stores, and so on. > Are all of these entities REQUIRED to make attributes available for > evaluation? Further refinement of terse, high-level requirements is needed to answer t= hese questions, and yours are exemplary of the very questions I hope the W= G can start discussing. >=20 > You seem to be making security optional, with "MAY support mutual > authentication" etc. Optional security wasn't my intent. Instead, I was (perhaps going against= my own rule-of-thumb) assuming that we'd not necessarily be concerned wit= h authentication - that's been done before so our system can probably leve= rage something that already exists. > Please look at RFC3365, which specifies an IETF requirement for IETF > standards. > The IESG will consider the RFC3365 requirements when deciding whether to= > approve our documents. >=20 > If we are going to talk about "policy", we should make sure our terminol= ogy is > consistent with previous IETF publications related to policy. > I'd start with RFC4949, since we are a SEC area WG. > We should probably at least look at: > RFC2753 - A Framework for Policy-based Admission Control > RFC2768 - Network Policy and Services: A Report of a Workshop on > Middleware > RFC3060 - Policy Core Information Model -- Version 1 Specification > RFC3198 - Terminology for Policy-Based Management > RFC3571 - Framework Policy Information Base for Usage Feedback >=20 I agree that the WG should use terminology in a consistent manner. This d= oes not, however, omit the possibility that our use of the term "policy" m= ay be different from any other IETF-related use. During one of our BoF se= ssions I presented an overview of our problem domain, which provided conte= xt for the level of policy we're talking about. =20 >=20 > Policy-based management, of which at least part of SACM appears to be a > subset, has been discussed in the IETF. > There are a number of IETF standards and documents that resulted from > prior efforts. > A great deal of thought went into the work, and we should not ignore wha= t > has already been done. > RFC3060 has a data model (and an inherent information model) for describ= ing > policies, including policies, groups, rules, properties of rules (enable= d, > priority, etc.), conditions, periods, actions, constraints, repository, > associations, aggregations, components, and so on. At this point, having not investigated all of the RFCs you've mentioned he= re, I believe we are talking about policy at one or two levels above that = addressed by RFC3060. > They may not apply directly to the work we are doing, but the discussion= s we > have been having certainly seem to be related to this prior work. > RFC3571 has an information model for monitoring the usage of policies. > This includes allowing one architectural entity (I'll be glad when we re= ach > consensus on some terms we can use to talk about these things) To query > another architectural entity (such as an evaluator) to determine which > policies (evaluations) are supported, intervals for periodic reporting, = actions, > thresholds, etc. >=20 > Much of the work on policy was a joint effort with people from DMTF. > The resulting standards have not been widely adopted to my knowledge. > But much of the work probably still deserves study so we don't try to > reinvent the same wheels. Agree. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Monday, October 28, 2013 12:07 PM > > To: sacm@ietf.org > > Subject: [sacm] Use Case Examination and Potential Requirements > > > > All: > > > > I've gone through the use cases and examined them for what I might > initially > > extract as requirements. In anticipation of some UC removal and > > addition, I've given each UC a reference ID of the form UC-nn, where n= > > is a digit > from > > 0-9. Similarly, each requirement is given an ID of the form REQ-nnn, > again > > where n is a digit from 0-9. > > > > I've attached the analysis in csv form to this note. Should it go up > > on a > wiki > > instead? > > > > Please note that my analysis is based on a fairly quick pass and makes= > > no attempt to weed out duplicate requirements. My intent in sharing > > this is > to > > kindle discussion and gain additional clarity on where we're going > > with > this > > work. > > > > Regards, > > > > Adam > > > > . . . >=20 >=20 > ... . . . From dromasca@avaya.com Thu Oct 31 05:24:13 2013 Return-Path: <dromasca@avaya.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C368211E8240 for <sacm@ietfa.amsl.com>; Thu, 31 Oct 2013 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.301 X-Spam-Level: X-Spam-Status: No, score=-103.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 L+2HJVLOgbeb for <sacm@ietfa.amsl.com>; Thu, 31 Oct 2013 05:24:07 -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 7D2E511E817D for <sacm@ietf.org>; Thu, 31 Oct 2013 05:24:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIGAMJKclKHCzI1/2dsb2JhbABZgmYhgQy/aoEkFm0HgicBAQMSKFEBFRUUQiYBBBsah2UBmi2ESJ0jjx6DWIEOA55viyWDJoIq X-IronPort-AV: E=Sophos;i="4.93,608,1378872000"; d="scan'208";a="34601861" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Oct 2013 08:24:04 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Oct 2013 08:14:20 -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.03.0146.000; Thu, 31 Oct 2013 13:24:00 +0100 From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> To: "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: preparing the wg meeting in Vancouver Thread-Index: Ac7WNBN8V5W6GSunTEmU2gRlf6p43Q== Date: Thu, 31 Oct 2013 12:24:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291ED03@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] preparing the wg meeting in Vancouver X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Oct 2013 12:24:13 -0000 In preparation for the next week WG meeting in Vancouver the chairs would l= ike to remind the participants the following:=20 - we need presentations to be submitted in advance so that they can be uplo= aded and made available for remote participants=20 - we need at least two minutes takers and one jabber scribe for the meeting= - please volunteer in advance Thanks and Regards, Adam and Dan From Kent_Landfield@mcafee.com Thu Oct 31 05:43:52 2013 Return-Path: <Kent_Landfield@mcafee.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F8821E805D for <sacm@ietfa.amsl.com>; Thu, 31 Oct 2013 05:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1-JwL9smB-z for <sacm@ietfa.amsl.com>; Thu, 31 Oct 2013 05:43:31 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9821F9FE9 for <sacm@ietf.org>; Thu, 31 Oct 2013 05:43:15 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 6da8_711f_4e2885f0_6cd1_4aea_aa51_74f111086b88; Thu, 31 Oct 2013 07:43:13 -0500 Received: from MIVEXAPP1N3.corp.nai.org (10.48.48.63) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Oct 2013 08:43:07 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.68]) by MIVEXAPP1N3.corp.nai.org ([169.254.3.153]) with mapi id 14.03.0158.001; Thu, 31 Oct 2013 08:43:07 -0400 From: <Kent_Landfield@McAfee.com> To: <dromasca@avaya.com>, <sacm@ietf.org> Thread-Topic: [sacm] preparing the wg meeting in Vancouver Thread-Index: AQHO1ja/FE+720jfwEeEnzzwJ89k8A== Date: Thu, 31 Oct 2013 12:43:06 +0000 Message-ID: <CE97BA6B.570F8%kent_landfield@mcafee.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1291ED03@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.48.48.241] Content-Type: multipart/alternative; boundary="_000_CE97BA6B570F8kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] preparing the wg meeting in Vancouver X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Oct 2013 12:43:52 -0000 --_000_CE97BA6B570F8kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I volunteer to be one of the minute takers. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com<http://www.mcafee.com/> From: <Romascanu>, "Dan (Dan)" <dromasca@avaya.com<mailto:dromasca@avaya.co= m>> Date: Thursday, October 31, 2013 7:24 AM To: "sacm@ietf.org<mailto:sacm@ietf.org>" <sacm@ietf.org<mailto:sacm@ietf.o= rg>> Subject: [sacm] preparing the wg meeting in Vancouver In preparation for the next week WG meeting in Vancouver the chairs would l= ike to remind the participants the following: - we need presentations to be submitted in advance so that they can be uplo= aded and made available for remote participants - we need at least two minutes takers and one jabber scribe for the meeting= - please volunteer in advance Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org<mailto:sacm@ietf.org> https://www.ietf.org/mailman/listinfo/sacm --_000_CE97BA6B570F8kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <D991B81AEB3DB741B68DE5DA6319997A@McAfee.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-fami= ly: 'Times New Roman', sans-serif; "> <div> <div> <div>I volunteer to be one of the minute takers.</div> <div><br> </div> <div><span class=3D"Apple-style-span" style=3D"color: rgb(96, 106, 113); fo= nt-family: Arial, Helvetica, sans-serif; font-size: 12px; border-spacing: 1= px; "><strong>Kent Landfield</strong><br> <br> <strong>McAfee | An Intel Company</strong><br> Direct: +1.972.963.7096 <br> Mobile: +1.817.637.8026<br> <strong>Web: </strong><a href=3D"http://www.mcafee.com/" style=3D"colo= r: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div> </div> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span><Romascanu>, "Dan = (Dan)" <<a href=3D"mailto:dromasca@avaya.com">dromasca@avaya.com</a= >><br> <span style=3D"font-weight:bold">Date: </span>Thursday, October 31, 2013 7:= 24 AM<br> <span style=3D"font-weight:bold">To: </span>"<a href=3D"mailto:sacm@ie= tf.org">sacm@ietf.org</a>" <<a href=3D"mailto:sacm@ietf.org">sacm@i= etf.org</a>><br> <span style=3D"font-weight:bold">Subject: </span>[sacm] preparing the wg me= eting in Vancouver<br> </div> <div><br> </div> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div> <div> <div><br> </div> <div>In preparation for the next week WG meeting in Vancouver the chairs wo= uld like to remind the participants the following: </div> <div><br> </div> <div>- we need presentations to be submitted in advance so that they can be= uploaded and made available for remote participants </div> <div>- we need at least two minutes takers and one jabber scribe for the me= eting - please volunteer in advance</div> <div><br> </div> <div>Thanks and Regards,</div> <div><br> </div> <div>Adam and Dan</div> <div><br> </div> <div><br> </div> <div><br> </div> <div>_______________________________________________</div> <div>sacm mailing list</div> <div><a href=3D"mailto:sacm@ietf.org">sacm@ietf.org</a></div> <div><a href=3D"https://www.ietf.org/mailman/listinfo/sacm">https://www.iet= f.org/mailman/listinfo/sacm</a></div> <div><br> </div> </div> </div> </blockquote> </span> </body> </html> --_000_CE97BA6B570F8kentlandfieldmcafeecom_-- From dromasca@avaya.com Thu Oct 31 05:44:15 2013 Return-Path: <dromasca@avaya.com> X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E5411E81D3 for <sacm@ietfa.amsl.com>; Thu, 31 Oct 2013 05:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY67sGsCwxj0 for <sacm@ietfa.amsl.com>; Thu, 31 Oct 2013 05:44:10 -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 185E511E816B for <sacm@ietf.org>; Thu, 31 Oct 2013 05:44:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhELADdPclLGmAcV/2dsb2JhbABWA4JDIyE4VKp/lGuBJBZ0giUBAQEBAwEBAQ8bHCUbAgEIBwYEAwEBAQsdBycLFAkIAQEEARIIGodlAQyefJ0JF48eDRMBDAoBEYMPgQ4Dnm+LJYMmgio X-IronPort-AV: E=Sophos;i="4.93,608,1378872000"; d="scan'208,217";a="34605310" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Oct 2013 08:44:03 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Oct 2013 08:38:51 -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.03.0146.000; Thu, 31 Oct 2013 13:44:02 +0100 From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> To: "Kent_Landfield@McAfee.com" <Kent_Landfield@McAfee.com>, "sacm@ietf.org" <sacm@ietf.org> Thread-Topic: [sacm] preparing the wg meeting in Vancouver Thread-Index: Ac7WNBN8V5W6GSunTEmU2gRlf6p43f//9JMA///vELA= Date: Thu, 31 Oct 2013 12:44:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291ED66@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1291ED03@AZ-FFEXMB04.global.avaya.com> <CE97BA6B.570F8%kent_landfield@mcafee.com> In-Reply-To: <CE97BA6B.570F8%kent_landfield@mcafee.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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1291ED66AZFFEXMB04globa_" MIME-Version: 1.0 Subject: Re: [sacm] preparing the wg meeting in Vancouver X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list <sacm.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sacm> List-Post: <mailto:sacm@ietf.org> List-Help: <mailto:sacm-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Oct 2013 12:44:15 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1291ED66AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Kent! Regards, Dan From: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] Sent: Thursday, October 31, 2013 2:43 PM To: Romascanu, Dan (Dan); sacm@ietf.org Subject: Re: [sacm] preparing the wg meeting in Vancouver I volunteer to be one of the minute takers. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com<http://www.mcafee.com/> From: <Romascanu>, "Dan (Dan)" <dromasca@avaya.com<mailto:dromasca@avaya.co= m>> Date: Thursday, October 31, 2013 7:24 AM To: "sacm@ietf.org<mailto:sacm@ietf.org>" <sacm@ietf.org<mailto:sacm@ietf.o= rg>> Subject: [sacm] preparing the wg meeting in Vancouver In preparation for the next week WG meeting in Vancouver the chairs would l= ike to remind the participants the following: - we need presentations to be submitted in advance so that they can be uplo= aded and made available for remote participants - we need at least two minutes takers and one jabber scribe for the meeting= - please volunteer in advance Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org<mailto:sacm@ietf.org> https://www.ietf.org/mailman/listinfo/sacm --_000_9904FB1B0159DA42B0B887B7FA8119CA1291ED66AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.apple-style-span {mso-style-name:apple-style-span;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks, Kent!<o:p></o:p><= /span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Regards,<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Dan<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Kent_Lan= dfield@McAfee.com [mailto:Kent_Landfield@McAfee.com] <br> <b>Sent:</b> Thursday, October 31, 2013 2:43 PM<br> <b>To:</b> Romascanu, Dan (Dan); sacm@ietf.org<br> <b>Subject:</b> Re: [sacm] preparing the wg meeting in Vancouver<o:p></o:p>= </span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">I volunteer to be one of= the minute takers.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><strong><span style=3D"font-size:9.0pt;font-family:&= quot;Arial","sans-serif";color:#606A71">Kent Landfield</span= ></strong><span style=3D"font-size:9.0pt;font-family:"Arial",&quo= t;sans-serif";color:#606A71"><br> <br> <strong><span style=3D"font-family:"Arial","sans-serif"= ">McAfee | An Intel Company</span></strong><br> <span class=3D"apple-style-span">Direct: +1.972.963.7096 </span><b= r> <span class=3D"apple-style-span">Mobile: +1.817.637.8026</span><br> <strong><span style=3D"font-family:"Arial","sans-serif"= ">Web: </span></strong><span class=3D"apple-style-span"><a href=3D"htt= p://www.mcafee.com/">www.mcafee.com</a></span></span><span style=3D"color:b= lack"><o:p></o:p></span></p> </div> </div> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif";color:black">From: </span></b><span style=3D"font-size:11.0pt;font-family:"Calibri",= "sans-serif";color:black"><Romascanu>, "Dan (Dan)"= ; <<a href=3D"mailto:dromasca@avaya.com">dromasca@avaya.com</a>><br> <b>Date: </b>Thursday, October 31, 2013 7:24 AM<br> <b>To: </b>"<a href=3D"mailto:sacm@ietf.org">sacm@ietf.org</a>" &= lt;<a href=3D"mailto:sacm@ietf.org">sacm@ietf.org</a>><br> <b>Subject: </b>[sacm] preparing the wg meeting in Vancouver<o:p></o:p></sp= an></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0i= n 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in" id=3D"MAC_OUTLOOK_ATTR= IBUTION_BLOCKQUOTE"> <div> <div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">In preparation for the n= ext week WG meeting in Vancouver the chairs would like to remind the partic= ipants the following: <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">- we need presentations = to be submitted in advance so that they can be uploaded and made available = for remote participants <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">- we need at least two m= inutes takers and one jabber scribe for the meeting - please volunteer in a= dvance<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">Thanks and Regards,<o:p>= </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">Adam and Dan<o:p></o:p><= /span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">________________________= _______________________<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">sacm mailing list<o:p></= o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><a href=3D"mailto:sacm@i= etf.org">sacm@ietf.org</a><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><a href=3D"https://www.i= etf.org/mailman/listinfo/sacm">https://www.ietf.org/mailman/listinfo/sacm</= a><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> </div> </div> </blockquote> </div> </div> </body> </html> --_000_9904FB1B0159DA42B0B887B7FA8119CA1291ED66AZFFEXMB04globa_--