From douglas.m.taylor@bt.com Wed Dec 5 08:05:23 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4521F8CA2 for ; Wed, 5 Dec 2012 08:05:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92wAcZ9aSudS for ; Wed, 5 Dec 2012 08:05:23 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AE93121F8BA9 for ; Wed, 5 Dec 2012 08:05:22 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 16:05:22 +0000 Received: from EVMHT31-UKDY.domain1.systemhost.net (193.113.31.41) by EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 16:05:21 +0000 Received: from EMV33-UKDY.domain1.systemhost.net ([169.254.2.191]) by EVMHT31-UKDY.domain1.systemhost.net ([193.113.31.41]) with mapi; Wed, 5 Dec 2012 16:05:21 +0000 From: To: Date: Wed, 5 Dec 2012 16:05:19 +0000 Thread-Topic: Poll on Scope Thread-Index: AQHNx/XVv5M1tTYN9EO3dZSXBes6m5gKcTBQgAADY1A= Message-ID: <99BE1B4FCEBDFC418F584DAE5EA8577B105F0F6468@EMV33-UKDY.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] FW: Poll on Scope X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:05:23 -0000 +1 Thanks, Doug Taylor, CISSP Security Tower Lead +1 972 830 8959 office +1 214 683 4789 mobile -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Wednesday, November 21, 2012 8:38 AM To: sacm@ietf.org Subject: [sacm] Poll on Scope Hello All, Question: Do you agree that narrowing the scope to UC1, while leaving the d= esign open to accommodate other use cases is the right approach for SACM? This poll will close in two weeks from today, December 5, 2012. =20 Reply with +1 if you agree or alternate options for considerations if you d= isagree. Thank you! Kathleen _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Wed Dec 5 13:12:48 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA5321F8C6E for ; Wed, 5 Dec 2012 13:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO6LTk03rOHe for ; Wed, 5 Dec 2012 13:12:43 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B99CE21F897C for ; Wed, 5 Dec 2012 13:12:43 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qB5LCaII029746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Dec 2012 16:12:36 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 5 Dec 2012 16:12:21 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qB5LCIWZ006493 for ; Wed, 5 Dec 2012 16:12:19 -0500 Received: from mx15a.corp.emc.com ([169.254.1.253]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Wed, 5 Dec 2012 16:12:18 -0500 From: "Moriarty, Kathleen" To: "sacm@ietf.org" Date: Wed, 5 Dec 2012 16:12:17 -0500 Thread-Topic: Poll on Scope Thread-Index: AQHNx/XVv5M1tTYN9EO3dZSXBes6m5gKcTBQgAADY1CAAFS4cA== Message-ID: References: <99BE1B4FCEBDFC418F584DAE5EA8577B105F0F6468@EMV33-UKDY.domain1.systemhost.net> In-Reply-To: <99BE1B4FCEBDFC418F584DAE5EA8577B105F0F6468@EMV33-UKDY.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Poll on Scope X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:12:48 -0000 Thank you all for taking the time to weigh in on the scope of effort for SA= CM. I believe we have shown clear consensus for targeting Use Case 1, whil= e ensuring the requirements include the ability to accommodate other use ca= ses and service provider models. The next step is to work through requirements. We did have several message= s posted to the list on requirements or questions about requirements. Adam= Montville had volunteered to collect the already posted requirements and s= ummarize them, so if that offer is still open, it could help to start that = conversation again. The requirements should be limited to those discussed = that apply to UC1 or are needed to ensure our scope enables other use cases= . We can expand and refine from there. Thank you! Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Wednesday, November 21, 2012 8:38 AM To: sacm@ietf.org Subject: [sacm] Poll on Scope Hello All, Question: Do you agree that narrowing the scope to UC1, while leaving the d= esign open to accommodate other use cases is the right approach for SACM? This poll will close in two weeks from today, December 5, 2012. =20 Reply with +1 if you agree or alternate options for considerations if you d= isagree. Thank you! Kathleen _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Wed Dec 5 13:56:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63F521F8CF2 for ; Wed, 5 Dec 2012 13:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRatcPYIl2sT for ; Wed, 5 Dec 2012 13:56:15 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id B826B21F8CEE for ; Wed, 5 Dec 2012 13:56:15 -0800 (PST) Received: from mail166-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE032.bigfish.com (10.236.130.95) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Dec 2012 21:56:15 +0000 Received: from mail166-co9 (localhost [127.0.0.1]) by mail166-co9-R.bigfish.com (Postfix) with ESMTP id 090991A00FC for ; Wed, 5 Dec 2012 21:56:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz98dI9371I9f17Rc85fh542I14ffIzz1de0h1202h1d1ah1d2ahzz1033IL17326ah110f33h8275bh8275dh18c673h18602ehz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631hbe3k1155h) Received: from mail166-co9 (localhost.localdomain [127.0.0.1]) by mail166-co9 (MessageSwitch) id 1354744572614778_3478; Wed, 5 Dec 2012 21:56:12 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.225]) by mail166-co9.bigfish.com (Postfix) with ESMTP id 93BAA18005A for ; Wed, 5 Dec 2012 21:56:12 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Dec 2012 21:56:09 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 11FB32321214 for ; Wed, 5 Dec 2012 13:45:07 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 6D8FA23211E9; Wed, 5 Dec 2012 13:45:06 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 5 Dec 2012 14:00:43 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Wed, 5 Dec 2012 13:56:07 -0800 From: Adam Montville To: "Moriarty, Kathleen" Thread-Topic: [sacm] Poll on Scope Thread-Index: AQHNx/XVv5M1tTYN9EO3dZSXBes6m5gKcTBQgAADY1CAAFS4cIAAk44A Date: Wed, 5 Dec 2012 21:56:06 +0000 Message-ID: <0494F32A-4F33-43D5-A1B3-1B3E37E827B8@tripwire.com> References: <99BE1B4FCEBDFC418F584DAE5EA8577B105F0F6468@EMV33-UKDY.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_0494F32A4F3343D5A1B31B3E37E827B8tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: b1e87865-fe86-47cf-b8ef-dfe07781117b X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] Poll on Scope X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:56:16 -0000 --_000_0494F32A4F3343D5A1B31B3E37E827B8tripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm in. On Dec 5, 2012, at 1:12 PM, "Moriarty, Kathleen" > wrote: Thank you all for taking the time to weigh in on the scope of effort for SA= CM. I believe we have shown clear consensus for targeting Use Case 1, whil= e ensuring the requirements include the ability to accommodate other use ca= ses and service provider models. The next step is to work through requirements. We did have several message= s posted to the list on requirements or questions about requirements. Adam= Montville had volunteered to collect the already posted requirements and s= ummarize them, so if that offer is still open, it could help to start that = conversation again. The requirements should be limited to those discussed = that apply to UC1 or are needed to ensure our scope enables other use cases= . We can expand and refine from there. Thank you! Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, November 21, 2012 8:38 AM To: sacm@ietf.org Subject: [sacm] Poll on Scope Hello All, Question: Do you agree that narrowing the scope to UC1, while leaving the d= esign open to accommodate other use cases is the right approach for SACM? This poll will close in two weeks from today, December 5, 2012. Reply with +1 if you agree or alternate options for considerations if you d= isagree. Thank you! Kathleen _______________________________________________ sacm mailing 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 Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_0494F32A4F3343D5A1B31B3E37E827B8tripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8437810B9EDC5543B952F3AC9EDFE5CF@tripwire.com> Content-Transfer-Encoding: quoted-printable I'm in.

On Dec 5, 2012, at 1:12 PM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com> wro= te:

Thank you all for taking the time to weigh in on = the scope of effort for SACM.  I believe we have shown clear consensus= for targeting Use Case 1, while ensuring the requirements include the abil= ity to accommodate other use cases and service provider models.

The next step is to work through requirements.  We did have several me= ssages posted to the list on requirements or questions about requirements. =  Adam Montville had volunteered to collect the already posted requirem= ents and summarize them, so if that offer is still open, it could help to start that conversation again.  The r= equirements should be limited to those discussed that apply to UC1 or are n= eeded to ensure our scope enables other use cases.  We can expand and = refine from there.

Thank you!
Kathleen


-----Original Message-----
From: sacm-bounces@ietf.org [m= ailto:sacm-bounces@ietf.org] On Beh= alf Of Moriarty, Kathleen
Sent: Wednesday, November 21, 2012 8:38 AM
To: sacm@ietf.org
Subject: [sacm] Poll on Scope

Hello All,

Question: Do you agree that narrowing the scope to UC1, while leaving the d= esign open to accommodate other use cases is the right approach for SACM?


This poll will close in two weeks from today, December 5, 2012.  
Reply with +1 if you agree or alternate options for considerations if y= ou disagree.

Thank you!
Kathleen
_______________________________________________
sacm mailing 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



Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_0494F32A4F3343D5A1B31B3E37E827B8tripwirecom_-- From Michael.Scanlin@netapp.com Wed Dec 5 08:13:08 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E4A21F8CDE for ; Wed, 5 Dec 2012 08:13:08 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TLzmEa86vqu for ; Wed, 5 Dec 2012 08:13:08 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3634C21F8CDD for ; Wed, 5 Dec 2012 08:13:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,221,1355126400"; d="scan'208";a="716245099" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Dec 2012 08:12:52 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qB5GCpYH000771 for ; Wed, 5 Dec 2012 08:12:51 -0800 (PST) Received: from SACEXCMBX03-PRD.hq.netapp.com ([169.254.5.174]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 08:12:51 -0800 From: "Scanlin, Mike" To: "sacm@ietf.org" Thread-Topic: Poll on Scope Thread-Index: AQHNx/XVv5M1tTYN9EO3dZSXBes6m5gKdr8w Date: Wed, 5 Dec 2012 16:12:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 06 Dec 2012 10:26:13 -0800 Subject: Re: [sacm] Poll on Scope X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:14:23 -0000 +1 Mike Mike Scanlin FCI Lead, NetApp US Public Sector scanlin@netapp.com 919.476.8578 - work 703.201.0842 - mobile -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Wednesday, November 21, 2012 9:38 AM To: sacm@ietf.org Subject: [sacm] Poll on Scope Hello All, Question: Do you agree that narrowing the scope to UC1, while leaving the d= esign open to accommodate other use cases is the right approach for SACM? This poll will close in two weeks from today, December 5, 2012. =20 Reply with +1 if you agree or alternate options for considerations if you d= isagree. Thank you! Kathleen _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Thu Dec 6 10:30:19 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D144D21F8773 for ; Thu, 6 Dec 2012 10:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eplsA4yPfLp for ; Thu, 6 Dec 2012 10:30:19 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9D21F875B for ; Thu, 6 Dec 2012 10:30:19 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 6 Dec 2012 13:29:50 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 6 Dec 2012 13:30:18 -0500 From: "Waltermire, David A." To: "Scanlin, Mike" , "sacm@ietf.org" Date: Thu, 6 Dec 2012 13:30:17 -0500 Thread-Topic: Poll on Scope Thread-Index: AQHNx/XVv5M1tTYN9EO3dZSXBes6m5gKdr8wgAG3xOA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] Poll on Scope X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:30:20 -0000 Mike, I just approved this moderated email from yesterday. My apologies, I have had limited connectivity until now. That's why this is coming across after Kathleen's email. Thanks for weighing in. Sincerely, Dave -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Scanlin, Mike Sent: Wednesday, December 05, 2012 11:13 AM To: sacm@ietf.org Subject: Re: [sacm] Poll on Scope +1 Mike Mike Scanlin FCI Lead, NetApp US Public Sector scanlin@netapp.com 919.476.8578 - work 703.201.0842 - mobile -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, November 21, 2012 9:38 AM To: sacm@ietf.org Subject: [sacm] Poll on Scope Hello All, Question: Do you agree that narrowing the scope to UC1, while leaving the design open to accommodate other use cases is the right approach for SACM? This poll will close in two weeks from today, December 5, 2012. Reply with +1 if you agree or alternate options for considerations if you disagree. Thank you! Kathleen _______________________________________________ sacm mailing 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 mrex@sap.com Mon Dec 10 16:50:23 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1AF21F86F9 for ; Mon, 10 Dec 2012 16:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxEXV+ed0i0A for ; Mon, 10 Dec 2012 16:50:22 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EB75321F86F5 for ; Mon, 10 Dec 2012 16:50:21 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qBB0oIvr007346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Dec 2012 01:50:19 +0100 (MET) In-Reply-To: <502005DB.80605@yaanatech.com> To: tony@yaanatech.com Date: Tue, 11 Dec 2012 01:50:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121211005018.A114C1A3EE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out X-Mailman-Approved-At: Mon, 10 Dec 2012 20:25:13 -0800 Cc: mrex@sap.com, Kent_Landfield@McAfee.com, sacm@ietf.org Subject: Re: [sacm] Legal aspects of System monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 00:50:23 -0000 Tony Rutkowski wrote: > > On 8/6/2012 1:21 PM, Martin Rex wrote: > > > > You have to realize that the problem here is not a security policy > > by itself. But trying to enforce compliance by constant electronic > > surveillance of end user systems will probably be illegal in most cases > > in Germany. > > Maybe this is getting off-topic, but could > you provide some citations to "German law." > These assertions seem like rather extreme > interpretations of something. It certainly does > not comport with the understanding of the > law that my German government colleagues > have. Maybe your German government colleagues should pay more attention to decisions of the Federal Administrative Court of Germany. There was a decision of the Federal Administrative Court of Germany last year that should provide a clue just how deep into illegal territory the monitoring of employee computing equipment is for an employer. Decision: BVerwG 2 A 11.08 vom 31.03.2011 Main Web Site: http://www.bundesverwaltungsgericht.de/weitere_Informationen/Information_and_Decisions__EN__g0.html Online Access to decisions for non-commercial use (in German language only) search for "BVerwG 2 A 11.08" http://www.bundesverwaltungsgericht.de/Entscheidungen/Entscheidungssuche_ny.html The relevant parts of that decision are paragraphs 17-19, basically re-iterating the Federal Constitutional Courts requirement for a existence of a formal statute law by the parlamentarian legislator to access non-public personal information. That the information was stored on the network storage of the employer, and that the use of that storage was officially strictly limited to business-related issues was found to be irrelevant!! This particular case was about an employee working for the German federal/governmental agency "Bundesnachrichtendienst (BND)" (which might be vaguely liked to the CIA among US government agencies). The employer (BND) had provided non-public network storage to the employee, and searched, probably among other locations, the contents of that network storage for indications of non-compliant publication of confidential information. Since there was no probably cause and no official criminal investigation when the search was performed, there was no applicable formal statue law authorizing this search, so the search was found to be a severe violation of the employees right of informational self-determination, based on the requirements established by the Federal Constitutional Court. After this decison, the employee sued his employer for "punitive damages" from this illegal search of his personal data. The employee was recently awarded EUR 3000,- by "Landgericht Berlin" http://www.berliner-zeitung.de/politik/bundesnachrichtendienst-bnd-muss-zahlen,10808018,21051542.html That latter decision about the awarded damages is still fresh, and could potentially be appealed by the employer. That decision also hasn't been published yet, but given that it is based on the very clear determination "BVerfG 2 A 11.08", it will be easy to justify such a payment of damages. It sides quite well with decisions of the Federal Labour court for severe violations of employee personality rights. -Martin From david.oliva@verizon.net Tue Dec 11 05:53:23 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCC721F8778 for ; Tue, 11 Dec 2012 05:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ysewbV95W1 for ; Tue, 11 Dec 2012 05:53:22 -0800 (PST) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by ietfa.amsl.com (Postfix) with ESMTP id 026F021F849F for ; Tue, 11 Dec 2012 05:53:21 -0800 (PST) Received: from vznit170164pub.verizon.net ([unknown] [192.168.1.3]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTP id <0MEV00EDUD8FSBY0@vms173009.mailsrvcs.net> for sacm@ietf.org; Tue, 11 Dec 2012 07:53:03 -0600 (CST) Received: from 96.241.166.234 ([96.241.166.234]) by vznit170164 (Verizon Webmail) with HTTP; Tue, 11 Dec 2012 07:53:03 -0600 (CST) Date: Tue, 11 Dec 2012 07:53:03 -0600 (CST) From: david.oliva@verizon.net To: mrex@sap.com, sacm@ietf.org Message-id: <1881776.88532.1355233983240.JavaMail.root@vznit170164> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [96.241.166.234] Subject: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 13:53:23 -0000
&nb= sp;Tony and all:
 
The monitoring which SACM perfo= rms is not about people's behavior.
The monitoring which SACM per= forms is of security mechanisms which are of interest to organiza= tions.
When organizations are expected by law to protect private = information, SACM monitors the security controls designed to protect privac= y laws.
 
David Oliva
 
&= nbsp;
On = 12/10/12, Martin Rex<mrex@sap.com> wrote:
&nb= sp;
Tony Rutkowski wrote:
>
> On 8/6/2012 1:21 PM, Martin Rex wrot= e:
> >
> > You have to realize that the problem here is n= ot a security policy
> > by itself. But trying to enforce complian= ce by constant electronic
> > surveillance of end user systems wil= l probably be illegal in most cases
> > in Germany.
>
>= ; Maybe this is getting off-topic, but could
> you provide some citat= ions to "German law."
> These assertions seem like rather extreme
= > interpretations of something. It certainly does
> not comport wi= th the understanding of the
> law that my German government colleague= s
> have.


Maybe your German government colleagues should p= ay more attention
to decisions of the Federal Administrative Court of Ge= rmany.


There was a decision of the Federal Administrative Court = of Germany
last year that should provide a clue just how deep into ille= gal
territory the monitoring of employee computing equipment is
for a= n employer.

Decision: BVerwG 2 A 11.08 vom 31.03.2011

Main We= b Site:
http://www.bundesverwaltungsgericht.de/weitere_Informationen/Info= rmation_and_Decisions__EN__g0.html

Online Access to decisions fo= r non-commercial use (in German language only)
search for "BVerwG 2 A 11= .08"
http://www.bun= desverwaltungsgericht.de/Entscheidungen/Entscheidungssuche_ny.html
<= BR>The relevant parts of that decision are paragraphs 17-19, basically
r= e-iterating the Federal Constitutional Courts requirement for a
existenc= e of a formal statute law by the parlamentarian legislator
to access non= -public personal information. That the information
was stored on the net= work storage of the employer, and that the use
of that storage was offic= ially strictly limited to business-related
issues was found to be irrele= vant!!


This particular case was about an employee working for th= e German
federal/governmental agency "Bundesnachrichtendienst (BND)"
= (which might be vaguely liked to the CIA among US government agencies).
= The employer (BND) had provided non-public network storage to the
employ= ee, and searched, probably among other locations, the contents
of that n= etwork storage for indications of non-compliant publication
of confident= ial information.

Since there was no probably cause and no official c= riminal investigation
when the search was performed, there was no applic= able formal statue law
authorizing this search, so the search was found = to be a severe violation
of the employees right of informational self-de= termination, based
on the requirements established by the Federal Consti= tutional Court.

After this decison, the employee sued his employer f= or "punitive damages"
from this illegal search of his personal data. The= employee was recently
awarded EUR 3000,- by "Landgericht Berlin"
= http://www.berliner-zeitung.de/politik/bundesnachrichtendienst-bnd-muss-zah= len,10808018,21051542.html

That latter decision about the awarde= d damages is still fresh, and
could potentially be appealed by the emplo= yer. That decision also
hasn't been published yet, but given that it is = based on the very
clear determination "BVerfG 2 A 11.08", it will be eas= y to justify
such a payment of damages. It sides quite well with decisio= ns
of the Federal Labour court for severe violations of employee
pers= onality rights.


-Martin
_____________________________________= __________
sacm mailing list
sacm@ietf.org
https://ww= w.ietf.org/mailman/listinfo/sacm
From amontville@tripwire.com Tue Dec 11 10:39:35 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E2621F8654 for ; Tue, 11 Dec 2012 10:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6dHzGpYTLTx for ; Tue, 11 Dec 2012 10:39:34 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id B772E21F8573 for ; Tue, 11 Dec 2012 10:39:33 -0800 (PST) Received: from mail148-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Dec 2012 18:39:32 +0000 Received: from mail148-va3 (localhost [127.0.0.1]) by mail148-va3-R.bigfish.com (Postfix) with ESMTP id A4ABB4C02FB for ; Tue, 11 Dec 2012 18:39:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzd6eahc85fh11fbIzz1de0h1202h1e76h1d1ah1d2ahzz17326ah8275bh8275dh18c673hz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail148-va3 (localhost.localdomain [127.0.0.1]) by mail148-va3 (MessageSwitch) id 1355251171292867_2878; Tue, 11 Dec 2012 18:39:31 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.235]) by mail148-va3.bigfish.com (Postfix) with ESMTP id 436983E0053 for ; Tue, 11 Dec 2012 18:39:31 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Dec 2012 18:39:28 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 888EA2321227 for ; Tue, 11 Dec 2012 10:27:56 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id E3AC323211F9 for ; Tue, 11 Dec 2012 10:27:55 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 11 Dec 2012 10:43:55 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Tue, 11 Dec 2012 10:39:26 -0800 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1A== Date: Tue, 11 Dec 2012 18:39:25 +0000 Message-ID: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_1ED269319A6F4405A9AC09361DE7DB0Atripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 667cfca9-a0c5-4fb1-9eef-204ac3ef0b56 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:39:35 -0000 --_000_1ED269319A6F4405A9AC09361DE7DB0Atripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ --_000_1ED269319A6F4405A9AC09361DE7DB0Atripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <377A335D59E17144ADF23D459A7B325A@tripwire.com> Content-Transfer-Encoding: quoted-printable All:

After trolling through some of the SACM mailing list, and reviewing SA= CM BoF minutes from IETF 85 and the current Use Case draft looking for requ= irements, and here's what I've pulled together so far: 

  • UC1 must provide coverage for enterprises of various sizes and include = support for assets delivered by third-parties
  • Asset representation/= identification should support those delivered by a given Service Provider (= SP)
  • Supporting data formats and/or protocols should support assessm= ent of SP-provided assets
  • Must provide a method of defining a targe= t system (asset identification; asset classification)
  • Must provide = a method of selecting acceptable state policy (test expression)
  • Mus= t provide a method of retrieving data collection instructions (activity cla= ss: configuration, patch, vulnerability, inventory; object representation; = state representation)
  • Must provide a method of expressing state col= lection values (collection language: technical, interrogative; object repre= sentation)
  • Must provide a method of comparing actual to expected st= ate values (test evaluation; test expression)
  • Must provide a protoc= ol for connecting to a content repository containing SACM content
  • M= ust provide a protocol for querying SACM content held in a content reposito= ry
  • Must provide a protocol of retrieving SACM content from a conten= t repository
  • Must provide a protocol for curating SACM content in a= content repository

In addition to the above, I would like to suggest that we take c= ertain requirements from CSIS 20 Critical Security Controls [1] und= er the following controls:

  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software=
  • Critical Control 3: Secure Configuration for Hardware and Software= on Mobile Devices, Laptops, Workstations, and Servers
  • Critical Con= trol 4: Continuous Vulnerability Assessment and Remediation
  • Critica= l Control 5: Malware Defenses
  • Critical Control 10: Secure Configura= tions for Network Devices such as Firewalls, Routers, and Switches


    • I have not yet parsed through each of the Critical Contr= ols, but anticipate more detailed requirements to come out of them.  I= emphasize that we will not be seeking to meet every requirement expressed = by a given Critical Control.  For example, we may not be in a position to express "authorizations" for soft= ware installed on an operating system in a given context.  But, Critic= al Control 2 does require accurate and meaningful asset identification (as = does Critical Control 1, for that matter), which is something with which we should be concerned.

    I have this Friday (12/14) dedicated to fleshing out these requirement= s.  If you have contributions to make, I respectfully request that you= do so before then.

    Regards,

    Adam


--_000_1ED269319A6F4405A9AC09361DE7DB0Atripwirecom_-- From dromasca@avaya.com Wed Dec 12 04:06:17 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867C821F89CC for ; Wed, 12 Dec 2012 04:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.334 X-Spam-Level: X-Spam-Status: No, score=-103.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO7sLHpP7PCl for ; Wed, 12 Dec 2012 04:06:11 -0800 (PST) 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 6394D21F89B1 for ; Wed, 12 Dec 2012 04:06:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIbQt1CHCzI1/2dsb2JhbABEgkkjgz+4ZnQWc4IeAQEBAQMBAQEPEQpBGwIBCA0EBAEBAQodAwICAiULFAkIAgQBEggah1wDDwELoXuKKpJii1dpFQyDDTJhA5wOijeCcoFjAR8e X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208,217";a="380267063" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Dec 2012 06:57:21 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Dec 2012 06:41:56 -0500 Received: from AZ-FFEXHC04.global.avaya.com (135.64.58.14) by DC-US1HCEX4.global.avaya.com (135.11.52.35) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 12 Dec 2012 07:06:08 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 07:06:07 -0500 From: "Romascanu, Dan (Dan)" To: "david.oliva@verizon.net" , "mrex@sap.com" , "sacm@ietf.org" Thread-Topic: [sacm] Mis-understanding of the term monitoring Thread-Index: AQHN16bpkqF5aIzM/EqeNo30P0Mlu5gVEeXg Date: Wed, 12 Dec 2012 12:06:06 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA03E3E6@AZ-FFEXMB04.global.avaya.com> References: <1881776.88532.1355233983240.JavaMail.root@vznit170164> In-Reply-To: <1881776.88532.1355233983240.JavaMail.root@vznit170164> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA03E3E6AZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 12:06:17 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA03E3E6AZFFEXMB04globala_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd2FzIGFsc28gY29uZnVzZWQgYnkgdGhlIHVzYWdlIG9mIHRoZSB0ZXJtIOKAmG1v bml0b3JpbmfigJkgYnkgdGhlIHRpbWUgSSB3YXMgaW50cm9kdWNpbmcgbXlzZWxmIGluIFNBQ00u IERhdmlkIE9saXZhIOKAmHMgb2JzZXJ2YXRpb24gaXMgY29ycmVjdCwg4oCYbW9uaXRvcmluZ+KA mSBhcyB1c2VkIGluIFNBQ00gaXMgYWJvdXQgYXVkaXRpbmcgdGhlIHNlY3VyaXR5IGNvbnRyb2xz IGFuZCBtZWNoYW5pc21zIChhbHRob3VnaCB1c2luZyDigJhhdWRpdGluZ+KAmSBpbnN0ZWFkIGNv dWxkIGNyZWF0ZSBvdGhlciBjb25mdXNpb25zKQ0KDQpSZWdhcmRzLA0KDQpEYW4NCg0KDQpGcm9t OiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldA0KU2VudDogVHVlc2RheSwgRGVjZW1i ZXIgMTEsIDIwMTIgMzo1MyBQTQ0KVG86IG1yZXhAc2FwLmNvbTsgc2FjbUBpZXRmLm9yZw0KU3Vi amVjdDogW3NhY21dIE1pcy11bmRlcnN0YW5kaW5nIG9mIHRoZSB0ZXJtIG1vbml0b3JpbmcNCg0K IFRvbnkgYW5kIGFsbDoNCg0KVGhlIG1vbml0b3Jpbmcgd2hpY2ggU0FDTSBwZXJmb3JtcyBpcyBu b3QgYWJvdXQgcGVvcGxlJ3MgYmVoYXZpb3IuDQpUaGUgbW9uaXRvcmluZyB3aGljaCBTQUNNIHBl cmZvcm1zIGlzIG9mIHNlY3VyaXR5IG1lY2hhbmlzbXMgd2hpY2ggYXJlIG9mIGludGVyZXN0IHRv IG9yZ2FuaXphdGlvbnMuDQpXaGVuIG9yZ2FuaXphdGlvbnMgYXJlIGV4cGVjdGVkIGJ5IGxhdyB0 byBwcm90ZWN0IHByaXZhdGUgaW5mb3JtYXRpb24sIFNBQ00gbW9uaXRvcnMgdGhlIHNlY3VyaXR5 IGNvbnRyb2xzIGRlc2lnbmVkIHRvIHByb3RlY3QgcHJpdmFjeSBsYXdzLg0KDQpEYXZpZCBPbGl2 YQ0KDQoNCk9uIDEyLzEwLzEyLCBNYXJ0aW4gUmV4PG1yZXhAc2FwLmNvbTxtYWlsdG86bXJleEBz YXAuY29tPj4gd3JvdGU6DQoNClRvbnkgUnV0a293c2tpIHdyb3RlOg0KPg0KPiBPbiA4LzYvMjAx MiAxOjIxIFBNLCBNYXJ0aW4gUmV4IHdyb3RlOg0KPiA+DQo+ID4gWW91IGhhdmUgdG8gcmVhbGl6 ZSB0aGF0IHRoZSBwcm9ibGVtIGhlcmUgaXMgbm90IGEgc2VjdXJpdHkgcG9saWN5DQo+ID4gYnkg aXRzZWxmLiBCdXQgdHJ5aW5nIHRvIGVuZm9yY2UgY29tcGxpYW5jZSBieSBjb25zdGFudCBlbGVj dHJvbmljDQo+ID4gc3VydmVpbGxhbmNlIG9mIGVuZCB1c2VyIHN5c3RlbXMgd2lsbCBwcm9iYWJs eSBiZSBpbGxlZ2FsIGluIG1vc3QgY2FzZXMNCj4gPiBpbiBHZXJtYW55Lg0KPg0KPiBNYXliZSB0 aGlzIGlzIGdldHRpbmcgb2ZmLXRvcGljLCBidXQgY291bGQNCj4geW91IHByb3ZpZGUgc29tZSBj aXRhdGlvbnMgdG8gIkdlcm1hbiBsYXcuIg0KPiBUaGVzZSBhc3NlcnRpb25zIHNlZW0gbGlrZSBy YXRoZXIgZXh0cmVtZQ0KPiBpbnRlcnByZXRhdGlvbnMgb2Ygc29tZXRoaW5nLiBJdCBjZXJ0YWlu bHkgZG9lcw0KPiBub3QgY29tcG9ydCB3aXRoIHRoZSB1bmRlcnN0YW5kaW5nIG9mIHRoZQ0KPiBs YXcgdGhhdCBteSBHZXJtYW4gZ292ZXJubWVudCBjb2xsZWFndWVzDQo+IGhhdmUuDQoNCg0KTWF5 YmUgeW91ciBHZXJtYW4gZ292ZXJubWVudCBjb2xsZWFndWVzIHNob3VsZCBwYXkgbW9yZSBhdHRl bnRpb24NCnRvIGRlY2lzaW9ucyBvZiB0aGUgRmVkZXJhbCBBZG1pbmlzdHJhdGl2ZSBDb3VydCBv ZiBHZXJtYW55Lg0KDQoNClRoZXJlIHdhcyBhIGRlY2lzaW9uIG9mIHRoZSBGZWRlcmFsIEFkbWlu aXN0cmF0aXZlIENvdXJ0IG9mIEdlcm1hbnkNCmxhc3QgeWVhciB0aGF0IHNob3VsZCBwcm92aWRl IGEgY2x1ZSBqdXN0IGhvdyBkZWVwIGludG8gaWxsZWdhbA0KdGVycml0b3J5IHRoZSBtb25pdG9y aW5nIG9mIGVtcGxveWVlIGNvbXB1dGluZyBlcXVpcG1lbnQgaXMNCmZvciBhbiBlbXBsb3llci4N Cg0KRGVjaXNpb246IEJWZXJ3RyAyIEEgMTEuMDggdm9tIDMxLjAzLjIwMTENCg0KTWFpbiBXZWIg U2l0ZToNCmh0dHA6Ly93d3cuYnVuZGVzdmVyd2FsdHVuZ3NnZXJpY2h0LmRlL3dlaXRlcmVfSW5m b3JtYXRpb25lbi9JbmZvcm1hdGlvbl9hbmRfRGVjaXNpb25zX19FTl9fZzAuaHRtbA0KDQpPbmxp bmUgQWNjZXNzIHRvIGRlY2lzaW9ucyBmb3Igbm9uLWNvbW1lcmNpYWwgdXNlIChpbiBHZXJtYW4g bGFuZ3VhZ2Ugb25seSkNCnNlYXJjaCBmb3IgIkJWZXJ3RyAyIEEgMTEuMDgiDQpodHRwOi8vd3d3 LmJ1bmRlc3ZlcndhbHR1bmdzZ2VyaWNodC5kZS9FbnRzY2hlaWR1bmdlbi9FbnRzY2hlaWR1bmdz c3VjaGVfbnkuaHRtbA0KDQpUaGUgcmVsZXZhbnQgcGFydHMgb2YgdGhhdCBkZWNpc2lvbiBhcmUg cGFyYWdyYXBocyAxNy0xOSwgYmFzaWNhbGx5DQpyZS1pdGVyYXRpbmcgdGhlIEZlZGVyYWwgQ29u c3RpdHV0aW9uYWwgQ291cnRzIHJlcXVpcmVtZW50IGZvciBhDQpleGlzdGVuY2Ugb2YgYSBmb3Jt YWwgc3RhdHV0ZSBsYXcgYnkgdGhlIHBhcmxhbWVudGFyaWFuIGxlZ2lzbGF0b3INCnRvIGFjY2Vz cyBub24tcHVibGljIHBlcnNvbmFsIGluZm9ybWF0aW9uLiBUaGF0IHRoZSBpbmZvcm1hdGlvbg0K d2FzIHN0b3JlZCBvbiB0aGUgbmV0d29yayBzdG9yYWdlIG9mIHRoZSBlbXBsb3llciwgYW5kIHRo YXQgdGhlIHVzZQ0Kb2YgdGhhdCBzdG9yYWdlIHdhcyBvZmZpY2lhbGx5IHN0cmljdGx5IGxpbWl0 ZWQgdG8gYnVzaW5lc3MtcmVsYXRlZA0KaXNzdWVzIHdhcyBmb3VuZCB0byBiZSBpcnJlbGV2YW50 ISENCg0KDQpUaGlzIHBhcnRpY3VsYXIgY2FzZSB3YXMgYWJvdXQgYW4gZW1wbG95ZWUgd29ya2lu ZyBmb3IgdGhlIEdlcm1hbg0KZmVkZXJhbC9nb3Zlcm5tZW50YWwgYWdlbmN5ICJCdW5kZXNuYWNo cmljaHRlbmRpZW5zdCAoQk5EKSINCih3aGljaCBtaWdodCBiZSB2YWd1ZWx5IGxpa2VkIHRvIHRo ZSBDSUEgYW1vbmcgVVMgZ292ZXJubWVudCBhZ2VuY2llcykuDQpUaGUgZW1wbG95ZXIgKEJORCkg aGFkIHByb3ZpZGVkIG5vbi1wdWJsaWMgbmV0d29yayBzdG9yYWdlIHRvIHRoZQ0KZW1wbG95ZWUs IGFuZCBzZWFyY2hlZCwgcHJvYmFibHkgYW1vbmcgb3RoZXIgbG9jYXRpb25zLCB0aGUgY29udGVu dHMNCm9mIHRoYXQgbmV0d29yayBzdG9yYWdlIGZvciBpbmRpY2F0aW9ucyBvZiBub24tY29tcGxp YW50IHB1YmxpY2F0aW9uDQpvZiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uDQoNClNpbmNlIHRo ZXJlIHdhcyBubyBwcm9iYWJseSBjYXVzZSBhbmQgbm8gb2ZmaWNpYWwgY3JpbWluYWwgaW52ZXN0 aWdhdGlvbg0Kd2hlbiB0aGUgc2VhcmNoIHdhcyBwZXJmb3JtZWQsIHRoZXJlIHdhcyBubyBhcHBs aWNhYmxlIGZvcm1hbCBzdGF0dWUgbGF3DQphdXRob3JpemluZyB0aGlzIHNlYXJjaCwgc28gdGhl IHNlYXJjaCB3YXMgZm91bmQgdG8gYmUgYSBzZXZlcmUgdmlvbGF0aW9uDQpvZiB0aGUgZW1wbG95 ZWVzIHJpZ2h0IG9mIGluZm9ybWF0aW9uYWwgc2VsZi1kZXRlcm1pbmF0aW9uLCBiYXNlZA0Kb24g dGhlIHJlcXVpcmVtZW50cyBlc3RhYmxpc2hlZCBieSB0aGUgRmVkZXJhbCBDb25zdGl0dXRpb25h bCBDb3VydC4NCg0KQWZ0ZXIgdGhpcyBkZWNpc29uLCB0aGUgZW1wbG95ZWUgc3VlZCBoaXMgZW1w bG95ZXIgZm9yICJwdW5pdGl2ZSBkYW1hZ2VzIg0KZnJvbSB0aGlzIGlsbGVnYWwgc2VhcmNoIG9m IGhpcyBwZXJzb25hbCBkYXRhLiBUaGUgZW1wbG95ZWUgd2FzIHJlY2VudGx5DQphd2FyZGVkIEVV UiAzMDAwLC0gYnkgIkxhbmRnZXJpY2h0IEJlcmxpbiINCg0KaHR0cDovL3d3dy5iZXJsaW5lci16 ZWl0dW5nLmRlL3BvbGl0aWsvYnVuZGVzbmFjaHJpY2h0ZW5kaWVuc3QtYm5kLW11c3MtemFobGVu LDEwODA4MDE4LDIxMDUxNTQyLmh0bWwNCg0KVGhhdCBsYXR0ZXIgZGVjaXNpb24gYWJvdXQgdGhl IGF3YXJkZWQgZGFtYWdlcyBpcyBzdGlsbCBmcmVzaCwgYW5kDQpjb3VsZCBwb3RlbnRpYWxseSBi ZSBhcHBlYWxlZCBieSB0aGUgZW1wbG95ZXIuIFRoYXQgZGVjaXNpb24gYWxzbw0KaGFzbid0IGJl ZW4gcHVibGlzaGVkIHlldCwgYnV0IGdpdmVuIHRoYXQgaXQgaXMgYmFzZWQgb24gdGhlIHZlcnkN CmNsZWFyIGRldGVybWluYXRpb24gIkJWZXJmRyAyIEEgMTEuMDgiLCBpdCB3aWxsIGJlIGVhc3kg dG8ganVzdGlmeQ0Kc3VjaCBhIHBheW1lbnQgb2YgZGFtYWdlcy4gSXQgc2lkZXMgcXVpdGUgd2Vs bCB3aXRoIGRlY2lzaW9ucw0Kb2YgdGhlIEZlZGVyYWwgTGFib3VyIGNvdXJ0IGZvciBzZXZlcmUg dmlvbGF0aW9ucyBvZiBlbXBsb3llZQ0KcGVyc29uYWxpdHkgcmlnaHRzLg0KDQoNCi1NYXJ0aW4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWNtIG1h aWxpbmcgbGlzdA0Kc2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0K --_000_9904FB1B0159DA42B0B887B7FA8119CA03E3E6AZFFEXMB04globala_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIHdhcyBhbHNvIGNvbmZ1c2VkIGJ5IHRoZSB1c2FnZSBvZiB0 aGUgdGVybSDigJhtb25pdG9yaW5n4oCZIGJ5IHRoZSB0aW1lIEkgd2FzIGludHJvZHVjaW5nIG15 c2VsZiBpbiBTQUNNLiBEYXZpZCBPbGl2YSDigJhzIG9ic2VydmF0aW9uIGlzIGNvcnJlY3QsIOKA mG1vbml0b3JpbmfigJkNCiBhcyB1c2VkIGluIFNBQ00gaXMgYWJvdXQgYXVkaXRpbmcgdGhlIHNl Y3VyaXR5IGNvbnRyb2xzIGFuZCBtZWNoYW5pc21zIChhbHRob3VnaCB1c2luZyDigJhhdWRpdGlu Z+KAmSBpbnN0ZWFkIGNvdWxkIGNyZWF0ZSBvdGhlciBjb25mdXNpb25zKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2FjbS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5kYXZpZC5vbGl2YUB2ZXJpem9uLm5ldDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBE ZWNlbWJlciAxMSwgMjAxMiAzOjUzIFBNPGJyPg0KPGI+VG86PC9iPiBtcmV4QHNhcC5jb207IHNh Y21AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NhY21dIE1pcy11bmRlcnN0YW5kaW5n IG9mIHRoZSB0ZXJtIG1vbml0b3Jpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7VG9ueSBhbmQgYWxsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGUgbW9uaXRvcmluZyB3aGljaCBTQUNNIHBlcmZvcm1zIGlzIG5vdCBhYm91dCBwZW9wbGUn cyBiZWhhdmlvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBt b25pdG9yaW5nIHdoaWNoIFNBQ00gcGVyZm9ybXMgaXMmbmJzcDtvZiBzZWN1cml0eSBtZWNoYW5p c21zIHdoaWNoIGFyZSBvZiBpbnRlcmVzdCB0byZuYnNwO29yZ2FuaXphdGlvbnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaGVuIG9yZ2FuaXphdGlvbnMgYXJlIGV4 cGVjdGVkIGJ5IGxhdyB0byBwcm90ZWN0IHByaXZhdGUgaW5mb3JtYXRpb24sIFNBQ00gbW9uaXRv cnMgdGhlIHNlY3VyaXR5IGNvbnRyb2xzIGRlc2lnbmVkIHRvIHByb3RlY3QgcHJpdmFjeSBsYXdz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EYXZpZCBPbGl2YTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ T24gMTIvMTAvMTIsIE1hcnRpbiBSZXgmbHQ7PGEgaHJlZj0ibWFpbHRvOm1yZXhAc2FwLmNvbSI+ bXJleEBzYXAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Ub255IFJ1 dGtvd3NraSB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiA4LzYvMjAxMiAxOjIxIFBNLCBN YXJ0aW4gUmV4IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZb3UgaGF2ZSB0 byByZWFsaXplIHRoYXQgdGhlIHByb2JsZW0gaGVyZSBpcyBub3QgYSBzZWN1cml0eSBwb2xpY3k8 YnI+DQomZ3Q7ICZndDsgYnkgaXRzZWxmLiBCdXQgdHJ5aW5nIHRvIGVuZm9yY2UgY29tcGxpYW5j ZSBieSBjb25zdGFudCBlbGVjdHJvbmljPGJyPg0KJmd0OyAmZ3Q7IHN1cnZlaWxsYW5jZSBvZiBl bmQgdXNlciBzeXN0ZW1zIHdpbGwgcHJvYmFibHkgYmUgaWxsZWdhbCBpbiBtb3N0IGNhc2VzPGJy Pg0KJmd0OyAmZ3Q7IGluIEdlcm1hbnkuPGJyPg0KJmd0Ozxicj4NCiZndDsgTWF5YmUgdGhpcyBp cyBnZXR0aW5nIG9mZi10b3BpYywgYnV0IGNvdWxkPGJyPg0KJmd0OyB5b3UgcHJvdmlkZSBzb21l IGNpdGF0aW9ucyB0byAmcXVvdDtHZXJtYW4gbGF3LiZxdW90Ozxicj4NCiZndDsgVGhlc2UgYXNz ZXJ0aW9ucyBzZWVtIGxpa2UgcmF0aGVyIGV4dHJlbWU8YnI+DQomZ3Q7IGludGVycHJldGF0aW9u cyBvZiBzb21ldGhpbmcuIEl0IGNlcnRhaW5seSBkb2VzPGJyPg0KJmd0OyBub3QgY29tcG9ydCB3 aXRoIHRoZSB1bmRlcnN0YW5kaW5nIG9mIHRoZTxicj4NCiZndDsgbGF3IHRoYXQgbXkgR2VybWFu IGdvdmVybm1lbnQgY29sbGVhZ3Vlczxicj4NCiZndDsgaGF2ZS48YnI+DQo8YnI+DQo8YnI+DQpN YXliZSB5b3VyIEdlcm1hbiBnb3Zlcm5tZW50IGNvbGxlYWd1ZXMgc2hvdWxkIHBheSBtb3JlIGF0 dGVudGlvbjxicj4NCnRvIGRlY2lzaW9ucyBvZiB0aGUgRmVkZXJhbCBBZG1pbmlzdHJhdGl2ZSBD b3VydCBvZiBHZXJtYW55Ljxicj4NCjxicj4NCjxicj4NClRoZXJlIHdhcyBhIGRlY2lzaW9uIG9m IHRoZSBGZWRlcmFsIEFkbWluaXN0cmF0aXZlIENvdXJ0IG9mIEdlcm1hbnkgPGJyPg0KbGFzdCB5 ZWFyIHRoYXQgc2hvdWxkIHByb3ZpZGUgYSBjbHVlIGp1c3QgaG93IGRlZXAgaW50byBpbGxlZ2Fs PGJyPg0KdGVycml0b3J5IHRoZSBtb25pdG9yaW5nIG9mIGVtcGxveWVlIGNvbXB1dGluZyBlcXVp cG1lbnQgaXM8YnI+DQpmb3IgYW4gZW1wbG95ZXIuPGJyPg0KPGJyPg0KRGVjaXNpb246IEJWZXJ3 RyAyIEEgMTEuMDggdm9tIDMxLjAzLjIwMTE8YnI+DQo8YnI+DQpNYWluIFdlYiBTaXRlOjxicj4N CjxhIGhyZWY9Imh0dHA6Ly93d3cuYnVuZGVzdmVyd2FsdHVuZ3NnZXJpY2h0LmRlL3dlaXRlcmVf SW5mb3JtYXRpb25lbi9JbmZvcm1hdGlvbl9hbmRfRGVjaXNpb25zX19FTl9fZzAuaHRtbCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuYnVuZGVzdmVyd2FsdHVuZ3NnZXJpY2h0LmRlL3dlaXRl cmVfSW5mb3JtYXRpb25lbi9JbmZvcm1hdGlvbl9hbmRfRGVjaXNpb25zX19FTl9fZzAuaHRtbDwv YT48YnI+DQo8YnI+DQpPbmxpbmUgQWNjZXNzIHRvIGRlY2lzaW9ucyBmb3Igbm9uLWNvbW1lcmNp YWwgdXNlIChpbiBHZXJtYW4gbGFuZ3VhZ2Ugb25seSk8YnI+DQpzZWFyY2ggZm9yICZxdW90O0JW ZXJ3RyAyIEEgMTEuMDgmcXVvdDs8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJ1bmRlc3Zlcndh bHR1bmdzZ2VyaWNodC5kZS9FbnRzY2hlaWR1bmdlbi9FbnRzY2hlaWR1bmdzc3VjaGVfbnkuaHRt bCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuYnVuZGVzdmVyd2FsdHVuZ3NnZXJpY2h0LmRl L0VudHNjaGVpZHVuZ2VuL0VudHNjaGVpZHVuZ3NzdWNoZV9ueS5odG1sPC9hPjxicj4NCjxicj4N ClRoZSByZWxldmFudCBwYXJ0cyBvZiB0aGF0IGRlY2lzaW9uIGFyZSBwYXJhZ3JhcGhzIDE3LTE5 LCBiYXNpY2FsbHk8YnI+DQpyZS1pdGVyYXRpbmcgdGhlIEZlZGVyYWwgQ29uc3RpdHV0aW9uYWwg Q291cnRzIHJlcXVpcmVtZW50IGZvciBhPGJyPg0KZXhpc3RlbmNlIG9mIGEgZm9ybWFsIHN0YXR1 dGUgbGF3IGJ5IHRoZSBwYXJsYW1lbnRhcmlhbiBsZWdpc2xhdG9yPGJyPg0KdG8gYWNjZXNzIG5v bi1wdWJsaWMgcGVyc29uYWwgaW5mb3JtYXRpb24uIFRoYXQgdGhlIGluZm9ybWF0aW9uPGJyPg0K d2FzIHN0b3JlZCBvbiB0aGUgbmV0d29yayBzdG9yYWdlIG9mIHRoZSBlbXBsb3llciwgYW5kIHRo YXQgdGhlIHVzZTxicj4NCm9mIHRoYXQgc3RvcmFnZSB3YXMgb2ZmaWNpYWxseSBzdHJpY3RseSBs aW1pdGVkIHRvIGJ1c2luZXNzLXJlbGF0ZWQ8YnI+DQppc3N1ZXMgd2FzIGZvdW5kIHRvIGJlIGly cmVsZXZhbnQhITxicj4NCjxicj4NCjxicj4NClRoaXMgcGFydGljdWxhciBjYXNlIHdhcyBhYm91 dCBhbiBlbXBsb3llZSB3b3JraW5nIGZvciB0aGUgR2VybWFuPGJyPg0KZmVkZXJhbC9nb3Zlcm5t ZW50YWwgYWdlbmN5ICZxdW90O0J1bmRlc25hY2hyaWNodGVuZGllbnN0IChCTkQpJnF1b3Q7PGJy Pg0KKHdoaWNoIG1pZ2h0IGJlIHZhZ3VlbHkgbGlrZWQgdG8gdGhlIENJQSBhbW9uZyBVUyBnb3Zl cm5tZW50IGFnZW5jaWVzKS48YnI+DQpUaGUgZW1wbG95ZXIgKEJORCkgaGFkIHByb3ZpZGVkIG5v bi1wdWJsaWMgbmV0d29yayBzdG9yYWdlIHRvIHRoZTxicj4NCmVtcGxveWVlLCBhbmQgc2VhcmNo ZWQsIHByb2JhYmx5IGFtb25nIG90aGVyIGxvY2F0aW9ucywgdGhlIGNvbnRlbnRzPGJyPg0Kb2Yg dGhhdCBuZXR3b3JrIHN0b3JhZ2UgZm9yIGluZGljYXRpb25zIG9mIG5vbi1jb21wbGlhbnQgcHVi bGljYXRpb248YnI+DQpvZiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uPGJyPg0KPGJyPg0KU2lu Y2UgdGhlcmUgd2FzIG5vIHByb2JhYmx5IGNhdXNlIGFuZCBubyBvZmZpY2lhbCBjcmltaW5hbCBp bnZlc3RpZ2F0aW9uPGJyPg0Kd2hlbiB0aGUgc2VhcmNoIHdhcyBwZXJmb3JtZWQsIHRoZXJlIHdh cyBubyBhcHBsaWNhYmxlIGZvcm1hbCBzdGF0dWUgbGF3PGJyPg0KYXV0aG9yaXppbmcgdGhpcyBz ZWFyY2gsIHNvIHRoZSBzZWFyY2ggd2FzIGZvdW5kIHRvIGJlIGEgc2V2ZXJlIHZpb2xhdGlvbjxi cj4NCm9mIHRoZSBlbXBsb3llZXMgcmlnaHQgb2YgaW5mb3JtYXRpb25hbCBzZWxmLWRldGVybWlu YXRpb24sIGJhc2VkPGJyPg0Kb24gdGhlIHJlcXVpcmVtZW50cyBlc3RhYmxpc2hlZCBieSB0aGUg RmVkZXJhbCBDb25zdGl0dXRpb25hbCBDb3VydC48YnI+DQo8YnI+DQpBZnRlciB0aGlzIGRlY2lz b24sIHRoZSBlbXBsb3llZSBzdWVkIGhpcyBlbXBsb3llciBmb3IgJnF1b3Q7cHVuaXRpdmUgZGFt YWdlcyZxdW90Ozxicj4NCmZyb20gdGhpcyBpbGxlZ2FsIHNlYXJjaCBvZiBoaXMgcGVyc29uYWwg ZGF0YS4gVGhlIGVtcGxveWVlIHdhcyByZWNlbnRseTxicj4NCmF3YXJkZWQgRVVSIDMwMDAsLSBi eSAmcXVvdDtMYW5kZ2VyaWNodCBCZXJsaW4mcXVvdDs8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRw Oi8vd3d3LmJlcmxpbmVyLXplaXR1bmcuZGUvcG9saXRpay9idW5kZXNuYWNocmljaHRlbmRpZW5z dC1ibmQtbXVzcy16YWhsZW4sMTA4MDgwMTgsMjEwNTE1NDIuaHRtbCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly93d3cuYmVybGluZXItemVpdHVuZy5kZS9wb2xpdGlrL2J1bmRlc25hY2hyaWNodGVu ZGllbnN0LWJuZC1tdXNzLXphaGxlbiwxMDgwODAxOCwyMTA1MTU0Mi5odG1sPC9hPjxicj4NCjxi cj4NClRoYXQgbGF0dGVyIGRlY2lzaW9uIGFib3V0IHRoZSBhd2FyZGVkIGRhbWFnZXMgaXMgc3Rp bGwgZnJlc2gsIGFuZDxicj4NCmNvdWxkIHBvdGVudGlhbGx5IGJlIGFwcGVhbGVkIGJ5IHRoZSBl bXBsb3llci4gVGhhdCBkZWNpc2lvbiBhbHNvPGJyPg0KaGFzbid0IGJlZW4gcHVibGlzaGVkIHll dCwgYnV0IGdpdmVuIHRoYXQgaXQgaXMgYmFzZWQgb24gdGhlIHZlcnk8YnI+DQpjbGVhciBkZXRl cm1pbmF0aW9uICZxdW90O0JWZXJmRyAyIEEgMTEuMDgmcXVvdDssIGl0IHdpbGwgYmUgZWFzeSB0 byBqdXN0aWZ5PGJyPg0Kc3VjaCBhIHBheW1lbnQgb2YgZGFtYWdlcy4gSXQgc2lkZXMgcXVpdGUg d2VsbCB3aXRoIGRlY2lzaW9uczxicj4NCm9mIHRoZSBGZWRlcmFsIExhYm91ciBjb3VydCBmb3Ig c2V2ZXJlIHZpb2xhdGlvbnMgb2YgZW1wbG95ZWU8YnI+DQpwZXJzb25hbGl0eSByaWdodHMuPGJy Pg0KPGJyPg0KPGJyPg0KLU1hcnRpbjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2FjbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2FjbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNhY21AaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNt PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA03E3E6AZFFEXMB04globala_-- From tony@yaanatech.com Wed Dec 12 04:33:19 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F00D21F88C8 for ; Wed, 12 Dec 2012 04:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2J1tgmOHh6m for ; Wed, 12 Dec 2012 04:33:13 -0800 (PST) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8309721F88CB for ; Wed, 12 Dec 2012 04:33:13 -0800 (PST) Received: from [10.184.77.215] (unknown [203.121.55.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 1A3F058081; Wed, 12 Dec 2012 12:33:11 +0000 (UTC) Message-ID: <50C87985.7010107@yaanatech.com> Date: Wed, 12 Dec 2012 20:33:09 +0800 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <1881776.88532.1355233983240.JavaMail.root@vznit170164> <9904FB1B0159DA42B0B887B7FA8119CA03E3E6@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA03E3E6@AZ-FFEXMB04.global.avaya.com> Content-Type: multipart/alternative; boundary="------------050007040709050801050603" Cc: "david.oliva@verizon.net" , "mrex@sap.com" , "sacm@ietf.org" Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 12:33:19 -0000 This is a multi-part message in MIME format. --------------050007040709050801050603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit How about continuous security awareness, continuous security assessment, continuous security measurement, ... There seem like many options here. --tony On 2012-12-12 8:06 PM, Romascanu, Dan (Dan) wrote: > > I was also confused by the usage of the term 'monitoring' by the time > I was introducing myself in SACM. David Oliva 's observation is > correct, 'monitoring' as used in SACM is about auditing the security > controls and mechanisms (although using 'auditing' instead could > create other confusions) > --------------050007040709050801050603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
How about continuous security awareness,
continuous security assessment, continuous
security measurement, ...   There
seem like many options here.

--tony

On 2012-12-12 8:06 PM, Romascanu, Dan (Dan) wrote:

I was also confused by the usage of the term ‘monitoring’ by the time I was introducing myself in SACM. David Oliva ‘s observation is correct, ‘monitoring’ as used in SACM is about auditing the security controls and mechanisms (although using ‘auditing’ instead could create other confusions)


--------------050007040709050801050603-- From ietfdbh@comcast.net Wed Dec 12 06:28:34 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E064E21F899E for ; Wed, 12 Dec 2012 06:28:33 -0800 (PST) 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=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp+cnlW9W40E for ; Wed, 12 Dec 2012 06:28:32 -0800 (PST) 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 37DC321F89C2 for ; Wed, 12 Dec 2012 06:28:29 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id adY21k0030bG4ec55eUSco; Wed, 12 Dec 2012 14:28:26 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta03.westchester.pa.mail.comcast.net with comcast id aeUR1k01G3Ecudz3PeUSom; Wed, 12 Dec 2012 14:28:26 +0000 From: "ietfdbh" To: , "'Romascanu, Dan \(Dan\)'" References: <1881776.88532.1355233983240.JavaMail.root@vznit170164> <9904FB1B0159DA42B0B887B7FA8119CA03E3E6@AZ-FFEXMB04.global.avaya.com> <50C87985.7010107@yaanatech.com> In-Reply-To: <50C87985.7010107@yaanatech.com> Date: Wed, 12 Dec 2012 09:28:13 -0500 Message-ID: <009f01cdd874$eb73e760$c25bb620$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CDD84B.02A05060" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlMdIqG/Dv+8i86xjjPudekNpA/wEldGVCATCd1VGW09SKUA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355322506; bh=qrDAbzXlSxUBiEMxbtgzvwvmyaCr2i9wjRwPGH6YCow=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=cTxnX6t8CLQ3a1m73+jWrqDsyTNCBzyY7K2PPQmYYxF7Zs2BsYTQzG1gkIZqmsQ8Q 9U0ThkS1uUaS9HN8klmvR3g3QM/e40MLrj+1/uLqeV7dpVSRqs8ZEtslBRcOx5eUn3 t5O4twusyBDksLIMJ9P0UaMACZudLC6Lm/WGBx7pFwE57ZNoKiaRPVxpOYu2G37r3p /hFQ3xppGvzgx9Whx+M70jP7FraZqVbPbF2CbFNXRXp5iFNN/5+QjHVcEha5PMrwNu nwmF3WFb1JwAjCgQu5IusR1sgNYpGkBjAMraZYlwHoU8k7ZxxrX7Gt7dv8SznYlTYi kyLg1WGqyFSgQ== Cc: david.oliva@verizon.net, mrex@sap.com, sacm@ietf.org Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 14:28:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A0_01CDD84B.02A05060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think "security assessment" and "security measurement" is what the security system does, i.e. monitoring traffic/endusers/etc. How about "security system monitoring" or "security system assessment"? David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Wednesday, December 12, 2012 7:33 AM To: Romascanu, Dan (Dan) Cc: david.oliva@verizon.net; mrex@sap.com; sacm@ietf.org Subject: Re: [sacm] Mis-understanding of the term monitoring How about continuous security awareness, continuous security assessment, continuous security measurement, ... There seem like many options here. --tony On 2012-12-12 8:06 PM, Romascanu, Dan (Dan) wrote: I was also confused by the usage of the term 'monitoring' by the time I was introducing myself in SACM. David Oliva 's observation is correct, 'monitoring' as used in SACM is about auditing the security controls and mechanisms (although using 'auditing' instead could create other confusions) ------=_NextPart_000_00A0_01CDD84B.02A05060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I think “security assessment” and “security = measurement” is what the security system does, i.e. monitoring = traffic/endusers/etc.

How about “security system monitoring” or “security = system assessment”?

 

David Harrington

ie= tfdbh@comcast.net

+1-603-828-1401

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Tony Rutkowski
Sent: Wednesday, December 12, 2012 7:33 = AM
To: Romascanu, Dan (Dan)
Cc: = david.oliva@verizon.net; mrex@sap.com; sacm@ietf.org
Subject: = Re: [sacm] Mis-understanding of the term = monitoring

 

How = about continuous security awareness,
continuous security assessment, = continuous
security measurement, ...   There
seem like = many options here.

--tony

On 2012-12-12 8:06 PM, = Romascanu, Dan (Dan) wrote:

I was also confused by the usage of the term ‘monitoring’ = by the time I was introducing myself in SACM. David Oliva ‘s = observation is correct, ‘monitoring’ as used in SACM is = about auditing the security controls and mechanisms (although using = ‘auditing’ instead could create other = confusions)

 

------=_NextPart_000_00A0_01CDD84B.02A05060-- From amontville@tripwire.com Wed Dec 12 06:42:56 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0281D21F899D for ; Wed, 12 Dec 2012 06:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.973 X-Spam-Level: X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U8Cl8aSxNxD for ; Wed, 12 Dec 2012 06:42:55 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id C370821F8903 for ; Wed, 12 Dec 2012 06:42:54 -0800 (PST) Received: from mail19-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 14:42:53 +0000 Received: from mail19-am1 (localhost [127.0.0.1]) by mail19-am1-R.bigfish.com (Postfix) with ESMTP id 6CF3E420378 for ; Wed, 12 Dec 2012 14:42:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zz9f17Rc85fhzz1de0h1202h1e76h1d1ah1d2ahzz18c673h17326ah18602eh8275bhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1 (MessageSwitch) id 1355323331646491_28218; Wed, 12 Dec 2012 14:42:11 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.241]) by mail19-am1.bigfish.com (Postfix) with ESMTP id 90879120240 for ; Wed, 12 Dec 2012 14:42:11 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 14:42:04 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 3091C232122B for ; Wed, 12 Dec 2012 06:30:27 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 9596323211D9 for ; Wed, 12 Dec 2012 06:30:26 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 12 Dec 2012 06:46:28 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Wed, 12 Dec 2012 06:42:01 -0800 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJw== Date: Wed, 12 Dec 2012 14:42:00 +0000 Message-ID: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_4991FB2E5A124E0CBA52A85393B8F63Atripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 013b7da9-e547-4084-b477-cf14d5bc2917 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 14:42:56 -0000 --_000_4991FB2E5A124E0CBA52A85393B8F63Atripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_4991FB2E5A124E0CBA52A85393B8F63Atripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable All:

Hopefully I'm not out of bounds on this one, but it appears that our s= coping efforts have rekindled the group naming debate.  I'd like to pr= opose that we handle this overhead efficiently by conducting this poll. &nb= sp;

There is one statement with which you may or may not agree (number 1 b= elow), and a follow on "suggestion" space (number 2 below) if you= *do* agree with the statement.

1. Security Automation and Continuous Monitoring is not the best name = for our present efforts, which are now focused on UC1 as described in the u= se case draft.

2. I believe a more suitable name is _____________ .

I'd like to close this poll by 17:00 PST on December 19 (one week from= today).


Regards,


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_4991FB2E5A124E0CBA52A85393B8F63Atripwirecom_-- From kathleen.moriarty@emc.com Wed Dec 12 07:28:20 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3021F8504 for ; Wed, 12 Dec 2012 07:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2xHZD9dzW9L for ; Wed, 12 Dec 2012 07:28:19 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C4A0C21E804A for ; Wed, 12 Dec 2012 07:28:06 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBCFS25f011663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 10:28:05 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 12 Dec 2012 10:27:47 -0500 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBCFRfrg015558; Wed, 12 Dec 2012 10:27:43 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Wed, 12 Dec 2012 10:27:41 -0500 From: "Moriarty, Kathleen" To: Adam Montville , "sacm@ietf.org" Date: Wed, 12 Dec 2012 10:27:39 -0500 Thread-Topic: POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJ5gVSS0w Message-ID: References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.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_F5063677821E3B4F81ACFB7905573F24CE2B069AMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:28:20 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CE2B069AMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to see if we can remain focused on establishing our requiremen= ts so that we can progress to working group status. If we need to have thi= s discussion later, then that's fine, but I think the acronym is well-known= now. Requirements first? Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_F5063677821E3B4F81ACFB7905573F24CE2B069AMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would l= ike to see if we can remain focused on establishing our requirements so tha= t we can progress to working group status.  If we need to have this di= scussion later, then that’s fine, but I think the acronym is well-kno= wn now.

 <= /span>

Requirements first?=

 

Thanks,

Kath= leen

 

From: sacm-bounces@ietf.org [mailto= :sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: = Wednesday, December 12, 2012 9:42 AM
To: sacm@ietf.org
Subj= ect: [sacm] POLL: SACM Name Change

 

All:

 

Hopefully I'm not out of bounds on this one, but it appears that o= ur scoping efforts have rekindled the group naming debate.  I'd like t= o propose that we handle this overhead efficiently by conducting this poll.=  

 

=

There is one statement with which you may o= r may not agree (number 1 below), and a follow on "suggestion" sp= ace (number 2 below) if you *do* agree with the statement.

 

1. Security Automation and Continuous Monitoring is not the best na= me for our present efforts, which are now focused on UC1 as described in th= e use case draft.

 =

2. I believe a more suitable name= is _____________ .

&nbs= p;

I'd like to close this poll by = 17:00 PST on December 19 (one week from today).

 

 

Regards,

<= br>Adam W. Montville | Security and Compliance Architec= t

Direct: 503 276-7661
Mobile: 360 471-7815    <= o:p>


TRIPWIRE | CONFIDENCE:=  SECURED
www.tri= pwire.com

&nbs= p;

 

 

= --_000_F5063677821E3B4F81ACFB7905573F24CE2B069AMX15Acorpemccom_-- From ietfdbh@comcast.net Wed Dec 12 07:31:58 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0488B21E804A for ; Wed, 12 Dec 2012 07:31:58 -0800 (PST) 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=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0yodqKoyRIW for ; Wed, 12 Dec 2012 07:31:53 -0800 (PST) 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 702EF21E80C7 for ; Wed, 12 Dec 2012 07:31:39 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id acWU1k00727AodY5FfXNpk; Wed, 12 Dec 2012 15:31:22 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta19.westchester.pa.mail.comcast.net with comcast id afXM1k00x3Ecudz3ffXNwc; Wed, 12 Dec 2012 15:31:22 +0000 From: "ietfdbh" To: "'Adam Montville'" , References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> Date: Wed, 12 Dec 2012 10:31:09 -0500 Message-ID: <00b601cdd87d$b5f86940$21e93bc0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01CDD853.CD23C0D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJt5Ew6TfoMYh9rbu3MArbFoR1H65bVLNew Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355326282; bh=HYfruj4lG/ANoeLLiFUwb+3lJ7z11jCxCtkiaDl+y9Y=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=cbxO/npDapT9Rh3ZVz9Z6QdhmWkrL6rY+hDsAMlO3h8bh8ljhtFO9KnwjSiQvoBKF q5ivNBNcmQEklQfbhJctVUbxRLxkoCRpoGbn0ggy4J0UsaIvXj19lM1XZrx6pHPtvp rG1SeM35D0CAGkCtUf22zHuTxdolHcfWVmf/I5SXHPqBkFC600M9bi4md53HePQqd9 iFrg8ZFJwP28GNRUF5gjPSJhO19Z9BNbIFztsI0gY9SuOS18InV3a7iSN5ltP8w9g9 GHZx69IzvOG2WNNdmw4cziCumHNKf2OK8FkFoU1JSRLzfazNT5GCUGv/0cKXYTBLv+ h/UKIJyxSyKSQ== Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:31:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B7_01CDD853.CD23C0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I think SACM is fine and doesn't need to be changed. The BOF name is only a temporary name; what's important is getting the documents written. If the area directors are convinced a change is needed to prevent confusion, the change can be done if/when the effort goes from BOF to WG. I think SACM would be fine as a WG name as well, since even the WG is a temporary thing. RFCs are the things that last forever, and I recommend not mentioning SACM in them since SACM will likely be shut down once the RFCs are published. (Personally, I think CM is really a part of SA, so, e.g., the "SACM Use Cases" title could be changed to "Security Automation Use Cases" easily.) I'm curious. I subscribe to the sacm list; I haven't seen any discussions of renaming the group. I checked the archive and didn't see any threads about renaming (and the Poll about Scope thread is mostly +1s) Where have you seen this discussion rekindled? BTW, chairs, the SACM BOF charter ( http://datatracker.ietf.org/wg/sacm/charter/) doesn't contain the list/archive info. I had to hunt it down in my "welcome to SACM" email. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scoping efforts have rekindled the group naming debate. I'd like to propose that we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below), and a follow on "suggestion" space (number 2 below) if you *do* agree with the statement. 1. Security Automation and Continuous Monitoring is not the best name for our present efforts, which are now focused on UC1 as described in the use case draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from today). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ------=_NextPart_000_00B7_01CDD853.CD23C0D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think SACM is fine and doesn’t need to be = changed.

The BOF name is only a temporary name; what’s important is = getting the documents written.

If the area directors are convinced a change is needed to prevent = confusion, the change can be done if/when the effort goes from BOF to = WG.

I think SACM would be fine as a WG name as well, since even the WG is = a temporary thing.

RFCs are the things that last forever, and I recommend not mentioning = SACM in them since SACM will likely be shut down once the RFCs are = published.

(Personally, I think CM is really a part of SA, so, e.g., the = “SACM Use Cases” title could be changed to “Security = Automation Use Cases” easily.)

 

I’m curious. I subscribe to the sacm list; I haven’t seen = any discussions of renaming the group.

I checked the archive and didn’t see any threads about renaming = (and the Poll about Scope thread is mostly +1s)

Where have you seen this discussion rekindled? =

 

BTW, chairs, the SACM BOF charter (http://data= tracker.ietf.org/wg/sacm/charter/) doesn’t contain the list/archive info. =

I had to hunt it down in  my “welcome to SACM” = email.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Adam Montville
Sent: Wednesday, December 12, 2012 9:42 = AM
To: sacm@ietf.org
Subject: [sacm] POLL: SACM Name = Change

 

All: =

 

Hopefully I'm not out of bounds on this one, but it = appears that our scoping efforts have rekindled the group naming debate. =  I'd like to propose that we handle this overhead efficiently by = conducting this poll.  

 

There is one statement with which you may or may not = agree (number 1 below), and a follow on "suggestion" space = (number 2 below) if you *do* agree with the = statement.

 

1. Security Automation and Continuous Monitoring is = not the best name for our present efforts, which are now focused on UC1 = as described in the use case draft.

 

2. I believe a more suitable name is _____________ = .

 

I'd like to close this poll by 17:00 PST on December = 19 (one week from today).

 

 

Regards,

=
Adam W. Montville = | Security and Compliance Architect

= Direct: 503 276-7661
Mobile: 360 471-7815   =  

<= br>TR= IPWIRE&n= bsp;|<= span class=3Dapple-converted-space> CONFIDE= NCE:<= span class=3Dapple-converted-space> SECURED
www.tripwire.com<= /p>

 

 

 

------=_NextPart_000_00B7_01CDD853.CD23C0D0-- From ggolovinsky@qualys.com Wed Dec 12 07:32:07 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0D121E80C5 for ; Wed, 12 Dec 2012 07:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rdQJrsonjTF for ; Wed, 12 Dec 2012 07:32:06 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C68321E8096 for ; Wed, 12 Dec 2012 07:32:05 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so494215qca.31 for ; Wed, 12 Dec 2012 07:32:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=2kBqqaGra5qUSgaYann2VKoRtbCsI3369m0l4oVtktQ=; b=RRqNTjsK1agE43HWWXxnB4kJkxBLeOd0i+oNxFh6KZf/Dn0SCW8OEUe5i5qTHHcaFH eTSfV+cwk3wK04NSVyVlwOF6008GE7uXjXF5kjTO5m5J4ESIG41rEx+5/k3f8oohpyEm qbIbCrB+xN2C+IwcdhRzZw72zcu3NVdMHTPg88GzFKXXJ4OzF2CEX08+8bAieIGz59CW ab1iNJECdCQ35je84RZAh6ic/8u6Ch1TByXWQepQoKGmOfsjcuB5Q/T8vkuX7gp8wPUR m9Lv0mwvEJkzkyGCU7KS9NG5hSQ1cPs2RvL2lZEzeT7Mev4ZIikF6Zc8ydzkPjI6Bt75 L/hA== Received: by 10.224.116.12 with SMTP id k12mr2627375qaq.47.1355326324588; Wed, 12 Dec 2012 07:32:04 -0800 (PST) From: Gene Golovinsky References: <1881776.88532.1355233983240.JavaMail.root@vznit170164> <9904FB1B0159DA42B0B887B7FA8119CA03E3E6@AZ-FFEXMB04.global.avaya.com> <50C87985.7010107@yaanatech.com> In-Reply-To: <50C87985.7010107@yaanatech.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlMdIqG/Dv+8i86xjjPudekNpA/wEldGVCATCd1VGW0+b3UA== Date: Wed, 12 Dec 2012 07:32:04 -0800 Message-ID: To: tony@yaanatech.com, "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=20cf3074d7e021c11b04d0a9807b X-Gm-Message-State: ALoCoQm62x7REJBaDrxGg3ZTY4ihTLSiU4ANabtAOcAD58t26WnR7H3didbhK6lqlRS0MdYiiyAb Cc: david.oliva@verizon.net, mrex@sap.com, sacm@ietf.org Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:32:07 -0000 --20cf3074d7e021c11b04d0a9807b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =93Continues monitoring=94 seems to be reasonably well accepted and widely circulated term. I think that changing it to something else will cause more confusion, not less. --Gene *From:* sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Tony Rutkowski *Sent:* Wednesday, December 12, 2012 04:33 AM *To:* Romascanu, Dan (Dan) *Cc:* david.oliva@verizon.net; mrex@sap.com; sacm@ietf.org *Subject:* Re: [sacm] Mis-understanding of the term monitoring How about continuous security awareness, continuous security assessment, continuous security measurement, ... There seem like many options here. --tony On 2012-12-12 8:06 PM, Romascanu, Dan (Dan) wrote: I was also confused by the usage of the term =91monitoring=92 by the time I= was introducing myself in SACM. David Oliva =91s observation is correct, =91monitoring=92 as used in SACM is about auditing the security controls an= d mechanisms (although using =91auditing=92 instead could create other confus= ions) --20cf3074d7e021c11b04d0a9807b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

=93Continues monitoring=94 seems to be reasonably well acce= pted and widely circulated term.

I think that changing it = to something else will cause more confusion, not less.

=A0

--Gene

=A0

=A0

From:<= /span> sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Tony Rutkowski
Sent: Wednesday, December 12, 2012 04:33 AM
To: Romascanu,= Dan (Dan)
Cc: david.o= liva@verizon.net; mrex@sap.com; sacm@ietf.org
Subject: Re: [sacm] Mis-understanding of the term monitoring<= /p>

=A0

Ho= w about continuous security awareness,
continuous security assessment, c= ontinuous
security measurement, ...=A0=A0 There
seem like many options here.
--tony

On 2012-12-12 8:06 PM, Romascanu, Dan (Dan) wrote:

I was also confused by the usage of the term =91= monitoring=92 by the time I was introducing myself in SACM. David Oliva =91= s observation is correct, =91monitoring=92 as used in SACM is about auditin= g the security controls and mechanisms (although using =91auditing=92 inste= ad could create other confusions)

=A0

--20cf3074d7e021c11b04d0a9807b-- From amontville@tripwire.com Wed Dec 12 07:35:52 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECF421E805E for ; Wed, 12 Dec 2012 07:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEpEqENX2QAj for ; Wed, 12 Dec 2012 07:35:51 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFF021E8054 for ; Wed, 12 Dec 2012 07:35:51 -0800 (PST) Received: from mail255-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 15:35:51 +0000 Received: from mail255-tx2 (localhost [127.0.0.1]) by mail255-tx2-R.bigfish.com (Postfix) with ESMTP id 108C0FC01CF for ; Wed, 12 Dec 2012 15:35:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz98dI9371I9f17Rc85eh4015Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h17326ah18602eh8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail255-tx2 (localhost.localdomain [127.0.0.1]) by mail255-tx2 (MessageSwitch) id 1355326533455915_26663; Wed, 12 Dec 2012 15:35:33 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.240]) by mail255-tx2.bigfish.com (Postfix) with ESMTP id 65EAE13C0047 for ; Wed, 12 Dec 2012 15:35:33 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 15:35:30 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id B6E93232122B for ; Wed, 12 Dec 2012 07:23:53 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 1C75E23211D0; Wed, 12 Dec 2012 07:23:53 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 12 Dec 2012 07:39:55 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Wed, 12 Dec 2012 07:35:27 -0800 From: Adam Montville To: "Moriarty, Kathleen" Thread-Topic: POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJ5gVSS0wgACIngA= Date: Wed, 12 Dec 2012 15:35:26 +0000 Message-ID: <26806F82-EE51-4922-8D8A-8CB9A14A3F1C@tripwire.com> References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.97.156] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_26806F82EE5149228D8A8CB9A14A3F1Ctripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 32200555-4103-4069-ad86-a3259f58b669 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:35:52 -0000 --_000_26806F82EE5149228D8A8CB9A14A3F1Ctripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kathleen, I actually agree with you. That said, I also believe that naming can be a = distraction - I was hoping to drive it to some conclusion sooner rather tha= n later in support of keeping our focus on the requirements. Speaking of the requirements, I sent a first pass out to the list yesterday= , so I hope we can have some discussion about them soon. Regards, Adam On Dec 12, 2012, at 7:27 AM, "Moriarty, Kathleen" > wrote: I would like to see if we can remain focused on establishing our requiremen= ts so that we can progress to working group status. If we need to have thi= s discussion later, then that=92s fine, but I think the acronym is well-kno= wn now. Requirements first? Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_26806F82EE5149228D8A8CB9A14A3F1Ctripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6B49FB5719C89A41A1431B3F9A566592@tripwire.com> Content-Transfer-Encoding: quoted-printable Kathleen,

I actually agree with you.  That said, I also believe that naming= can be a distraction - I was hoping to drive it to some conclusion sooner = rather than later in support of keeping our focus on the requirements.

Speaking of the requirements, I sent a first pass out to the list yest= erday, so I hope we can have some discussion about them soon.

Regards,

Adam

On Dec 12, 2012, at 7:27 AM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
 wrote:

I would like to see if we can remain focused on establish= ing our requirements so that we can progress to working group status. = If we need to have this discussion later, then that=92s fine, but I think the acronym is well-known now.<= /span>
 
Requirements first?
 
Thanks,
Kathleen
 
From:=  sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, D= ecember 12, 2012 9:42 AM
To: sacm@ietf.org
Subject: [sacm] PO= LL: SACM Name Change
 
All:
 
Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate.  I'd like to propose= that we handle this overhead efficiently by conducting this poll.  
 
There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do*= agree with the statement.
 
1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft.
 
2. I believe a more suitable name is _____________ .
 
I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y).
 
 
Regards,


Adam W. Montville | Security and Compliance Architect

Direct: = 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com

 = ;
 



Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_26806F82EE5149228D8A8CB9A14A3F1Ctripwirecom_-- From gapinski@nasa.gov Wed Dec 12 07:36:47 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7727F21F8445 for ; Wed, 12 Dec 2012 07:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqhPS-sTRtGS for ; Wed, 12 Dec 2012 07:36:47 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by ietfa.amsl.com (Postfix) with ESMTP id E5F5521F8442 for ; Wed, 12 Dec 2012 07:36:46 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 412B8D04B9 for ; Wed, 12 Dec 2012 09:36:45 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qBCFaiJI018561 for ; Wed, 12 Dec 2012 09:36:44 -0600 Received: from gr2186815.grc.nasa.gov (139.88.188.52) by smtp01.ndc.nasa.gov (198.117.1.160) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 12 Dec 2012 09:36:44 -0600 Message-ID: <50C8A48B.3090201@nasa.gov> Date: Wed, 12 Dec 2012 10:36:43 -0500 From: Gary Gapinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-12_05:2012-12-12, 2012-12-12, 1970-01-01 signatures=0 Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:36:47 -0000 On 12/12/2012 10:27 AM, Moriarty, Kathleen wrote: > > I would like to see if we can remain focused on establishing our > requirements so that we can progress to working group status. If we > need to have this discussion later, then that’s fine, but I think the > acronym is well-known now. > > > > Requirements first? > +1. Besides, everyone knows SACM stands for Sinister Alien Conformance Monitoring. From Kent_Landfield@mcafee.com Wed Dec 12 07:42:51 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E645221F85E6 for ; Wed, 12 Dec 2012 07:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz2gyQtqbmxd for ; Wed, 12 Dec 2012 07:42:51 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id D616021F85A4 for ; Wed, 12 Dec 2012 07:42:50 -0800 (PST) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 375a_3f9a_04fe992f_a9d8_48c5_a5a1_2218ff997711; Wed, 12 Dec 2012 09:42:49 -0600 Received: from MIVEXAPAC1N3.corp.nai.org (10.48.48.43) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 12 Dec 2012 10:41:21 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.159]) by MIVEXAPAC1N3.corp.nai.org ([10.48.48.43]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 10:41:21 -0500 From: To: , , Thread-Topic: [sacm] POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJ5gVSS0w///z0gA= Date: Wed, 12 Dec 2012 15:41:20 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF098AE5@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.48.48.241] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF098AE5MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:42:52 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF098AE5MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable While I thank Adam for the effort, I too see this as a distraction that we = don't need at this point. I'd much rather we focus on getting agreement on = the working group requirements. At that point we can see can revisit this b= ut for now =85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kathleen Moriarty > Date: Wednesday, December 12, 2012 9:27 AM To: Adam Montville = >, "sacm@ietf.org" > Subject: Re: [sacm] POLL: SACM Name Change I would like to see if we can remain focused on establishing our requiremen= ts so that we can progress to working group status. If we need to have thi= s discussion later, then that=92s fine, but I think the acronym is well-kno= wn now. Requirements first? Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_3CBA099FBA0AB843895D72474092B8CF098AE5MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7733EFD903B9814DA9A4428B9E9DC20A@McAfee.com> Content-Transfer-Encoding: quoted-printable
While I thank Adam for the effort, I too see this as a distraction tha= t we don't need at this point. I'd much rather we focus on getting agreemen= t on the working group requirements. At that point we can see can revisit t= his but for now =85


Kent Landfield

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

From: <Moriarty>, Kathleen Mo= riarty <kathleen.moriarty@e= mc.com>
Date: Wednesday, December 12, 2012 = 9:27 AM
To: Adam Montville <amontville@tripwire.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] POLL: SACM Name= Change

I would like to see if we can rema= in focused on establishing our requirements so that we can progress to work= ing group status.  If we need to have this discussion later, then that=92s fine, but I think the acronym is well= -known now.

 

Requirements first?

 

Thanks,

Kathleen

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 9:42 AM
To: sacm@ietf.org
Subject: [sacm] POLL: SACM Name Change

 

All:

 

Hopefully I'm not out of bounds on this one, but it = appears that our scoping efforts have rekindled the group naming debate. &n= bsp;I'd like to propose that we handle this overhead efficiently by conduct= ing this poll.  

 

There is one statement with which you may or may not= agree (number 1 below), and a follow on "suggestion" space (numb= er 2 below) if you *do* agree with the statement.

 

1. Security Automation and Continuous Monitoring is = not the best name for our present efforts, which are now focused on UC1 as = described in the use case draft.

 

2. I believe a more suitable name is _____________ .=

 

I'd like to close this poll by 17:00 PST on December= 19 (one week from today).

 

 

Regards,


Adam W. Montville | Security and Compliance Architect=

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE=  | CONFIDENCE:&nbs= p;SECURED
www.tripwire.com=

 

 

 

 --_000_3CBA099FBA0AB843895D72474092B8CF098AE5MIVEXAMER1N1corpn_-- From shanna@juniper.net Wed Dec 12 07:48:28 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8C21F841B for ; Wed, 12 Dec 2012 07:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Afak4hR4+VsO for ; Wed, 12 Dec 2012 07:48:27 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3751C21F8781 for ; Wed, 12 Dec 2012 07:48:27 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUMinSyen08H2KffuPZzLZBDbuL1DxORy@postini.com; Wed, 12 Dec 2012 07:48:27 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 07:46:13 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 12 Dec 2012 07:46:13 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 07:48:24 -0800 Received: from mail131-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 15:46:11 +0000 Received: from mail131-ch1 (localhost [127.0.0.1]) by mail131-ch1-R.bigfish.com (Postfix) with ESMTP id C8CA640225 for ; Wed, 12 Dec 2012 15:46:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -33 X-BigFish: PS-33(zz9371I9f17Rc85fh4015I1415Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h17326ah18602eh8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail131-ch1 (localhost.localdomain [127.0.0.1]) by mail131-ch1 (MessageSwitch) id 1355327169348408_15973; Wed, 12 Dec 2012 15:46:09 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail131-ch1.bigfish.com (Postfix) with ESMTP id 48AF026004F; Wed, 12 Dec 2012 15:46:09 +0000 (UTC) Received: from SN2PRD0510HT003.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 15:46:09 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.140]) by SN2PRD0510HT003.namprd05.prod.outlook.com ([10.255.116.38]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 15:46:07 +0000 From: Stephen Hanna To: Adam Montville , "sacm@ietf.org" Thread-Topic: POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJ5gVP0zw Date: Wed, 12 Dec 2012 15:46:07 +0000 Message-ID: References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BC5SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TRIPWIRE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:48:28 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BC5SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do agree with statement 1. For statement 2, I suggest just "Security Automation" since this covers all= of the use cases that we've talked about. However, I look forward to seein= g more ideas from others and reserve the right to throw out more, better id= eas that may come to me later! :-) Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BC5SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do agree with statement= 1.

 <= /p>

For statement 2, I sugges= t just “Security Automation” since this covers all of the use c= ases that we’ve talked about. However, I look forward to seeing more ideas from others and reserve the right to throw out more, better ideas th= at may come to me later! :-)

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 9:42 AM
To: sacm@ietf.org
Subject: [sacm] POLL: SACM Name Change

 

All:

 

Hopefully I'm not out of bounds on this one, but it = appears that our scoping efforts have rekindled the group naming debate. &n= bsp;I'd like to propose that we handle this overhead efficiently by conduct= ing this poll.  

 

There is one statement with which you may or may not= agree (number 1 below), and a follow on "suggestion" space (numb= er 2 below) if you *do* agree with the statement.

 

1. Security Automation and Continuous Monitoring is = not the best name for our present efforts, which are now focused on UC1 as = described in the use case draft.

 

2. I believe a more suitable name is _____________ .=

 

I'd like to close this poll by 17:00 PST on December= 19 (one week from today).

 

 

Regards,


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

 

 

 

--_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BC5SN2PRD0510MB372_-- From dromasca@avaya.com Wed Dec 12 07:48:41 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8993921F8781 for ; Wed, 12 Dec 2012 07:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.345 X-Spam-Level: X-Spam-Status: No, score=-103.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtimqKYD7Ge7 for ; Wed, 12 Dec 2012 07:48:40 -0800 (PST) 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 AFF7521F841B for ; Wed, 12 Dec 2012 07:48:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKUvoFDGmAcF/2dsb2JhbABBA4JJI8BpgQiCHgEBAQEDEhscQAIBCAcGBAQBAQsdBzIUCQgCBAESCBqHaAGeMJwAjBWDHoJLYQOcCYo2gm+CGQ X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208,217";a="336104091" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Dec 2012 10:42:19 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Dec 2012 10:45:52 -0500 Received: from AZ-FFEXHC04.global.avaya.com (135.64.58.14) by DC-US1HCEX3.global.avaya.com (135.11.52.38) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 12 Dec 2012 10:48:36 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 10:48:35 -0500 From: "Romascanu, Dan (Dan)" To: "Moriarty, Kathleen" , Adam Montville , "sacm@ietf.org" Thread-Topic: POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJ5gVSS0wgAAGI2A= Date: Wed, 12 Dec 2012 15:48:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA03E87F@AZ-FFEXMB04.global.avaya.com> References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA03E87FAZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:48:41 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA03E87FAZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Wednesday, December 12, 2012 5:28 PM To: Adam Montville; sacm@ietf.org Subject: Re: [sacm] POLL: SACM Name Change I would like to see if we can remain focused on establishing our requiremen= ts so that we can progress to working group status. If we need to have thi= s discussion later, then that's fine, but I think the acronym is well-known= now. Requirements first? Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_9904FB1B0159DA42B0B887B7FA8119CA03E87FAZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Wednesday, December 12, 2012 5:28 PM
To: Adam Montville; sacm@ietf.org
Subject: Re: [sacm] POLL: SACM Name Change

 

I would like to see if we= can remain focused on establishing our requirements so that we can progres= s to working group status.  If we need to have this discussion later, then that’s fine, but I think the acronym is well-known now.<= o:p>

 <= /p>

Requirements first?<= /o:p>

 <= /p>

Thanks,=

Kathleen

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 9:42 AM
To: sacm@ietf.org
Subject: [sacm] POLL: SACM Name Change

 

All:

 

Hopefully I'm not out of bounds on this one, but it = appears that our scoping efforts have rekindled the group naming debate. &n= bsp;I'd like to propose that we handle this overhead efficiently by conduct= ing this poll.  

 

There is one statement with which you may or may not= agree (number 1 below), and a follow on "suggestion" space (numb= er 2 below) if you *do* agree with the statement.

 

1. Security Automation and Continuous Monitoring is = not the best name for our present efforts, which are now focused on UC1 as = described in the use case draft.

 

2. I believe a more suitable name is _____________ .=

 

I'd like to close this poll by 17:00 PST on December= 19 (one week from today).

 

 

Regards,


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA03E87FAZFFEXMB04globala_-- From shanna@juniper.net Wed Dec 12 07:52:40 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B5E21F878D for ; Wed, 12 Dec 2012 07:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhIJDx-MWNDd for ; Wed, 12 Dec 2012 07:52:39 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4D23521F8564 for ; Wed, 12 Dec 2012 07:52:38 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUMioRjA80cwHGlTHumsJA0lwj+SOjeDb@postini.com; Wed, 12 Dec 2012 07:52:38 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 07:47:57 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 12 Dec 2012 07:47:56 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.205) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 07:50:01 -0800 Received: from mail80-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 15:47:48 +0000 Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id 1F4B04600BE for ; Wed, 12 Dec 2012 15:47:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -33 X-BigFish: PS-33(zz9371Id6eah9f17Rc85fh4015I1415Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h17326ah18602eh8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 1355327265159533_9832; Wed, 12 Dec 2012 15:47:45 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.246]) by mail80-am1.bigfish.com (Postfix) with ESMTP id 2103BE0057; Wed, 12 Dec 2012 15:47:45 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 15:47:44 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.140]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 15:47:42 +0000 From: Stephen Hanna To: Adam Montville , "sacm@ietf.org" Thread-Topic: POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJ5gVP0zwgAAPhNA= Date: Wed, 12 Dec 2012 15:47:41 +0000 Message-ID: References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BE4SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TRIPWIRE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:52:40 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BE4SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tarnation! That will teach me to always read incoming email before hitting = send. I withdraw my email. This discussion can certainly wait. Sorry, Steve From: Stephen Hanna Sent: Wednesday, December 12, 2012 10:46 AM To: 'Adam Montville'; sacm@ietf.org Subject: RE: POLL: SACM Name Change I do agree with statement 1. For statement 2, I suggest just "Security Automation" since this covers all= of the use cases that we've talked about. However, I look forward to seein= g more ideas from others and reserve the right to throw out more, better id= eas that may come to me later! :-) Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BE4SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tarnation! That will teac= h me to always read incoming email before hitting send.

 <= /p>

I withdraw my email. This= discussion can certainly wait.

 <= /p>

Sorry,<= /p>

 <= /p>

Steve

 <= /p>

From: Stephen = Hanna
Sent: Wednesday, December 12, 2012 10:46 AM
To: 'Adam Montville'; sacm@ietf.org
Subject: RE: POLL: SACM Name Change

 

I do agree with statement= 1.

 <= /p>

For statement 2, I sugges= t just “Security Automation” since this covers all of the use c= ases that we’ve talked about. However, I look forward to seeing more ideas from others and reserve the right to throw out more, better ideas th= at may come to me later! :-)

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 9:42 AM
To: sacm@ietf.org
Subject: [sacm] POLL: SACM Name Change

 

All:

 

Hopefully I'm not out of bounds on this one, but it = appears that our scoping efforts have rekindled the group naming debate. &n= bsp;I'd like to propose that we handle this overhead efficiently by conduct= ing this poll.  

 

There is one statement with which you may or may not= agree (number 1 below), and a follow on "suggestion" space (numb= er 2 below) if you *do* agree with the statement.

 

1. Security Automation and Continuous Monitoring is = not the best name for our present efforts, which are now focused on UC1 as = described in the use case draft.

 

2. I believe a more suitable name is _____________ .=

 

I'd like to close this poll by 17:00 PST on December= 19 (one week from today).

 

 

Regards,


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

 

 

 

--_000_F1DFC16DCAA7D3468651A5A776D5796E068E3BE4SN2PRD0510MB372_-- From anton.chuvakin@gmail.com Wed Dec 12 07:53:34 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333DD21F87EE for ; Wed, 12 Dec 2012 07:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fptwvybJ40YC for ; Wed, 12 Dec 2012 07:53:23 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF06621F8808 for ; Wed, 12 Dec 2012 07:53:21 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so292397eaa.31 for ; Wed, 12 Dec 2012 07:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=gWMFIcnxCuWroi2ScW0J6qy5pXxyGPQPM7ct7eoINsk=; b=ZKX5j10X2KIyYAbtBGpjl9XLdJVwjKr7Ik+35sTkLjoKMONJkL4z0u95NGAFD6opf3 BWngI9g2JrHQYHuzOCn8mKFWBetutIW6p1BL2Y9W4s8lhXg+6vTsv+4rdOeJxBqfxBcU APRC1BoLqa2FYnbZIlTc7UcVfzdUQzdJqwgVz+gUTf+NoRIPh0cgXLx9VXu59rbD0Eri qlYqfLZXB0plL5ibrqH6R7Ul4ofo96zM/gLjYK82tR1Mu6l6t61Nr+/GXEXMxS0GzuqO zN9LzhmXjRJebAUmk71YLC2AVXOaa3Dxw9Gh3aMFQnZxwxZQpdvIJ0IospqFy5i8hoZT SPqw== Received: by 10.14.204.198 with SMTP id h46mr3748435eeo.1.1355327601045; Wed, 12 Dec 2012 07:53:21 -0800 (PST) MIME-Version: 1.0 Sender: anton.chuvakin@gmail.com Received: by 10.223.64.204 with HTTP; Wed, 12 Dec 2012 07:52:49 -0800 (PST) In-Reply-To: References: <1881776.88532.1355233983240.JavaMail.root@vznit170164> <9904FB1B0159DA42B0B887B7FA8119CA03E3E6@AZ-FFEXMB04.global.avaya.com> <50C87985.7010107@yaanatech.com> From: Anton Chuvakin Date: Wed, 12 Dec 2012 08:52:49 -0700 X-Google-Sender-Auth: RVF2icaSTNh1J2X7Ft4eX7-x0qw Message-ID: To: sacm@ietf.org Content-Type: multipart/alternative; boundary=047d7b343e3c36eed504d0a9ccbe Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:53:35 -0000 --047d7b343e3c36eed504d0a9ccbe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2012 at 8:32 AM, Gene Golovinsky wr= ote: > =93Continues monitoring=94 seems to be reasonably well accepted and widel= y > circulated term. > > I think that changing it to something else will cause more confusion, not > less. > > if you love in FISMA-land it is accepted. Elsewhere monitoring is monitoring (continuous by definition), and "continuous monitoring" is really "periodic control assessment." Guinea pig is NOT a pig, and it is NOT from Guinea.... --=20 Dr. Anton Chuvakin Site: http://www.chuvakin.org Twitter: @anton_chuvakin Work: http://www.linkedin.com/in/chuvakin --047d7b343e3c36eed504d0a9ccbe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 12, 2012 at 8:32 AM, Gene Go= lovinsky <ggolovinsky@qualys.com> wrote:
<= p class=3D"MsoNormal">=93Continues monitoring=94= seems to be reasonably well accepted and widely circulated term.

I think that changing it = to something else will cause more confusion, not less.


if you love in FISMA-land it is accepted. Elsewhere monitoring is m= onitoring (continuous by definition), and "continuous monitoring"= is really "periodic control assessment."=A0Guinea=A0pig is NOT a= pig, and it is NOT from Guinea....

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: = @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin
--047d7b343e3c36eed504d0a9ccbe-- From ggolovinsky@qualys.com Wed Dec 12 07:54:20 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5921F88DC for ; Wed, 12 Dec 2012 07:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZgnFrnmTn3O for ; Wed, 12 Dec 2012 07:54:01 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFC821F88AE for ; Wed, 12 Dec 2012 07:53:58 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so533662qca.31 for ; Wed, 12 Dec 2012 07:53:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:content-type:x-gm-message-state; bh=gx4HErQiC0mN538T10QfSf2+NrkjiTTp5cOfykHwgQU=; b=imP2Et4C9nvrYhmAh8KHMs5Lv1HzUJwLc1eSaL3yk2MmVuQo6tFKInB2tL6Yn9k4Zo zvTOf3ZhAsCJynfFFQe61axxYCvlOsZ1hO649Sza6NUMTG2AqLVWYqzoEQ7PofXOWBJD 7+cfPd1NFp04M0+aHq8ncjAIVxX33MM3m6Hke2eDbs3qUm2Gx7oDxGaoJ+0Qrx37YcK+ TPai3oazMZYndpA8gNUp6+a/9HKu2tKRF/CN69jZX53VPRgghIsA9b7Q1a72zJklWI+u EcPzGaYfx/DPIig6LkoQNWzubTQa0c9o2HaUvYGlRBjU1TtZuwcIcB42AuLHrIgd0pBg 6aAQ== Received: by 10.224.116.12 with SMTP id k12mr2761580qaq.47.1355327638391; Wed, 12 Dec 2012 07:53:58 -0800 (PST) From: Gene Golovinsky References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJt5Ew6TfoMYh9rbu3MArbFoR1H6wFtN0JIlsnPZ6A= Date: Wed, 12 Dec 2012 07:53:58 -0800 Message-ID: <6ffdcb7aa36cdddbd4a4d31493a6659d@mail.gmail.com> To: "Moriarty, Kathleen" , Adam Montville , sacm@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d7e070cc0304d0a9cec7 X-Gm-Message-State: ALoCoQlveQy+bWxks1XnDl3ilgL4bsbByJvjf4ROR8d4PJFPKfd1MUQla1Z+oqVqY/2h18Bz9+Hy Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:54:20 -0000 --20cf3074d7e070cc0304d0a9cec7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Requirements +1 --Gene *From:* sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Moriarty, Kathleen *Sent:* Wednesday, December 12, 2012 07:28 AM *To:* Adam Montville; sacm@ietf.org *Subject:* Re: [sacm] POLL: SACM Name Change I would like to see if we can remain focused on establishing our requirements so that we can progress to working group status. If we need to have this discussion later, then that=92s fine, but I think the acronym = is well-known now. Requirements first? Thanks, Kathleen *From:* sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Adam Montville *Sent:* Wednesday, December 12, 2012 9:42 AM *To:* sacm@ietf.org *Subject:* [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scoping efforts have rekindled the group naming debate. I'd like to propose that we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below), and a follow on "suggestion" space (number 2 below) if you *do* agree with the statement. 1. Security Automation and Continuous Monitoring is not the best name for our present efforts, which are now focused on UC1 as described in the use case draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from today). Regards, * Adam W. Montville *| Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 * **TRIPWIRE* | CONFIDENCE: *SECURED* www.tripwire.com --20cf3074d7e070cc0304d0a9cec7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Re= quirements +1

--Gene

=A0

=A0

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen=
Sent: Wednesday, December 12, 2012 07:28 AM
To: Adam Montv= ille; sacm@ietf.org
Subject:= Re: [sacm] POLL: SACM Name Change

=A0

I would like to se= e if we can remain focused on establishing our requirements so that we can = progress to working group status.=A0 If we need to have this discussion lat= er, then that=92s fine, but I think the acronym is well-known now.

=A0

Requirements first?

=A0

Thanks,

Kathleen

=A0

From: sacm-bounces@ietf.org [<= a href=3D"mailto:sacm-bounces@ietf.org">mailto:sacm-bounces@ietf.org] <= b>On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 9:42 AM
To: sacm@ietf.org
Subject: [sacm] POLL: SAC= M Name Change

=A0

All:

=A0

Hopefully I'm not out of bounds on this one, but it appears that our= scoping efforts have rekindled the group naming debate. =A0I'd like to= propose that we handle this overhead efficiently by conducting this poll. = =A0

=A0

= There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do*= agree with the statement.

=A0

= 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft.

=A0

= 2. I believe a more suitable name is _____________ .

=A0

I'd like to clo= se this poll by 17:00 PST on December 19 (one week from today).

=A0

= =A0

Regards,


Adam W. Montville=A0| Security and Compliance Architect

Direct: 503 276-76= 61
Mobile: 360 471-7815 =A0 =A0

=
TRIPWIRE=A0|=A0:=A0SECURED
www.tripwire.com

=A0

=A0

=A0

--20cf3074d7e070cc0304d0a9cec7-- From amontville@tripwire.com Wed Dec 12 08:01:52 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9743C21E8050 for ; Wed, 12 Dec 2012 08:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOSMKTZXXUqg for ; Wed, 12 Dec 2012 08:01:51 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 0377B21F897E for ; Wed, 12 Dec 2012 08:01:50 -0800 (PST) Received: from mail17-db3-R.bigfish.com (10.3.81.237) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 16:01:50 +0000 Received: from mail17-db3 (localhost [127.0.0.1]) by mail17-db3-R.bigfish.com (Postfix) with ESMTP id 61EDA220302 for ; Wed, 12 Dec 2012 16:01:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz98dI9371I9f17Rc85eh4015Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh182cceh8275dh18c673h18602ehz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail17-db3 (localhost.localdomain [127.0.0.1]) by mail17-db3 (MessageSwitch) id 1355328049754060_24791; Wed, 12 Dec 2012 16:00:49 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.238]) by mail17-db3.bigfish.com (Postfix) with ESMTP id 66024340197 for ; Wed, 12 Dec 2012 16:00:49 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 15:50:03 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id CAABB2321243 for ; Wed, 12 Dec 2012 07:38:25 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 2D7F723211D0; Wed, 12 Dec 2012 07:38:25 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 12 Dec 2012 07:54:27 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Wed, 12 Dec 2012 07:49:59 -0800 From: Adam Montville To: "Kent_Landfield@McAfee.com" Thread-Topic: [sacm] POLL: SACM Name Change Thread-Index: AQHN2HbXAqEHI+/1/EKQG6a5kF5fJ5gVSS0w///z0gCAAJjcAA== Date: Wed, 12 Dec 2012 15:49:58 +0000 Message-ID: References: <3CBA099FBA0AB843895D72474092B8CF098AE5@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF098AE5@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.97.156] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CD48FE6D337F46938419B46FF454A532tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 7e650909-b41e-4d21-8fce-b48792384cb6 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "" , "" Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:01:52 -0000 --_000_CD48FE6D337F46938419B46FF454A532tripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sent out a first pass at requirements yesterday (day before?), hoping to ge= t feedback by end of tomorrow so I can start creating a draft on Friday. On Dec 12, 2012, at 7:41 AM, Kent_Landfield@McAfee.com wrote: While I thank Adam for the effort, I too see this as a distraction that we = don't need at this point. I'd much rather we focus on getting agreement on = the working group requirements. At that point we can see can revisit this b= ut for now =85 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kathleen Moriarty > Date: Wednesday, December 12, 2012 9:27 AM To: Adam Montville = >, "sacm@ietf.org" > Subject: Re: [sacm] POLL: SACM Name Change I would like to see if we can remain focused on establishing our requiremen= ts so that we can progress to working group status. If we need to have thi= s discussion later, then that=92s fine, but I think the acronym is well-kno= wn now. Requirements first? Thanks, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, December 12, 2012 9:42 AM To: sacm@ietf.org Subject: [sacm] POLL: SACM Name Change All: Hopefully I'm not out of bounds on this one, but it appears that our scopin= g efforts have rekindled the group naming debate. I'd like to propose that= we handle this overhead efficiently by conducting this poll. There is one statement with which you may or may not agree (number 1 below)= , and a follow on "suggestion" space (number 2 below) if you *do* agree wit= h the statement. 1. Security Automation and Continuous Monitoring is not the best name for o= ur present efforts, which are now focused on UC1 as described in the use ca= se draft. 2. I believe a more suitable name is _____________ . I'd like to close this poll by 17:00 PST on December 19 (one week from toda= y). Regards, Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_CD48FE6D337F46938419B46FF454A532tripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Sent out a first pass at requirements yesterday (day before?), hoping = to get feedback by end of tomorrow so I can start creating a draft on Frida= y.

On Dec 12, 2012, at 7:41 AM, Kent_Landfield@McAfee.com wrote:

While I thank Adam for the effort, I too see this as a distraction tha= t we don't need at this point. I'd much rather we focus on getting agreemen= t on the working group requirements. At that point we can see can revisit t= his but for now =85


Kent Landfield

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

From: <Moriarty>, Kathleen Mo= riarty <kathleen.moriarty@e= mc.com>
Date: Wednesday, December 12, 2012 = 9:27 AM
To: Adam Montville <amontville@tripwire.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] POLL: SACM Name= Change

I would like to see if we can re= main focused on establishing our requirements so that we can progress to wo= rking group status.  If we need to have this discussion later, then that=92s fine, but I think the acronym is well= -known now.
 
Requirements first?
 
Thanks,
Kathleen
 
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 9:42 AM
To: sacm@ietf.org
Subject: [sacm] POLL: SACM Name Change
 
All:
 
Hopefully I'm not out of bounds on this one, but i= t appears that our scoping efforts have rekindled the group naming debate. =  I'd like to propose that we handle this overhead efficiently by condu= cting this poll.  
 
There is one statement with which you may or may n= ot agree (number 1 below), and a follow on "suggestion" space (nu= mber 2 below) if you *do* agree with the statement.
 
1. Security Automation and Continuous Monitoring i= s not the best name for our present efforts, which are now focused on UC1 a= s described in the use case draft.
 
2. I believe a more suitable name is _____________= .
 
I'd like to close this poll by 17:00 PST on Decemb= er 19 (one week from today).
 
 
Regards,


Adam W. Montville | Security and Compliance Architect

Direct: = 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

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


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_CD48FE6D337F46938419B46FF454A532tripwirecom_-- From shanna@juniper.net Wed Dec 12 09:05:58 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2F721E80F0 for ; Wed, 12 Dec 2012 09:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtnsfSTS2wuY for ; Wed, 12 Dec 2012 09:05:56 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id ECF9021E80ED for ; Wed, 12 Dec 2012 09:05:55 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUMi5c5vRM055xYOmQ7VvQNQYmkeMzqr2@postini.com; Wed, 12 Dec 2012 09:05:55 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 09:02:39 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 12 Dec 2012 09:02:38 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.204) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 09:04:50 -0800 Received: from mail13-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 17:02:36 +0000 Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id 9492A160190 for ; Wed, 12 Dec 2012 17:02:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz9371Ic85fh1102I148cI11fbIzz1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 1355331753389300_31118; Wed, 12 Dec 2012 17:02:33 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.241]) by mail13-am1.bigfish.com (Postfix) with ESMTP id 5C34EA006A; Wed, 12 Dec 2012 17:02:33 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 17:02:31 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.140]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 17:02:31 +0000 From: Stephen Hanna To: Adam Montville , "sacm@ietf.org" Thread-Topic: SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULw Date: Wed, 12 Dec 2012 17:02:30 +0000 Message-ID: References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> In-Reply-To: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E068E3EE4SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TRIPWIRE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:05:58 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3EE4SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in ente= rprise networks today. If people agree, I would recommend changing your sec= ond requirement to add this at the end: "or brought and owned by end users"= . 2) Do we really need protocols for accessing a content repository for = UC1? Why? I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3EE4SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam,

 <= /p>

Thanks for putting togeth= er this initial list of requirements. This is a good start. I do have some = questions:

 <= /p>

1)  &= nbsp;   Is BYOD in scope?= I think it should be. It’s a fact of life in enterprise networks tod= ay. If people agree, I would recommend changing your second requirement to add this at the end: “or brought and owned by end use= rs”.

2) = ;     Do we really need= protocols for accessing a content repository for UC1? Why?

 <= /p>

I’m glad to see us = moving forward with this and other issues.

 <= /p>

Take care,

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SACM UC1 And Related Requirements<= /p>

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide coverage for enterprises of various sizes and include supp= ort for assets delivered by third-parties
  • Asset representation/identification should support those delivered by a giv= en Service Provider (SP)
  • Supporting data formats and/or protocols should support assessment of SP-pr= ovided assets
  • Must provide a method of defining a target system (asset identification; as= set classification)
  • Must provide a method of selecting acceptable state policy (test expression= )
  • Must provide a method of retrieving data collection instructions (activity = class: configuration, patch, vulnerability, inventory; object representatio= n; state representation)
  • Must provide a method of expressing state collection values (collection lan= guage: technical, interrogative; object representation)
  • Must provide a method of comparing actual to expected state values (test ev= aluation; test expression)
  • Must provide a protocol for connecting to a content repository containing S= ACM content
  • Must provide a protocol for querying SACM content held in a content reposit= ory
  • Must provide a protocol of retrieving SACM content from a content repositor= y
  • Must provide a protocol for curating SACM content in a content repository

 

In addition to the above, I would like to suggest th= at we take certain requirements from CSIS 20 Critical Security Controls = [1] under the following controls:

 

  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software<= /o:p>
  • Critical Control 3: Secure Configuration for Hardware and Software on Mobil= e Devices, Laptops, Workstations, and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Remediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Configurations for Network Devices such as Fire= walls, Routers, and Switches

 

 

I have not yet parsed through each of = the Critical Controls, but anticipate more detailed requirements to come ou= t of them.  I emphasize that we will not be seeking to meet every requ= irement expressed by a given Critical Control.  For example, we may not be in a position to express "authorizat= ions" for software installed on an operating system in a given context= .  But, Critical Control 2 does require accurate and meaningful asset = identification (as does Critical Control 1, for that matter), which is something with which we should be concerned.<= /p>

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 

--_000_F1DFC16DCAA7D3468651A5A776D5796E068E3EE4SN2PRD0510MB372_-- From amontville@tripwire.com Wed Dec 12 09:09:28 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032E221F88C4 for ; Wed, 12 Dec 2012 09:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOy+qJvY1gei for ; Wed, 12 Dec 2012 09:09:26 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2299821F88CA for ; Wed, 12 Dec 2012 09:09:25 -0800 (PST) Received: from mail167-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 17:09:19 +0000 Received: from mail167-tx2 (localhost [127.0.0.1]) by mail167-tx2-R.bigfish.com (Postfix) with ESMTP id 032CB160151 for ; Wed, 12 Dec 2012 17:09:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz98dI9371I9f17Rc85eh1102I148cI11fbIzz1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh18c673h18602ehz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2 (MessageSwitch) id 1355332156356105_9972; Wed, 12 Dec 2012 17:09:16 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.254]) by mail167-tx2.bigfish.com (Postfix) with ESMTP id 47D46A010E for ; Wed, 12 Dec 2012 17:09:16 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 17:09:15 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id C1CD6232122B for ; Wed, 12 Dec 2012 08:57:38 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 1D00F23211D0; Wed, 12 Dec 2012 08:57:38 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 12 Dec 2012 09:13:40 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Wed, 12 Dec 2012 09:09:13 -0800 From: Adam Montville To: Stephen Hanna Thread-Topic: SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgA= Date: Wed, 12 Dec 2012 17:09:12 +0000 Message-ID: <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_60E2C65A4BA944F08AE778F65A031ECBtripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 4774a586-6db1-47a1-bfa1-233c096b2dce X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:09:28 -0000 --_000_60E2C65A4BA944F08AE778F65A031ECBtripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It=92s a fact of life in en= terprise networks today. If people agree, I would recommend changing your s= econd requirement to add this at the end: =93or brought and owned by end us= ers=94. This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I=92m glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_60E2C65A4BA944F08AE778F65A031ECBtripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> wrote:

Adam,
 
Thanks for putting together this initial list of requirem= ents. This is a good start. I do have some questions:
 

1)      Is BYOD in scope? I think it should be. It=92s a fact of life in enterprise n= etworks today. If people agree, I would recommend changing your second requ= irement to add this at the end: =93or brought and owned by end users=94.


2)      Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

It seems to me that these are likely to be "light," but are neede= d.  How do we expect to get information from one place to the next wit= hout at least defining what an access API might look like, what supported t= ransport protocols exist for the given technology, and what identifiers to use, etc. 
 
I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response.
 
Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think.

 
I=92m glad to see us moving forward with this and other i= ssues.
 
Take care,
 
Steve
 
From:=  sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SA= CM UC1 And Related Requirements
 
All:
 
After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: 
 
  • UC1 must provide coverage for enterprises of various sizes and include supp= ort for assets delivered by third-parties
  • Asset representation/identification should support those delivered by a giv= en Service Provider (SP)
  • Supporting data formats and/or protocols should support assessment of SP-pr= ovided assets
  • Must provide a method of defining a target system (asset identification; as= set classification)
  • Must provide a method of retrieving data collection instructions (activity = class: configuration, patch, vulnerability, inventory; object representatio= n; state representation)
  • Must provide a method of expressing state collection values (collection lan= guage: technical, interrogative; object representation)
  • Must provide a method of comparing actual to expected state values (test ev= aluation; test expression)
  • Must provide a protocol for connecting to a content repository containing S= ACM content
  • Must provide a protocol for querying SACM content held in a content reposit= ory
  • Must provide a protocol of retrieving SACM content from a content repositor= y
  • Must provide a protocol for curating SACM content in a content repository
 
In addition to the above, I would like to suggest that we take certain requirements<= span class=3D"Apple-converted-space"> from CSIS 20 Critical Sec= urity Controls [1] under the following controls:
 
  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software<= /o:p>
  • Critical Control 3: Secure Configuration for Hardware and Software on Mobil= e Devices, Laptops, Workstations, and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Remediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Configurations for Network Devices such as Fire= walls, Routers, and Switches
 
 
I have not yet<= /i> parsed through each o= f the Critical Controls, but anticipate more detailed requirements to come = out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control. &= nbsp;For example, we may not be in a position to express "authorizatio= ns" for software installed on an operating system in a given context. =  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that = matter), which is something with which we should be concerned.
 
I have this Friday (12/14) dedicated to fleshing out these requirements. &n= bsp;If you have contributions to make, I respectfully request that you do s= o before then.
 
Regards,
 
Adam
 



Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_60E2C65A4BA944F08AE778F65A031ECBtripwirecom_-- From ggolovinsky@qualys.com Wed Dec 12 09:13:05 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5192221F88E6 for ; Wed, 12 Dec 2012 09:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+HZh0hgjMrD for ; Wed, 12 Dec 2012 09:13:04 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC06D21F88E4 for ; Wed, 12 Dec 2012 09:13:03 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so678568qca.31 for ; Wed, 12 Dec 2012 09:13:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:content-type:x-gm-message-state; bh=+5pGqsNbNe6crIFJ6KJ3C0vC1cfmq3a5dMCtv0cp3lE=; b=Tya2+LhZmwFatXFDOoDggHRJDAMOorkdWYd7IX2sv8N8wjoX9+6ySPvPuL86bkumC6 yAIr3KgsHBA/qRDCzRQl990bJW9FLBf7LJ3MFC/Uow3RxWoEL71t9R95Eq5D64pclbIP //vz08b/YGVqth6o3PyTQnwJKRU5aTTj4GEZdE7+WLg25Lupsvo7IsKBkuX3oRJshGxO VQR+f9N+8FG5t8bV3mrsT6mCulS/37qqkkMasCpkJ3mfM26RcPrhTFGsFcN6PuJc5roA K5OG85MCk3vK6yoHwouyBUlDp+L/dSxRX9SehNVcmCFk3pSv+goOm1Yrtad3jqWA9uWi vNzw== Received: by 10.49.74.198 with SMTP id w6mr4178611qev.57.1355332383117; Wed, 12 Dec 2012 09:13:03 -0800 (PST) From: Gene Golovinsky References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUc35wJva16S/1A1/2czVjnCTohgHkGF2tmXkO4EA= Date: Wed, 12 Dec 2012 09:13:02 -0800 Message-ID: To: Stephen Hanna , Adam Montville , sacm@ietf.org Content-Type: multipart/alternative; boundary=047d7bb04cf23f908704d0aae915 X-Gm-Message-State: ALoCoQkdf28qWTuycHtmQTuJ0dgXQd4tJrPwrEhIZcllyzYqREehw+HNT1Jk8e2weLvVh7hgJBMc Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:13:05 -0000 --047d7bb04cf23f908704d0aae915 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Adam, I would agree that BYOD is a part of everyday life today as are SP provided/supported assets. The question that I will ask in this case is it really part of SP or distinctly separate case. I actually think it is a separate case. So, I am in support of adding it, but not sure it is an addition to line #2 or a line #3 by itself. Cheers. --Gene *From:* sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Stephen Hanna *Sent:* Wednesday, December 12, 2012 09:03 AM *To:* Adam Montville; sacm@ietf.org *Subject:* Re: [sacm] SACM UC1 And Related Requirements Adam, Thanks for putting together this initial list of requirements. This is a good start. I do have some questions: 1) Is BYOD in scope? I think it should be. It=92s a fact of life in enterprise networks today. If people agree, I would recommend changing your second requirement to add this at the end: =93or brought and owned by end users=94. 2) Do we really need protocols for accessing a content repository for UC1? Why? I=92m glad to see us moving forward with this and other issues. Take care, Steve *From:* sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf Of *Adam Montville *Sent:* Tuesday, December 11, 2012 1:39 PM *To:* sacm@ietf.org *Subject:* [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far: - UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties - Asset representation/identification should support those delivered by a given Service Provider (SP) - Supporting data formats and/or protocols should support assessment of SP-provided assets - Must provide a method of defining a target system (asset identification; asset classification) - Must provide a method of selecting acceptable state policy (test expression) - Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation) - Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation) - Must provide a method of comparing actual to expected state values (test evaluation; test expression) - Must provide a protocol for connecting to a content repository containing SACM content - Must provide a protocol for querying SACM content held in a content repository - Must provide a protocol of retrieving SACM content from a content repository - Must provide a protocol for curating SACM content in a content repository In addition to the above, I would like to suggest that we take *certain requirements* from CSIS 20 Critical Security Controls [1] under the following controls: - Critical Control 1: Inventory of Authorized and Unauthorized Devices - Critical Control 2: Inventory of Authorized and Unauthorized Software - Critical Control 3: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers - Critical Control 4: Continuous Vulnerability Assessment and Remediatio= n - Critical Control 5: Malware Defenses - Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches I have *not yet* parsed through each of the Critical Controls, but anticipate more detailed requirements to come out of them. I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control. For example, we may not be in a position to express "authorizations" for software installed on an operating system in a given context. But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. If you have contributions to make, I respectfully request that you do so before then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ --047d7bb04cf23f908704d0aae915 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Ad= am, I would agree that BYOD is a part of everyday life today as are SP prov= ided/supported assets.

The question that I will = ask in this case is it really part of SP or distinctly separate case.

I actually think it is a = separate case.

So, I am in support of adding it, but not sure it is an addition to line #= 2 or a line #3 by itself.

=A0

=A0

Cheers.

--Gene

=A0

=A0

From: sacm-bounces@ietf.org [m= ailto:sacm-bounces@ietf.org] <= b>On Behalf Of Stephen Hanna
Sent: Wednesday, December 12, 2012 09:03 AM
To: Adam Montv= ille; sacm@ietf.org
Subject:= Re: [sacm] SACM UC1 And Related Requirements

=A0

Adam,

=A0

Thanks for putting togeth= er this initial list of requirements. This is a good start. I do have some = questions:

=A0

=A0= =A0=A0=A0=A0 Is BYOD in sco= pe? I think it should be. It=92s a fact of life in enterprise networks toda= y. If people agree, I would recommend changing your second requirement to a= dd this at the end: =93or brought and owned by end users=94.

= 2)=A0=A0=A0=A0=A0 Do we really need protocols f= or accessing a content repository for UC1? Why?

=A0

I=92m glad to see us moving forward = with this and other issues.

=A0

Take care,

=A0

Steve

=A0

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf O= f Adam Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SACM UC1 An= d Related Requirements

=A0

=

All:

=A0

After trolling through some of the SACM mailing list, and reviewing SACM= BoF minutes from IETF 85 and the current Use Case draft looking for requir= ements, and here's what I've pulled together so far:=A0

=A0

  • UC1 must provide coverage for enterprises of vario= us sizes and include support for assets delivered by third-parties
  • Asset representation/identification should support those delivered by a giv= en Service Provider (SP)
  • Supporting data = formats and/or protocols should support assessment of SP-provided assets
  • Must provide a method of defining a target sy= stem (asset identification; asset classification)
  • Must provide a method of selecting acceptable state policy (test e= xpression)
  • Must provide a method of retrieving data coll= ection instructions (activity class: configuration, patch, vulnerability, i= nventory; object representation; state representation)
  • Must provide a method of expressing state collection values (collection lan= guage: technical, interrogative; object representation)
  • Must provide a method of comparing actual to expected state = values (test evaluation; test expression)
  • Must provide a protocol for connecting to a c= ontent repository containing SACM content
  • Must provide a protocol for querying SACM content held in a content reposi= tory
  • Must provide a protocol of retrieving SACM co= ntent from a content repository
  • Must prov= ide a protocol for curating SACM content in a content repository
<= /div>

=A0

In add= ition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the foll= owing controls:

=A0

  • Critical Control 1: Inventory of Authorized and Un= authorized Devices
  • Critical Control 2: In= ventory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Configuration for = Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers=
  • Critical Control 4: Continuous Vulnerabi= lity Assessment and Remediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Configurations for Ne= twork Devices such as Firewalls, Routers, and Switches

=A0

=A0

I have not yet parsed through each of the Critical Con= trols, but anticipate more detailed requirements to come out of them. =A0I = emphasize that we will not be seeking to meet every requirement expressed b= y a given Critical Control. =A0For example, we may not be in a position to = express "authorizations" for software installed on an operating s= ystem in a given context. =A0But, Critical Control 2 does require accurate = and meaningful asset identification (as does Critical Control 1, for that m= atter), which is something with which we should be concerned.

=A0

= I have this Friday (12/14) dedicated to fleshing out these requirements. = =A0If you have contributions to make, I respectfully request that you do so= before then.

=A0

= Regards,

=A0

Adam

=A0

= =A0

--047d7bb04cf23f908704d0aae915-- From lnunez@mitre.org Wed Dec 12 09:14:32 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CA61F0CC2 for ; Wed, 12 Dec 2012 09:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmdebkjARHPo for ; Wed, 12 Dec 2012 09:14:29 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C5C1E21F88FD for ; Wed, 12 Dec 2012 09:14:28 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E6D7B1F08C4; Wed, 12 Dec 2012 12:14:27 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C42AC1F08B8; Wed, 12 Dec 2012 12:14:27 -0500 (EST) Received: from IMCMBX03.MITRE.ORG ([169.254.3.16]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 12:14:27 -0500 From: "Nunez, Luis K" To: Adam Montville , Stephen Hanna Thread-Topic: SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3sdgA== Date: Wed, 12 Dec 2012 17:14:26 +0000 Message-ID: References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> In-Reply-To: <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_FDCC719E8EC4714EBFDE8473009EF6EC99BAB5IMCMBX03MITREORG_" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:14:32 -0000 --_000_FDCC719E8EC4714EBFDE8473009EF6EC99BAB5IMCMBX03MITREORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are two distinctive focus areas. "Method" and "Protocol". To me the = protocol for repository should be a separate but parallel effort. * Must provide a protocol for connecting to a content repositor= y containing SACM content * Must provide a protocol for querying SACM content held in a c= ontent repository * Must provide a protocol of retrieving SACM content from a con= tent repository * Must provide a protocol for curating SACM content in a conten= t repository -ln From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in ente= rprise networks today. If people agree, I would recommend changing your sec= ond requirement to add this at the end: "or brought and owned by end users"= . This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and inclu= de support for assets delivered by third-parties * Asset representation/identification should support those delivered b= y a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment o= f SP-provided assets * Must provide a method of defining a target system (asset identificat= ion; asset classification) * Must provide a method of selecting acceptable state policy (test exp= ression) * Must provide a method of retrieving data collection instructions (ac= tivity class: configuration, patch, vulnerability, inventory; object repres= entation; state representation) * Must provide a method of expressing state collection values (collect= ion language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (= test evaluation; test expression) * Must provide a protocol for connecting to a content repository conta= ining SACM content * Must provide a protocol for querying SACM content held in a content = repository * Must provide a protocol of retrieving SACM content from a content re= pository * Must provide a protocol for curating SACM content in a content repos= itory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Softwar= e * Critical Control 3: Secure Configuration for Hardware and Software o= n Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediat= ion * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such = as Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_FDCC719E8EC4714EBFDE8473009EF6EC99BAB5IMCMBX03MITREORG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are two distinctive= focus areas.  “Method” and “Protocol”. To me = the protocol for repository should be a separate but parallel effort.

 <= /p>

•   =           Must provide a proto= col for connecting to a content repository containing SACM content

•   =           Must provide a proto= col for querying SACM content held in a content repository

•   =           Must provide a proto= col of retrieving SACM content from a content repository<= /p>

•   =           Must provide a proto= col for curating SACM content in a content repository

 <= /p>

-ln

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: sacm@ietf.org
Subject: Re: [sacm] SACM UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 = AM, Stephen Hanna <shanna@juniper.= net> wrote:



1)     =  Is BYOD in scope? I think it should be. It’s a fact of life in enterpri= se networks today. If people agree, I would recommend changing your second = requirement to add this at the end: “or brought and owned by end user= s”.

 

This change seems reasona= ble to me.  We can ensure we address the issue, and then leave it to o= rganizations using implementations of the standards/guidelines we produce a= s to how they want to apply the technology.

 



2)      = Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

 

It seems to me that these= are likely to be "light," but are needed.  How do we expect= to get information from one place to the next without at least defining wh= at an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc= . 

 

I don't think we need any= thing heavy, just enough to say: If you want to get assessment content, fin= d the content repository, and form your request like this, and you'll get y= our response.

 

Notionally, it's easy for= me to see a service-oriented interface using a REST API to get this type o= f thing done, but that's getting the cart before the horse, I think.



From: sacm-bounces@ietf.org= [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SA= CM UC1 And Related Requirements

 

All:

 

After trolling through so= me of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 an= d the current Use Case draft looking for requirements, and here's what I've= pulled together so far: 

 

·      UC1 must provide coverage for enterprises of= various sizes and include support for assets delivered by third-parties

·      Asset representation/identification should s= upport those delivered by a given Service Provider (SP)

·      Supporting data formats and/or protocols sho= uld support assessment of SP-provided assets

·      Must provide a method of defining a target s= ystem (asset identification; asset classification)

·      Must provide a method of selecting acceptabl= e state policy (test expression)

·      Must provide a method of retrieving data col= lection instructions (activity class: configuration, patch, vulnerability, = inventory; object representation; state representation)

·      Must provide a method of expressing state co= llection values (collection language: technical, interrogative; object repr= esentation)

·      Must provide a method of comparing actual to= expected state values (test evaluation; test expression)

·      Must provide a protocol for connecting to a = content repository containing SACM content

·      Must provide a protocol for querying SACM co= ntent held in a content repository

·      Must provide a protocol of retrieving SACM c= ontent from a content repository

·      Must provide a protocol for curating SACM co= ntent in a content repository

 

In addition to the above,= I would like to suggest that we take=  certain requirements from CSIS 20 Critical Security Controls [1] under the following controls:

 

·      Critical Control 1: Inventory of Authorized = and Unauthorized Devices

·      Critical Control 2: Inventory of Authorized = and Unauthorized Software

·      Critical Control 3: Secure Configuration for= Hardware and Software on Mobile Devices, Laptops, Workstations, and Server= s

·      Critical Control 4: Continuous Vulnerability= Assessment and Remediation

·      Critical Control 5: Malware Defenses

·      Critical Control 10: Secure Configurations f= or Network Devices such as Firewalls, Routers, and Switches

 

 

I have not yet parsed through each of the Critical Controls, = but anticipate more detailed requirements to come out of them.  I emphasize that we will not be seeking to meet every r= equirement expressed by a given Critical Control.  For example, we may= not be in a position to express "authorizations" for software in= stalled on an operating system in a given context.  But, Critical Control 2 does require accurate and meaningful asset identificati= on (as does Critical Control 1, for that matter), which is something with w= hich we should be concerned.

 

I have this Friday (12/14= ) dedicated to fleshing out these requirements.  If you have contribut= ions to make, I respectfully request that you do so before then.=

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

=  

 

 

--_000_FDCC719E8EC4714EBFDE8473009EF6EC99BAB5IMCMBX03MITREORG_-- From shanna@juniper.net Wed Dec 12 09:27:52 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185E421F8201 for ; Wed, 12 Dec 2012 09:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+aEs5J-r1AR for ; Wed, 12 Dec 2012 09:27:45 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53021F871A for ; Wed, 12 Dec 2012 09:27:45 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUMi+ipTBaUuDeKRIEZlaDklzSDJs0sx0@postini.com; Wed, 12 Dec 2012 09:27:45 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 09:24:48 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 12 Dec 2012 09:24:47 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.143) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 09:26:49 -0800 Received: from mail90-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 17:24:35 +0000 Received: from mail90-db3 (localhost [127.0.0.1]) by mail90-db3-R.bigfish.com (Postfix) with ESMTP id C92F6180089 for ; Wed, 12 Dec 2012 17:24:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -37 X-BigFish: PS-37(zz98dI9371Id6eah9f17Rc85fh1102I148cI1432I4015I11fbIzz1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh18c673h18602ehz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail90-db3 (localhost.localdomain [127.0.0.1]) by mail90-db3 (MessageSwitch) id 1355333073320395_26548; Wed, 12 Dec 2012 17:24:33 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.237]) by mail90-db3.bigfish.com (Postfix) with ESMTP id 4B62A32007D; Wed, 12 Dec 2012 17:24:33 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 17:24:32 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.140]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 17:24:32 +0000 From: Stephen Hanna To: Adam Montville Thread-Topic: SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgA== Date: Wed, 12 Dec 2012 17:24:31 +0000 Message-ID: References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> In-Reply-To: <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E068E3F92SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TRIPWIRE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:27:52 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3F92SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam Montville wrote: > > 2) Do we really need protocols for accessing a content repository = for UC1? Why? > > It seems to me that these are likely to be "light," but are needed. How = do we expect to get information from one place to the next without at least= defining what an access API might look like, what supported transport prot= ocols exist for the given technology, and what identifiers to use, etc. I understand why we want to have a standard protocol for conveying the targ= et system identification and data collection instructions to the data colle= ctor and for getting back the state values. I just don't understand why we = need a standard protocol for talking to a content repository for UC1. Maybe we have a different idea of how UC1 works. I think UC1 is saying that= one party (call it the "data requestor") asks a second party (call it the = "data collector") to gather data ("state values") relating to the security = of a third party (the "target system"). So we need standard protocols and d= ata formats that the data requestor can use when talking to the data collec= tor. To give a concrete example, the data requestor might say "Send me the = list of software installed on device 374629" and the data collector might r= espond with a list of installed software. With that model, the question of how the data collector gathers data about = the target system (through the NEA protocols or via WMI or SSH) is not our = problem. And how the data requestor determines the list of state values to = request is not our problem. Arguably, even the nature of the policies used = by the data requestor to determine whether it likes the state values may no= t be our problem. But I certainly don't see any need for content repository= protocols in this model. Do you have a different model for UC1? I realize that this is straying into= architecture somewhat but I don't think we'll be able to come up with a se= t of requirements unless we have a common model for what the actors in the = system are and how they interact to achieve the goals of the use case. Thanks, Steve From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in ente= rprise networks today. If people agree, I would recommend changing your sec= ond requirement to add this at the end: "or brought and owned by end users"= . This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_F1DFC16DCAA7D3468651A5A776D5796E068E3F92SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam Montville wrote:

> > 2)  &= nbsp;   Do we really need protocols for accessing a content repos= itory for UC1? Why?

> 

> It seems to me that = these are likely to be "light," but are needed.  How do we e= xpect to get information from one place to the next without at least defini= ng what an access API might look like, what supported transport protocols exi= st for the given technology, and what identifiers to use, etc.

 <= /p>

I understand why we want = to have a standard protocol for conveying the target system identification = and data collection instructions to the data collector and for getting back the state values. I just don’t understand why we ne= ed a standard protocol for talking to a content repository for UC1.

 <= /p>

Maybe we have a different= idea of how UC1 works. I think UC1 is saying that one party (call it the &= #8220;data requestor”) asks a second party (call it the “data collector”) to gather data (“state values”) relating to = the security of a third party (the “target system”). So we need= standard protocols and data formats that the data requestor can use when t= alking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on = device 374629” and the data collector might respond with a list of in= stalled software.

 <= /p>

With that model, the ques= tion of how the data collector gathers data about the target system (throug= h the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request = is not our problem. Arguably, even the nature of the policies used by the d= ata requestor to determine whether it likes the state values may not be our= problem. But I certainly don’t see any need for content repository protocols in this model.

 <= /p>

Do you have a different m= odel for UC1? I realize that this is straying into architecture somewhat bu= t I don’t think we’ll be able to come up with a set of requirem= ents unless we have a common model for what the actors in the system are and ho= w they interact to achieve the goals of the use case.

 <= /p>

Thanks,=


Steve

 <= /p>

From: Adam Mon= tville [mailto:amontville@tripwire.com]
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: sacm@ietf.org
Subject: Re: SACM UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> wrote:



Adam,

 <= /p>

Thanks for putting togeth= er this initial list of requirements. This is a good start. I do have some = questions:

 <= /p>

1)     =  Is BYOD in scope? I think it should be. It’s a fact of life in enterpri= se networks today. If people agree, I would recommend changing your second = requirement to add this at the end: “or brought and owned by end user= s”.

 

This change seems reasonable to me.  We can ens= ure we address the issue, and then leave it to organizations using implemen= tations of the standards/guidelines we produce as to how they want to apply= the technology.

 



2)  &nbs= p;   Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

 

It seems to me that these are likely to be "lig= ht," but are needed.  How do we expect to get information from on= e place to the next without at least defining what an access API might look= like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to= say: If you want to get assessment content, find the content repository, a= nd form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-orient= ed interface using a REST API to get this type of thing done, but that's ge= tting the cart before the horse, I think.



 <= /p>

I’m glad to see us = moving forward with this and other issues.

 <= /p>

Take care,

 <= /p>

Steve

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SA= CM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide = coverage for enterprises of various sizes and include support for assets de= livered by third-parties
  • Asset representation/identification should support t= hose delivered by a given Service Provider (SP)
  • Supporting data formats and/o= r protocols should support assessment of SP-provided assets
    • =
  • Must provide a me= thod of defining a target system (asset identification; asset classificatio= n)
  • Must provide a method of selecting acceptable state policy (test expressio= n)
  • Must provide a method of retrieving data collection instructions (activity= class: configuration, patch, vulnerability, inventory; object representati= on; state representation)
  • Must provide a method of expressing state collectio= n values (collection language: technical, interrogative; object representat= ion)
  • Must provide a method of comparing actual to expected state values (test= evaluation; test expression)
  • Must provide a protocol for connecting to a co= ntent repository containing SACM content
  • Must provide a protocol for querying= SACM content held in a content repository
  • Must provide a protocol of retriev= ing SACM content from a content repository
  • Must provide a protocol for curati= ng SACM content in a content repository

 

In addition to the above, I would like to suggest th= at we take certain = requirements from= CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control = 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inven= tory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Confi= guration for Hardware and Software on Mobile Devices, Laptops, Workstations= , and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Rem= ediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Confi= gurations for Network Devices such as Firewalls, Routers, and Switches=

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detaile= d requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given= Critical Control.  For example, we may not be in a position to expres= s "authorizations" for software installed on an operating system = in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Con= trol 1, for that matter), which is something with which we should be concer= ned.

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

 

 

 

--_000_F1DFC16DCAA7D3468651A5A776D5796E068E3F92SN2PRD0510MB372_-- From gunnar.engelbach@threatguard.com Wed Dec 12 09:29:14 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3D121F8746 for ; Wed, 12 Dec 2012 09:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOYqKcbG2Die for ; Wed, 12 Dec 2012 09:29:13 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4B36121F86F9 for ; Wed, 12 Dec 2012 09:29:13 -0800 (PST) Received: (qmail 6296 invoked from network); 12 Dec 2012 09:33:23 -0800 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Dec 2012 09:33:23 -0800 Message-ID: <50C8BEFA.2090607@ThreatGuard.com> Date: Wed, 12 Dec 2012 12:29:30 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 CC: sacm@ietf.org References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:29:14 -0000 Between SP-provided assets, BYOD, and the assets owned by the enterprise, is that likely to completely cover the scope of responsibility of the entity doing the security audit? More complete, I think, to make #2 a more general statement such as "...all other assets within the scope of responsibility, such as those provided by a Service Provider (SP) or those brought and owned by end users." As a note, the responsibility for performing the security assessment (or monitoring) of these devices may not be the responsibility of the enterprise, but it may still be responsible for tracking the assessment results, making it a case of being able to communicate the results of the security audit. --gun On 12/12/2012 12:13 PM, Gene Golovinsky wrote: > Adam, I would agree that BYOD is a part of everyday life today as are SP > provided/supported assets. > > The question that I will ask in this case is it really part of SP or > distinctly separate case. > > I actually think it is a separate case. > > So, I am in support of adding it, but not sure it is an addition to line > #2 or a line #3 by itself. > > Cheers. > > --Gene > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org ] *On Behalf > Of *Stephen Hanna > *Sent:* Wednesday, December 12, 2012 09:03 AM > *To:* Adam Montville; sacm@ietf.org > *Subject:* Re: [sacm] SACM UC1 And Related Requirements > > Adam, > > Thanks for putting together this initial list of requirements. This is a > good start. I do have some questions: > > 1)Is BYOD in scope? I think it should be. It’s a fact of life in > enterprise networks today. If people agree, I would recommend changing > your second requirement to add this at the end: “or brought and owned by > end users”. > > 2)Do we really need protocols for accessing a content repository for > UC1? Why? > > I’m glad to see us moving forward with this and other issues. > > Take care, > > Steve > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] *On Behalf Of *Adam Montville > *Sent:* Tuesday, December 11, 2012 1:39 PM > *To:* sacm@ietf.org > *Subject:* [sacm] SACM UC1 And Related Requirements > > All: > > After trolling through some of the SACM mailing list, and reviewing SACM > BoF minutes from IETF 85 and the current Use Case draft looking for > requirements, and here's what I've pulled together so far: > > * UC1 must provide coverage for enterprises of various sizes and > include support for assets delivered by third-parties > * Asset representation/identification should support those delivered > by a given Service Provider (SP) > * Supporting data formats and/or protocols should support assessment > of SP-provided assets > * Must provide a method of defining a target system (asset > identification; asset classification) > * Must provide a method of selecting acceptable state policy (test > expression) > * Must provide a method of retrieving data collection instructions > (activity class: configuration, patch, vulnerability, inventory; > object representation; state representation) > * Must provide a method of expressing state collection values > (collection language: technical, interrogative; object representation) > * Must provide a method of comparing actual to expected state values > (test evaluation; test expression) > * Must provide a protocol for connecting to a content repository > containing SACM content > * Must provide a protocol for querying SACM content held in a content > repository > * Must provide a protocol of retrieving SACM content from a content > repository > * Must provide a protocol for curating SACM content in a content > repository > > In addition to the above, I would like to suggest that we take /_certain > requirements_/ from CSIS 20 Critical Security Controls [1] under the > following controls: > > * Critical Control 1: Inventory of Authorized and Unauthorized Devices > * Critical Control 2: Inventory of Authorized and Unauthorized Software > * Critical Control 3: Secure Configuration for Hardware and Software > on Mobile Devices, Laptops, Workstations, and Servers > * Critical Control 4: Continuous Vulnerability Assessment and Remediation > * Critical Control 5: Malware Defenses > * Critical Control 10: Secure Configurations for Network Devices such > as Firewalls, Routers, and Switches > > I have /_not yet_/ parsed through each of the Critical Controls, but > anticipate more detailed requirements to come out of them. I emphasize > that we will not be seeking to meet every requirement expressed by a > given Critical Control. For example, we may not be in a position to > express "authorizations" for software installed on an operating system > in a given context. But, Critical Control 2 does require accurate and > meaningful asset identification (as does Critical Control 1, for that > matter), which is something with which we should be concerned. > > I have this Friday (12/14) dedicated to fleshing out these requirements. > If you have contributions to make, I respectfully request that you do > so before then. > > Regards, > > Adam > > [1] http://www.sans.org/critical-security-controls/ > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From gunnar.engelbach@threatguard.com Wed Dec 12 09:38:42 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B2421E80E2 for ; Wed, 12 Dec 2012 09:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85SYNJech0dt for ; Wed, 12 Dec 2012 09:38:41 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 262CC21E805A for ; Wed, 12 Dec 2012 09:38:41 -0800 (PST) Received: (qmail 6507 invoked from network); 12 Dec 2012 09:42:52 -0800 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Dec 2012 09:42:51 -0800 Message-ID: <50C8C133.9040805@ThreatGuard.com> Date: Wed, 12 Dec 2012 12:38:59 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 CC: "sacm@ietf.org" References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> In-Reply-To: <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:38:42 -0000 On 12/12/2012 12:09 PM, Adam Montville wrote: > > On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: > >> Adam, >> Thanks for putting together this initial list of requirements. This is >> a good start. I do have some questions: >> >> 1)Is BYOD in scope? I think it should be. It’s a fact of life in >> enterprise networks today. If people agree, I would recommend changing >> your second requirement to add this at the end: “or brought and owned >> by end users”. >> > > This change seems reasonable to me. We can ensure we address the issue, > and then leave it to organizations using implementations of the > standards/guidelines we produce as to how they want to apply the technology. > > >> 2)Do we really need protocols for accessing a content repository for >> UC1? Why? Strictly speaking, no, this isn't needed if you are just looking at the minimal subset for doing the security assessments. In a practical sense, however, when it comes to implementing the resultant standards, access to the content in some manner will be necessary. If that access is not defined the result will be proprietary solutions that must be later replaced as the scope of SACM grows. I'm not saying that's either good or bad, just the tradeoff. > > It seems to me that these are likely to be "light," but are needed. How > do we expect to get information from one place to the next without at > least defining what an access API might look like, what supported > transport protocols exist for the given technology, and what identifiers > to use, etc. > I don't think we need anything heavy, just enough to say: If you want to > get assessment content, find the content repository, and form your > request like this, and you'll get your response. > Notionally, it's easy for me to see a service-oriented interface using a > REST API to get this type of thing done, but that's getting the cart > before the horse, I think. > >> I’m glad to see us moving forward with this and other issues. >> Take care, >> Steve >> *From:*sacm-bounces@ietf.org >> [mailto:sacm-bounces@ietf.org ]*On Behalf >> Of*Adam Montville >> *Sent:*Tuesday, December 11, 2012 1:39 PM >> *To:*sacm@ietf.org >> *Subject:*[sacm] SACM UC1 And Related Requirements >> All: >> After trolling through some of the SACM mailing list, and reviewing >> SACM BoF minutes from IETF 85 and the current Use Case draft looking >> for requirements, and here's what I've pulled together so far: >> >> * UC1 must provide coverage for enterprises of various sizes and >> include support for assets delivered by third-parties >> * Asset representation/identification should support those delivered >> by a given Service Provider (SP) >> * Supporting data formats and/or protocols should support assessment >> of SP-provided assets >> * Must provide a method of defining a target system (asset >> identification; asset classification) >> * Must provide a method of selecting acceptable state policy (test >> expression) >> * Must provide a method of retrieving data collection instructions >> (activity class: configuration, patch, vulnerability, inventory; >> object representation; state representation) >> * Must provide a method of expressing state collection values >> (collection language: technical, interrogative; object representation) >> * Must provide a method of comparing actual to expected state values >> (test evaluation; test expression) >> * Must provide a protocol for connecting to a content repository >> containing SACM content >> * Must provide a protocol for querying SACM content held in a >> content repository >> * Must provide a protocol of retrieving SACM content from a content >> repository >> * Must provide a protocol for curating SACM content in a content >> repository >> >> In addition to the above, I would like to suggest that we >> take/_certain requirements_/from CSIS 20 Critical Security Controls >> [1] under the following controls: >> >> * Critical Control 1: Inventory of Authorized and Unauthorized Devices >> * Critical Control 2: Inventory of Authorized and Unauthorized Software >> * Critical Control 3: Secure Configuration for Hardware and Software >> on Mobile Devices, Laptops, Workstations, and Servers >> * Critical Control 4: Continuous Vulnerability Assessment and >> Remediation >> * Critical Control 5: Malware Defenses >> * Critical Control 10: Secure Configurations for Network Devices >> such as Firewalls, Routers, and Switches >> >> I have/_not yet_/parsed through each of the Critical Controls, but >> anticipate more detailed requirements to come out of them. I >> emphasize that we will not be seeking to meet every requirement >> expressed by a given Critical Control. For example, we may not be in >> a position to express "authorizations" for software installed on an >> operating system in a given context. But, Critical Control 2 does >> require accurate and meaningful asset identification (as does Critical >> Control 1, for that matter), which is something with which we should >> be concerned. >> I have this Friday (12/14) dedicated to fleshing out these >> requirements. If you have contributions to make, I respectfully >> request that you do so before then. >> Regards, >> Adam >> [1] http://www.sans.org/critical-security-controls/ >> > > * > Adam W. Montville *| Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > / > /*TRIPWIRE*|CONFIDENCE:*SECURED* > www.tripwire.com > > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From dwhitejr@cisco.com Wed Dec 12 11:24:28 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B4F21E8124 for ; Wed, 12 Dec 2012 11:24:27 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zsQE+LkbcNG for ; Wed, 12 Dec 2012 11:24:26 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF0F21E811D for ; Wed, 12 Dec 2012 11:24:25 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBCJOI5c004250; Wed, 12 Dec 2012 14:24:18 -0500 (EST) Received: from [127.0.0.1] (dwhitejr-pc.cisco.com [172.18.254.199]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBCJOHa4005957; Wed, 12 Dec 2012 14:24:17 -0500 (EST) Message-ID: <50C8D9E0.20101@cisco.com> Date: Wed, 12 Dec 2012 14:24:16 -0500 From: "David White, Jr. (dwhitejr)" Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adam Montville References: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> In-Reply-To: <4991FB2E-5A12-4E0C-BA52-A85393B8F63A@tripwire.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------040303050608050101020402" Cc: "sacm@ietf.org" Subject: Re: [sacm] POLL: SACM Name Change X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dwhitejr@cisco.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:24:28 -0000 This is a multi-part message in MIME format. --------------040303050608050101020402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I vote to table the name change for now and focus on the requirements. Sincerely, David White. On 12/12/2012 9:42 AM, Adam Montville wrote: > All: > > Hopefully I'm not out of bounds on this one, but it appears that our > scoping efforts have rekindled the group naming debate. I'd like to > propose that we handle this overhead efficiently by conducting this > poll. > > There is one statement with which you may or may not agree (number 1 > below), and a follow on "suggestion" space (number 2 below) if you > *do* agree with the statement. > > 1. Security Automation and Continuous Monitoring is not the best name > for our present efforts, which are now focused on UC1 as described in > the use case draft. > > 2. I believe a more suitable name is _____________ . > > I'd like to close this poll by 17:00 PST on December 19 (one week from > today). > > > Regards, > > * > Adam W. Montville *| Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > / > /*TRIPWIRE* | CONFIDENCE: *SECURED* > www.tripwire.com > > > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --------------040303050608050101020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I vote to table the name change for now and focus on the requirements.

Sincerely,

David White.

On 12/12/2012 9:42 AM, Adam Montville wrote:
All:

Hopefully I'm not out of bounds on this one, but it appears that our scoping efforts have rekindled the group naming debate.  I'd like to propose that we handle this overhead efficiently by conducting this poll.  

There is one statement with which you may or may not agree (number 1 below), and a follow on "suggestion" space (number 2 below) if you *do* agree with the statement.

1. Security Automation and Continuous Monitoring is not the best name for our present efforts, which are now focused on UC1 as described in the use case draft.

2. I believe a more suitable name is _____________ .

I'd like to close this poll by 17:00 PST on December 19 (one week from today).


Regards,


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com






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

--------------040303050608050101020402-- From bchandra@secpod.com Wed Dec 12 22:32:33 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736B821F8552 for ; Wed, 12 Dec 2012 22:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeLYgBUU+eV8 for ; Wed, 12 Dec 2012 22:32:28 -0800 (PST) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8483021F854C for ; Wed, 12 Dec 2012 22:32:28 -0800 (PST) Received: from [182.72.99.242] (port=1641 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tj2LJ-00012K-3l; Thu, 13 Dec 2012 12:02:27 +0530 From: "Chandrashekhar B" To: "'Stephen Hanna'" , "'Adam Montville'" References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> In-Reply-To: Date: Thu, 13 Dec 2012 12:02:17 +0530 Organization: SecPod Technologies Message-ID: <012001cdd8fb$9b5df770$d219e650$@secpod.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0121_01CDD929.B5201E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUc35wJva16S/1A1/2czVjnCTohgHkGF2tAwJOW2UB8vmwQplSPlSg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Get-Message-Sender-Via: cpanel23.interactivedns.com: authenticated_id: bchandra@secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 06:32:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0121_01CDD929.B5201E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the target system identification and data collection instructions to the data collector and for getting back the state values. I just don't understand why we need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying that one party (call it the "data requestor") asks a second party (call it the "data collector") to gather data ("state values") relating to the security of a third party (the "target system"). So we need standard protocols and data formats that the data requestor can use when talking to the data collector. To give a concrete example, the data requestor might say "Send me the list of software installed on device 374629" and the data collector might respond with a list of installed software. >With that model, the question of how the data collector gathers data about the target system (through the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not our problem. Arguably, even the nature of the policies used by the data requestor to determine whether it likes the state values may not be our problem. But I certainly don't see any need for content repository protocols in this model. >Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don't think we'll be able to come up with a set of requirements unless we have a common model for what the actors in the system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna wrote: Adam, Thanks for putting together this initial list of requirements. This is a good start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in enterprise networks today. If people agree, I would recommend changing your second requirement to add this at the end: "or brought and owned by end users". This change seems reasonable to me. We can ensure we address the issue, and then leave it to organizations using implementations of the standards/guidelines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for UC1? Why? It seems to me that these are likely to be "light," but are needed. How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to get assessment content, find the content repository, and form your request like this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a REST API to get this type of thing done, but that's getting the cart before the horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties * Asset representation/identification should support those delivered by a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of SP-provided assets * Must provide a method of defining a target system (asset identification; asset classification) * Must provide a method of selecting acceptable state policy (test expression) * Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation) * Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (test evaluation; test expression) * Must provide a protocol for connecting to a content repository containing SACM content * Must provide a protocol for querying SACM content held in a content repository * Must provide a protocol of retrieving SACM content from a content repository * Must provide a protocol for curating SACM content in a content repository In addition to the above, I would like to suggest that we take certain requirements from CSIS 20 Critical Security Controls [1] under the following controls: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediation * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate more detailed requirements to come out of them. I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control. For example, we may not be in a position to express "authorizations" for software installed on an operating system in a given context. But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. If you have contributions to make, I respectfully request that you do so before then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 ------=_NextPart_000_0121_01CDD929.B5201E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Adam Montville wrote:

>> > 2)      Do we really need = protocols for accessing a content repository for UC1? = Why?

>> 

>> It seems to me that these are likely to be "light," = but are needed.  How do we expect to get information from one place = to the next without at least defining what an access API might look = like, what supported transport protocols exist for the given technology, = and what identifiers to use, etc.

 

> I understand why we want to have a standard protocol for conveying = the target system identification and data collection instructions to the = data collector and for getting back the state values. I just don’t = understand why we need a standard protocol for talking to a content = repository for UC1.

 

>Maybe we have a different idea of how UC1 works. I think UC1 is = saying that one party (call it the “data requestor”) asks a = second party (call it the “data collector”) to gather data = (“state values”) relating to the security of a third party = (the “target system”). So we need standard protocols and = data formats that the data requestor can use when talking to the data = collector. To give a concrete example, the data requestor might say = “Send me the list of software installed on device 374629” = and the data collector might respond with a list of installed = software.

 

>With that model, the question of how the data collector gathers data = about the target system (through the NEA protocols or via WMI or SSH) is = not our problem. And how the data requestor determines the list of state = values to request is not our problem. Arguably, even the nature of the = policies used by the data requestor to determine whether it likes the = state values may not be our problem. But I certainly don’t see any = need for content repository protocols in this = model.

 

>Do you have a different model for UC1? I realize that this is = straying into architecture somewhat but I don’t think we’ll = be able to come up with a set of requirements unless we have a common = model for what the actors in the system are and how they interact to = achieve the goals of the use case.

 

Data collector needs to have the assessment content for performing = the task the data requestor asked for. This is 4.1.4 from use case = document.

 

Chandra.

 

 

 

 

On = Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> = wrote:

 

Adam,

 

Thanks for putting together this initial list of requirements. This = is a good start. I do have some = questions:

 

1)      Is BYOD in scope? I think it should be. It’s a fact of life in = enterprise networks today. If people agree, I would recommend changing = your second requirement to add this at the end: “or brought and = owned by end users”.

 

This change seems reasonable to me.  We can = ensure we address the issue, and then leave it to organizations using = implementations of the standards/guidelines we produce as to how they = want to apply the technology.

 

 

2)      Do we really need protocols for accessing a content repository for = UC1? Why?

 

It seems to me that these are likely to be = "light," but are needed.  How do we expect to get = information from one place to the next without at least defining what an = access API might look like, what supported transport protocols exist for = the given technology, and what identifiers to use, = etc. 

 

I don't think we need anything heavy, just enough to = say: If you want to get assessment content, find the content repository, = and form your request like this, and you'll get your = response.

 

Notionally, it's easy for me to see a service-oriented = interface using a REST API to get this type of thing done, but that's = getting the cart before the horse, I = think.

 

 

I’m glad to see us moving forward with this and other = issues.

 

Take care,

 

Steve

 

From:=  sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of Adam = Montville
Sent: Tuesday, December 11, 2012 = 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SACM UC1 And Related = Requirements

 

All:

 

After trolling through some of the SACM mailing list, = and reviewing SACM BoF minutes from IETF 85 and the current Use Case = draft looking for requirements, and here's what I've pulled together so = far: 

 

  • UC1 must provide coverage for = enterprises of various sizes and include support for assets delivered by = third-parties
  • Asset representation/identification should support those = delivered by a given Service Provider (SP)
  • Supporting data = formats and/or protocols should support assessment of SP-provided = assets
  • Must provide a method of defining a target system (asset = identification; asset classification)
  • Must provide a = method of selecting acceptable state policy (test = expression)
  • Must provide a method of retrieving data collection = instructions (activity class: configuration, patch, vulnerability, = inventory; object representation; state = representation)
  • Must provide a method of expressing = state collection values (collection language: technical, interrogative; = object representation)
  • Must provide a method of comparing = actual to expected state values (test evaluation; test = expression)
  • Must provide a protocol for connecting to a content = repository containing SACM content
  • Must provide a protocol for querying = SACM content held in a content repository
  • Must provide a = protocol of retrieving SACM content from a content = repository
  • Must provide a protocol for curating SACM content in a = content repository

 

In addition to the above, I would like to suggest that = we take certain = requirements from CSIS 20 Critical = Security Controls [1] under the following = controls:

 

  • Critical Control 1: Inventory of = Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of = Authorized and Unauthorized Software
  • Critical Control 3: = Secure Configuration for Hardware and Software on Mobile Devices, = Laptops, Workstations, and Servers
  • Critical Control 4: Continuous = Vulnerability Assessment and Remediation
  • Critical Control 5: = Malware Defenses
  • Critical Control 10: Secure = Configurations for Network Devices such as Firewalls, Routers, and = Switches

 

 

I have not yet parsed through each of the = Critical Controls, but anticipate more detailed requirements to come out = of them.  I emphasize that we will not be seeking to meet every = requirement expressed by a given Critical Control.  For example, we = may not be in a position to express "authorizations" for = software installed on an operating system in a given context.  But, = Critical Control 2 does require accurate and meaningful asset = identification (as does Critical Control 1, for that matter), which is = something with which we should be = concerned.

 

I have this Friday (12/14) dedicated to fleshing out = these requirements.  If you have contributions to make, I = respectfully request that you do so before = then.

 

Regards,

 

Adam

 

 

=
Adam W. Montville = | Security and Compliance Architect

= Direct: 503 276-7661
Mobile: 360 471-7815   =  

<= br>TR= IPWIRE&n= bsp;|<= span class=3Dapple-converted-space> CONFIDE= NCE:<= span class=3Dapple-converted-space> SECURED
www.tripwire.com<= /p>

 

 

 

No virus = found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / = Virus Database: 2634/5953 - Release Date: = 12/12/12

------=_NextPart_000_0121_01CDD929.B5201E80-- From bchandra@secpod.com Thu Dec 13 05:47:56 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14AB21F89B7 for ; Thu, 13 Dec 2012 05:47:56 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uatf0MfiIJ35 for ; Thu, 13 Dec 2012 05:47:55 -0800 (PST) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66121F887A for ; Thu, 13 Dec 2012 05:47:55 -0800 (PST) Received: from [182.72.99.242] (port=1547 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tj98k-0000Cf-48; Thu, 13 Dec 2012 19:17:54 +0530 From: "Chandrashekhar B" To: "'Adam Montville'" , "'Stephen Hanna'" References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> In-Reply-To: <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> Date: Thu, 13 Dec 2012 19:17:46 +0530 Organization: SecPod Technologies Message-ID: <01ae01cdd938$711749c0$5345dd40$@secpod.com> 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: AQEUc35wJva16S/1A1/2czVjnCTohgHkGF2tAwJOW2WZYdbQ4A== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Get-Message-Sender-Via: cpanel23.interactivedns.com: authenticated_id: bchandra@secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:47:56 -0000 > 2)=A0=A0=A0=A0=A0=A0Do we really need protocols for accessing a = content repository for UC1? Why? >It seems to me that these are likely to be "light," but are needed. = =A0How do we expect to get information from >one place to the next without at = least defining what an access API might look like, what supported transport >protocols exist for the given technology, and what identifiers to use, etc.=A0 =A0 >I don't think we need anything heavy, just enough to say: If you want = to get assessment content, find the content >repository, and form your = request like this, and you'll get your response. =A0 >Notionally, it's easy for me to see a service-oriented interface using = a REST API to get this type of thing done, >but that's getting the cart = before the horse, I think. Yes, we see the same too, interface for SCAP Repo is REST based: https://www.scaprepo.com/SCAPRepoWebService=20 Chandra. =A0 From:=A0sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org]=A0On Behalf = Of=A0Adam Montville Sent:=A0Tuesday, December 11, 2012 1:39 PM To:=A0sacm@ietf.org Subject:=A0[sacm] SACM UC1 And Related Requirements =A0 All: =A0 After trolling through some of the SACM mailing list, and reviewing SACM = BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far:=A0 =A0 =95 UC1 must provide coverage for enterprises of various sizes and = include support for assets delivered by third-parties =95 Asset representation/identification should support those delivered = by a given Service Provider (SP) =95 Supporting data formats and/or protocols should support assessment = of SP-provided assets =95 Must provide a method of defining a target system (asset = identification; asset classification) =95 Must provide a method of selecting acceptable state policy (test expression) =95 Must provide a method of retrieving data collection instructions = (activity class: configuration, patch, vulnerability, inventory; object representation; state representation) =95 Must provide a method of expressing state collection values = (collection language: technical, interrogative; object representation) =95 Must provide a method of comparing actual to expected state values = (test evaluation; test expression) =95 Must provide a protocol for connecting to a content repository = containing SACM content =95 Must provide a protocol for querying SACM content held in a content repository =95 Must provide a protocol of retrieving SACM content from a content repository =95 Must provide a protocol for curating SACM content in a content = repository =A0 In addition to the above, I would like to suggest that we take=A0certain requirements=A0from CSIS 20 Critical Security Controls [1] under the = following controls: =A0 =95 Critical Control 1: Inventory of Authorized and Unauthorized Devices =95 Critical Control 2: Inventory of Authorized and Unauthorized = Software =95 Critical Control 3: Secure Configuration for Hardware and Software = on Mobile Devices, Laptops, Workstations, and Servers =95 Critical Control 4: Continuous Vulnerability Assessment and = Remediation =95 Critical Control 5: Malware Defenses =95 Critical Control 10: Secure Configurations for Network Devices such = as Firewalls, Routers, and Switches =A0 =A0 I have=A0not yet=A0parsed through each of the Critical Controls, but = anticipate more detailed requirements to come out of them. =A0I emphasize that we = will not be seeking to meet every requirement expressed by a given Critical Control. =A0For example, we may not be in a position to express "authorizations" for software installed on an operating system in a = given context. =A0But, Critical Control 2 does require accurate and meaningful = asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned. =A0 I have this Friday (12/14) dedicated to fleshing out these requirements. = =A0If you have contributions to make, I respectfully request that you do so = before then. =A0 Regards, =A0 Adam =A0 [1]=A0http://www.sans.org/critical-security-controls/ Adam W. Montville=A0| Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 =A0 =A0 TRIPWIRE=A0|=A0CONFIDENCE:=A0SECURED www.tripwire.com ________________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: = 12/12/12 From shanna@juniper.net Thu Dec 13 05:51:21 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B021F8AE0 for ; Thu, 13 Dec 2012 05:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 458et-WymcIr for ; Thu, 13 Dec 2012 05:51:16 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCD21F8ADE for ; Thu, 13 Dec 2012 05:51:16 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUMndVGtPFUwceDyObF9Kz9fHsobDn0jZ@postini.com; Thu, 13 Dec 2012 05:51:16 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 05:51:01 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 05:51:00 -0800 Received: from TX2EHSOBE001.bigfish.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 05:53:10 -0800 Received: from mail20-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 13:50:59 +0000 Received: from mail20-tx2 (localhost [127.0.0.1]) by mail20-tx2-R.bigfish.com (Postfix) with ESMTP id 96D83360150 for ; Thu, 13 Dec 2012 13:50:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -38 X-BigFish: PS-38(zzbb2dI98dI9371Id6eah9f17Rc85fh1102I148cI1432I4015I11fbIzz1de0h1202h1e76h1d1ah1d2ahzz8275ch18c673h17326ah18602eh8275bh8275dh1033IL1954cbhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail20-tx2 (localhost.localdomain [127.0.0.1]) by mail20-tx2 (MessageSwitch) id 1355406654706898_15608; Thu, 13 Dec 2012 13:50:54 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.247]) by mail20-tx2.bigfish.com (Postfix) with ESMTP id A8D12200084; Thu, 13 Dec 2012 13:50:54 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 13:50:54 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.140]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0245.002; Thu, 13 Dec 2012 13:50:53 +0000 From: Stephen Hanna To: "bchandra@secpod.com" , 'Adam Montville' Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIAA4CiAgABN58A= Date: Thu, 13 Dec 2012 13:50:52 +0000 Message-ID: References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> In-Reply-To: <012001cdd8fb$9b5df770$d219e650$@secpod.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E068E4DA2SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%SECPOD.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TRIPWIRE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:51:22 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E4DA2SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chandra wrote: > Data collector needs to have the assessment content for performing the ta= sk > the data requestor asked for. This is 4.1.4 from use case document. Perhaps. If the communications between the data requestor and the data coll= ector included all the necessary content, this interaction could take place= without needing a separate content repository. Maybe this would not be eff= icient so it's desirable to use references to content instead of sending th= e content itself. Is this true? Thanks, Steve From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository= for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How= do we expect to get information from one place to the next without at leas= t defining what an access API might look like, what supported transport pro= tocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the ta= rget system identification and data collection instructions to the data col= lector and for getting back the state values. I just don't understand why w= e need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying tha= t one party (call it the "data requestor") asks a second party (call it the= "data collector") to gather data ("state values") relating to the security= of a third party (the "target system"). So we need standard protocols and = data formats that the data requestor can use when talking to the data colle= ctor. To give a concrete example, the data requestor might say "Send me the= list of software installed on device 374629" and the data collector might = respond with a list of installed software. >With that model, the question of how the data collector gathers data about= the target system (through the NEA protocols or via WMI or SSH) is not our= problem. And how the data requestor determines the list of state values to= request is not our problem. Arguably, even the nature of the policies used= by the data requestor to determine whether it likes the state values may n= ot be our problem. But I certainly don't see any need for content repositor= y protocols in this model. >Do you have a different model for UC1? I realize that this is straying int= o architecture somewhat but I don't think we'll be able to come up with a s= et of requirements unless we have a common model for what the actors in the= system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task= the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in ente= rprise networks today. If people agree, I would recommend changing your sec= ond requirement to add this at the end: "or brought and owned by end users"= . This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E4DA2SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chandra wrote:=

> Data collector needs= to have the assessment content for performing the task

> the data requestor a= sked for. This is 4.1.4 from use case document.

 <= /p>

Perhaps. If the communica= tions between the data requestor and the data collector= included all the necessary content, this interaction could take place without needing a separate content repository= . Maybe this would not be efficient so it’s desirable to use referenc= es to content instead of sending the content itself. Is this true?

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: Chandras= hekhar B [mailto:bchandra@secpod.com]
Sent: Thursday, December 13, 2012 1:32 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Adam Montville wrote:=

>> > 2) &nb= sp;    Do we really need protocols for accessing a content r= epository for UC1? Why?

>> =

>> It seems to me t= hat these are likely to be "light," but are needed.  How do = we expect to get information from one place to the next without at least de= fining what an access API might look like, what supported transport protocols exi= st for the given technology, and what identifiers to use, etc.

 <= /p>

> I understand why we = want to have a standard protocol for conveying the target system identifica= tion and data collection instructions to the data collector and for getting back the state values. I just don’t understand why w= e need a standard protocol for talking to a content repository for UC1.

 <= /p>

>Maybe we have a diffe= rent idea of how UC1 works. I think UC1 is saying that one party (call it t= he “data requestor”) asks a second party (call it the “da= ta collector”) to gather data (“state values”) relating to = the security of a third party (the “target system”). So we need= standard protocols and data formats that the data requestor can use when t= alking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on = device 374629” and the data collector might respond with a list of in= stalled software.

 <= /p>

>With that model, the = question of how the data collector gathers data about the target system (th= rough the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request = is not our problem. Arguably, even the nature of the policies used by the d= ata requestor to determine whether it likes the state values may not be our= problem. But I certainly don’t see any need for content repository protocols in this model.

 <= /p>

>Do you have a differe= nt model for UC1? I realize that this is straying into architecture somewha= t but I don’t think we’ll be able to come up with a set of requirements unless we have a common model for what the actors in the syst= em are and how they interact to achieve the goals of the use case.

 <= /p>

Data collector needs to h= ave the assessment content for performing the task the data requestor asked= for. This is 4.1.4 from use case document.

 <= /p>

Chandra.

 <= /p>

 <= /p>

From: Adam Mon= tville [mailto:amontville@tripwi= re.com]
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: sacm@ietf.org
Subject: Re: SACM UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> wrote:

 

Adam,

 <= /p>

Thanks for putting togeth= er this initial list of requirements. This is a good start. I do have some = questions:

 <= /p>

1)     =  Is BYOD in scope? I think it should be. It’s a fact of life in enterpri= se networks today. If people agree, I would recommend changing your second = requirement to add this at the end: “or brought and owned by end user= s”.

 

This change seems reasonable to me.  We can ens= ure we address the issue, and then leave it to organizations using implemen= tations of the standards/guidelines we produce as to how they want to apply= the technology.

 

 

2)  &nbs= p;   Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

 

It seems to me that these are likely to be "lig= ht," but are needed.  How do we expect to get information from on= e place to the next without at least defining what an access API might look= like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to= say: If you want to get assessment content, find the content repository, a= nd form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-orient= ed interface using a REST API to get this type of thing done, but that's ge= tting the cart before the horse, I think.

 

 <= /p>

I’m glad to see us = moving forward with this and other issues.

 <= /p>

Take care,

 <= /p>

Steve

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SA= CM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide = coverage for enterprises of various sizes and include support for assets de= livered by third-parties
  • Asset representation/identification should support t= hose delivered by a given Service Provider (SP)
  • Supporting data formats and/o= r protocols should support assessment of SP-provided assets
    • =
  • Must provide a me= thod of defining a target system (asset identification; asset classificatio= n)
  • Must provide a method of selecting acceptable state policy (test expressio= n)
  • Must provide a method of retrieving data collection instructions (activity= class: configuration, patch, vulnerability, inventory; object representati= on; state representation)
  • Must provide a method of expressing state collectio= n values (collection language: technical, interrogative; object representat= ion)
  • Must provide a method of comparing actual to expected state values (test= evaluation; test expression)
  • Must provide a protocol for connecting to a co= ntent repository containing SACM content
  • Must provide a protocol for querying= SACM content held in a content repository
  • Must provide a protocol of retriev= ing SACM content from a content repository
  • Must provide a protocol for curati= ng SACM content in a content repository

 

In addition to the above, I would like to suggest th= at we take certain = requirements from= CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control = 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inven= tory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Confi= guration for Hardware and Software on Mobile Devices, Laptops, Workstations= , and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Rem= ediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Confi= gurations for Network Devices such as Firewalls, Routers, and Switches=

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detaile= d requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given= Critical Control.  For example, we may not be in a position to expres= s "authorizations" for software installed on an operating system = in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Con= trol 1, for that matter), which is something with which we should be concer= ned.

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

 

 

 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

--_000_F1DFC16DCAA7D3468651A5A776D5796E068E4DA2SN2PRD0510MB372_-- From bchandra@secpod.com Thu Dec 13 06:47:17 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D2C21F8AD0 for ; Thu, 13 Dec 2012 06:47:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHdmiqtDGYUU for ; Thu, 13 Dec 2012 06:47:09 -0800 (PST) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 20CE021F88FD for ; Thu, 13 Dec 2012 06:47:09 -0800 (PST) Received: from [182.72.99.242] (port=1531 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TjA43-0007CV-2C; Thu, 13 Dec 2012 20:17:08 +0530 From: "Chandrashekhar B" To: "'Stephen Hanna'" , "'Adam Montville'" References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> In-Reply-To: Date: Thu, 13 Dec 2012 20:16:58 +0530 Organization: SecPod Technologies Message-ID: <002001cdd940$b61eab50$225c01f0$@secpod.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CDD96E.CFDB7B30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUc35wJva16S/1A1/2czVjnCTohgHkGF2tAwJOW2UB8vmwQgE1A+1pAaZgksqZO/JgEA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Get-Message-Sender-Via: cpanel23.interactivedns.com: authenticated_id: bchandra@secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:47:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CDD96E.CFDB7B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >Chandra wrote: >> Data collector needs to have the assessment content for performing the task >> the data requestor asked for. This is 4.1.4 from use case document. >Perhaps. If the communications between the data requestor and the data collector included all the necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficient so it's desirable to use references to content instead of sending the content itself. Is this true? That could be another scenario. In which case, data requestor is behaving like a content repository with a push model. But, it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor. Chandra. From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the target system identification and data collection instructions to the data collector and for getting back the state values. I just don't understand why we need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying that one party (call it the "data requestor") asks a second party (call it the "data collector") to gather data ("state values") relating to the security of a third party (the "target system"). So we need standard protocols and data formats that the data requestor can use when talking to the data collector. To give a concrete example, the data requestor might say "Send me the list of software installed on device 374629" and the data collector might respond with a list of installed software. >With that model, the question of how the data collector gathers data about the target system (through the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not our problem. Arguably, even the nature of the policies used by the data requestor to determine whether it likes the state values may not be our problem. But I certainly don't see any need for content repository protocols in this model. >Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don't think we'll be able to come up with a set of requirements unless we have a common model for what the actors in the system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna wrote: Adam, Thanks for putting together this initial list of requirements. This is a good start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in enterprise networks today. If people agree, I would recommend changing your second requirement to add this at the end: "or brought and owned by end users". This change seems reasonable to me. We can ensure we address the issue, and then leave it to organizations using implementations of the standards/guidelines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for UC1? Why? It seems to me that these are likely to be "light," but are needed. How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to get assessment content, find the content repository, and form your request like this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a REST API to get this type of thing done, but that's getting the cart before the horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties * Asset representation/identification should support those delivered by a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of SP-provided assets * Must provide a method of defining a target system (asset identification; asset classification) * Must provide a method of selecting acceptable state policy (test expression) * Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation) * Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (test evaluation; test expression) * Must provide a protocol for connecting to a content repository containing SACM content * Must provide a protocol for querying SACM content held in a content repository * Must provide a protocol of retrieving SACM content from a content repository * Must provide a protocol for curating SACM content in a content repository In addition to the above, I would like to suggest that we take certain requirements from CSIS 20 Critical Security Controls [1] under the following controls: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediation * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate more detailed requirements to come out of them. I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control. For example, we may not be in a position to express "authorizations" for software installed on an operating system in a given context. But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. If you have contributions to make, I respectfully request that you do so before then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 ------=_NextPart_000_0021_01CDD96E.CFDB7B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Chandra wrote:

>> Data collector needs to have the assessment content for = performing the task

>> the data requestor asked for. This is 4.1.4 from use case = document.

 

>Perhaps. If the communications between the data requestor and the = data collector included all the necessary >content, this interaction could take place without needing a separate = content repository. Maybe this would not >be efficient so it’s desirable to use references to content = instead of sending the content itself. Is this true?

 

That could be another scenario. In which case, data requestor is = behaving like a content repository with a push model. But, it is = desirable in my view to use references so data collector could pull the = content or data collector knows how to get the content based on the = instructions given by the requestor.

 

Chandra.

 

 

From:= = Chandrashekhar B [mailto:bchandra@secpod.com] =
Sent: Thursday, December 13, 2012 1:32 AM
To: = Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: = [sacm] SACM UC1 And Related = Requirements

 

>Adam Montville wrote:

>> > 2)      Do we really need = protocols for accessing a content repository for UC1? = Why?

>> 

>> It seems to me that these are likely to be = "light," but are needed.  How do we expect to get = information from one place to the next without at least defining what an = access API might look like, what supported transport protocols exist for = the given technology, and what identifiers to use, = etc.

 

> I understand why we want to have a standard protocol for = conveying the target system identification and data collection = instructions to the data collector and for getting back the state = values. I just don’t understand why we need a standard protocol = for talking to a content repository for UC1.

 

>Maybe we have a different idea of how UC1 works. I think UC1 is = saying that one party (call it the “data requestor”) asks a = second party (call it the “data collector”) to gather data = (“state values”) relating to the security of a third party = (the “target system”). So we need standard protocols and = data formats that the data requestor can use when talking to the data = collector. To give a concrete example, the data requestor might say = “Send me the list of software installed on device 374629” = and the data collector might respond with a list of installed = software.

 

>With that model, the question of how the data collector gathers = data about the target system (through the NEA protocols or via WMI or = SSH) is not our problem. And how the data requestor determines the list = of state values to request is not our problem. Arguably, even the nature = of the policies used by the data requestor to determine whether it likes = the state values may not be our problem. But I certainly don’t see = any need for content repository protocols in this = model.

 

>Do you have a different model for UC1? I realize that this is = straying into architecture somewhat but I don’t think we’ll = be able to come up with a set of requirements unless we have a common = model for what the actors in the system are and how they interact to = achieve the goals of the use case.

 

Data collector needs to have the assessment content for performing = the task the data requestor asked for. This is 4.1.4 from use case = document.

 

Chandra.

 

 

 

 

On = Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> = wrote:

 

Adam,

 

Thanks for putting together this initial list of requirements. This = is a good start. I do have some = questions:

 

1)      Is BYOD in scope? I think it should be. It’s a fact of life in = enterprise networks today. If people agree, I would recommend changing = your second requirement to add this at the end: “or brought and = owned by end users”.

 

This change seems reasonable to me.  We can = ensure we address the issue, and then leave it to organizations using = implementations of the standards/guidelines we produce as to how they = want to apply the technology.

 

 

2)      Do we really need protocols for accessing a content repository for = UC1? Why?

 

It seems to me that these are likely to be = "light," but are needed.  How do we expect to get = information from one place to the next without at least defining what an = access API might look like, what supported transport protocols exist for = the given technology, and what identifiers to use, = etc. 

 

I don't think we need anything heavy, just enough to = say: If you want to get assessment content, find the content repository, = and form your request like this, and you'll get your = response.

 

Notionally, it's easy for me to see a service-oriented = interface using a REST API to get this type of thing done, but that's = getting the cart before the horse, I = think.

 

 

I’m glad to see us moving forward with this and other = issues.

 

Take care,

 

Steve

 

From:=  sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of Adam = Montville
Sent: Tuesday, December 11, 2012 = 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SACM UC1 And Related = Requirements

 

All:

 

After trolling through some of the SACM mailing list, = and reviewing SACM BoF minutes from IETF 85 and the current Use Case = draft looking for requirements, and here's what I've pulled together so = far: 

 

  • UC1 must provide coverage for = enterprises of various sizes and include support for assets delivered by = third-parties
  • Asset representation/identification should support those = delivered by a given Service Provider (SP)
  • Supporting data = formats and/or protocols should support assessment of SP-provided = assets
  • Must provide a method of defining a target system (asset = identification; asset classification)
  • Must provide a = method of selecting acceptable state policy (test = expression)
  • Must provide a method of retrieving data collection = instructions (activity class: configuration, patch, vulnerability, = inventory; object representation; state = representation)
  • Must provide a method of expressing = state collection values (collection language: technical, interrogative; = object representation)
  • Must provide a method of comparing = actual to expected state values (test evaluation; test = expression)
  • Must provide a protocol for connecting to a content = repository containing SACM content
  • Must provide a protocol for querying = SACM content held in a content repository
  • Must provide a = protocol of retrieving SACM content from a content = repository
  • Must provide a protocol for curating SACM content in a = content repository

 

In addition to the above, I would like to suggest that = we take certain = requirements from CSIS 20 Critical = Security Controls [1] under the following = controls:

 

  • Critical Control 1: Inventory of = Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of = Authorized and Unauthorized Software
  • Critical Control 3: = Secure Configuration for Hardware and Software on Mobile Devices, = Laptops, Workstations, and Servers
  • Critical Control 4: Continuous = Vulnerability Assessment and Remediation
  • Critical Control 5: = Malware Defenses
  • Critical Control 10: Secure = Configurations for Network Devices such as Firewalls, Routers, and = Switches

 

 

I have not yet parsed through each of the = Critical Controls, but anticipate more detailed requirements to come out = of them.  I emphasize that we will not be seeking to meet every = requirement expressed by a given Critical Control.  For example, we = may not be in a position to express "authorizations" for = software installed on an operating system in a given context.  But, = Critical Control 2 does require accurate and meaningful asset = identification (as does Critical Control 1, for that matter), which is = something with which we should be = concerned.

 

I have this Friday (12/14) dedicated to fleshing out = these requirements.  If you have contributions to make, I = respectfully request that you do so before = then.

 

Regards,

 

Adam

 

 

=
Adam W. Montville = | Security and Compliance Architect

= Direct: 503 276-7661
Mobile: 360 471-7815   =  

<= br>TR= IPWIRE&n= bsp;|<= span class=3Dapple-converted-space> CONFIDE= NCE:<= span class=3Dapple-converted-space> SECURED
www.tripwire.com<= /p>

 

 

 

No virus = found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / = Virus Database: 2634/5953 - Release Date: = 12/12/12

No virus = found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / = Virus Database: 2634/5954 - Release Date: = 12/12/12

------=_NextPart_000_0021_01CDD96E.CFDB7B30-- From shanna@juniper.net Thu Dec 13 07:14:05 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7E521F8B0A for ; Thu, 13 Dec 2012 07:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le8T2DSeaiSu for ; Thu, 13 Dec 2012 07:13:59 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4E221F8B73 for ; Thu, 13 Dec 2012 07:13:59 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUMnwt/UZRRxQ6VskjKyPLNFBkpQS6d64@postini.com; Thu, 13 Dec 2012 07:13:59 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 07:07:28 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 07:07:27 -0800 Received: from CO9EHSOBE025.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 07:15:00 -0800 Received: from mail204-co9-R.bigfish.com (10.236.132.248) by CO9EHSOBE025.bigfish.com (10.236.130.88) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 15:07:26 +0000 Received: from mail204-co9 (localhost [127.0.0.1]) by mail204-co9-R.bigfish.com (Postfix) with ESMTP id 58D2A88016C for ; Thu, 13 Dec 2012 15:07:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -38 X-BigFish: PS-38(zzbb2dI98dI9371Id6eah9f17Rc85fh1102I148cI1432I4015I11fbIzz1de0h1202h1e76h1d1ah1d2ahzz8275ch18c673h17326ah18602eh8275bh8275dh1033IL1954cbhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail204-co9 (localhost.localdomain [127.0.0.1]) by mail204-co9 (MessageSwitch) id 1355411108905365_16885; Thu, 13 Dec 2012 15:05:08 +0000 (UTC) Received: from CO9EHSMHS019.bigfish.com (unknown [10.236.132.246]) by mail204-co9.bigfish.com (Postfix) with ESMTP id D2F9364004A; Thu, 13 Dec 2012 15:05:08 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by CO9EHSMHS019.bigfish.com (10.236.130.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 15:05:02 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.140]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0245.002; Thu, 13 Dec 2012 15:04:59 +0000 From: Stephen Hanna To: "bchandra@secpod.com" , 'Adam Montville' Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIAA4CiAgABN58CAADxPAIAAAbxw Date: Thu, 13 Dec 2012 15:04:59 +0000 Message-ID: References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> In-Reply-To: <002001cdd940$b61eab50$225c01f0$@secpod.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E068E4EF4SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%SECPOD.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TRIPWIRE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:14:05 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E4EF4SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chandra wrote: > it is desirable in my view to use references so data collector could pull= the content or data collector knows how to get the content based on the in= structions given by the requestor. Chandra, As I recall, you are the founder of a company (SecPod) that develops and pr= ovides SCAP content on a subscription basis. SecPod was the first company t= o create an SCAP Content Repository and to provide a standard protocol for = accessing it. With all due respect and appreciation for your work (which I = think is of the highest quality), you may have a personal bias toward stand= ardizing a content repository protocol. Could you offer a compelling techni= cal rationale for doing so at this time and as a part of UC1? I'd also like= to hear from other SACM participants on this topic. Thanks, Steve From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 9:47 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Chandra wrote: >> Data collector needs to have the assessment content for performing the t= ask >> the data requestor asked for. This is 4.1.4 from use case document. >Perhaps. If the communications between the data requestor and the data col= lector included all the necessary >content, this interaction could take pla= ce without needing a separate content repository. Maybe this would not >be = efficient so it's desirable to use references to content instead of sending= the content itself. Is this true? That could be another scenario. In which case, data requestor is behaving l= ike a content repository with a push model. But, it is desirable in my view= to use references so data collector could pull the content or data collect= or knows how to get the content based on the instructions given by the requ= estor. Chandra. From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository= for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How= do we expect to get information from one place to the next without at leas= t defining what an access API might look like, what supported transport pro= tocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the ta= rget system identification and data collection instructions to the data col= lector and for getting back the state values. I just don't understand why w= e need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying tha= t one party (call it the "data requestor") asks a second party (call it the= "data collector") to gather data ("state values") relating to the security= of a third party (the "target system"). So we need standard protocols and = data formats that the data requestor can use when talking to the data colle= ctor. To give a concrete example, the data requestor might say "Send me the= list of software installed on device 374629" and the data collector might = respond with a list of installed software. >With that model, the question of how the data collector gathers data about= the target system (through the NEA protocols or via WMI or SSH) is not our= problem. And how the data requestor determines the list of state values to= request is not our problem. Arguably, even the nature of the policies used= by the data requestor to determine whether it likes the state values may n= ot be our problem. But I certainly don't see any need for content repositor= y protocols in this model. >Do you have a different model for UC1? I realize that this is straying int= o architecture somewhat but I don't think we'll be able to come up with a s= et of requirements unless we have a common model for what the actors in the= system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task= the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in ente= rprise networks today. If people agree, I would recommend changing your sec= ond requirement to add this at the end: "or brought and owned by end users"= . This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E4EF4SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chandra wrote:=

> it is desirable in m= y view to use references so data collector could pull the content or data c= ollector knows how to get the content based on the instructions given by the requestor.

 <= /p>

Chandra,

 <= /p>

As I recall, you are the = founder of a company (SecPod) that develops and provides SCAP content on a = subscription basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol for accessin= g it. With all due respect and appreciation for your work (which I think is= of the highest quality), you may have a personal bias toward standardizing= a content repository protocol. Could you offer a compelling technical rationale for doing so at this time= and as a part of UC1? I’d also like to hear from other SACM particip= ants on this topic.

 <= /p>

Thanks,=


Steve

 <= /p>

From: Chandras= hekhar B [mailto:bchandra@secpod.com]
Sent: Thursday, December 13, 2012 9:47 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Chandra wrote:

>> Data collector n= eeds to have the assessment content for performing the task

>> the data request= or asked for. This is 4.1.4 from use case document.

 <= /p>

>Perhaps. If the commu= nications between the data requestor and the data collector included all th= e necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficie= nt so it’s desirable to use references to content instead of sending = the content itself. Is this true?

 <= /p>

That could be another sce= nario. In which case, data requestor is behaving like a content repository = with a push model. But, it is desirable in my view to use references so data collector could pull the content or data collector know= s how to get the content based on the instructions given by the requestor.<= o:p>

 <= /p>

Chandra.

 <= /p>

 <= /p>

From: Chandras= hekhar B [mailto:bchandra@secpod.com= ]
Sent: Thursday, December 13, 2012 1:32 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Adam Montville wrote:=

>> > 2) &nb= sp;    Do we really need protocols for accessing a content r= epository for UC1? Why?

>> =

>> It seems to me t= hat these are likely to be "light," but are needed.  How do = we expect to get information from one place to the next without at least de= fining what an access API might look like, what supported transport protocols exi= st for the given technology, and what identifiers to use, etc.

 <= /p>

> I understand why we = want to have a standard protocol for conveying the target system identifica= tion and data collection instructions to the data collector and for getting back the state values. I just don’t understand why w= e need a standard protocol for talking to a content repository for UC1.

 <= /p>

>Maybe we have a diffe= rent idea of how UC1 works. I think UC1 is saying that one party (call it t= he “data requestor”) asks a second party (call it the “da= ta collector”) to gather data (“state values”) relating to = the security of a third party (the “target system”). So we need= standard protocols and data formats that the data requestor can use when t= alking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on = device 374629” and the data collector might respond with a list of in= stalled software.

 <= /p>

>With that model, the = question of how the data collector gathers data about the target system (th= rough the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request = is not our problem. Arguably, even the nature of the policies used by the d= ata requestor to determine whether it likes the state values may not be our= problem. But I certainly don’t see any need for content repository protocols in this model.

 <= /p>

>Do you have a differe= nt model for UC1? I realize that this is straying into architecture somewha= t but I don’t think we’ll be able to come up with a set of requirements unless we have a common model for what the actors in the syst= em are and how they interact to achieve the goals of the use case.

 <= /p>

Data collector needs to h= ave the assessment content for performing the task the data requestor asked= for. This is 4.1.4 from use case document.

 <= /p>

Chandra.

 <= /p>

 <= /p>

From: Adam Mon= tville [mailto:amontville@tripwi= re.com]
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: sacm@ietf.org
Subject: Re: SACM UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> wrote:

 

Adam,

 <= /p>

Thanks for putting togeth= er this initial list of requirements. This is a good start. I do have some = questions:

 <= /p>

1)     =  Is BYOD in scope? I think it should be. It’s a fact of life in enterpri= se networks today. If people agree, I would recommend changing your second = requirement to add this at the end: “or brought and owned by end user= s”.

 

This change seems reasonable to me.  We can ens= ure we address the issue, and then leave it to organizations using implemen= tations of the standards/guidelines we produce as to how they want to apply= the technology.

 

 

2)  &nbs= p;   Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

 

It seems to me that these are likely to be "lig= ht," but are needed.  How do we expect to get information from on= e place to the next without at least defining what an access API might look= like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to= say: If you want to get assessment content, find the content repository, a= nd form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-orient= ed interface using a REST API to get this type of thing done, but that's ge= tting the cart before the horse, I think.

 

 <= /p>

I’m glad to see us = moving forward with this and other issues.

 <= /p>

Take care,

 <= /p>

Steve

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SA= CM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide = coverage for enterprises of various sizes and include support for assets de= livered by third-parties
  • Asset representation/identification should support t= hose delivered by a given Service Provider (SP)
  • Supporting data formats and/o= r protocols should support assessment of SP-provided assets
    • =
  • Must provide a me= thod of defining a target system (asset identification; asset classificatio= n)
  • Must provide a method of selecting acceptable state policy (test expressio= n)
  • Must provide a method of retrieving data collection instructions (activity= class: configuration, patch, vulnerability, inventory; object representati= on; state representation)
  • Must provide a method of expressing state collectio= n values (collection language: technical, interrogative; object representat= ion)
  • Must provide a method of comparing actual to expected state values (test= evaluation; test expression)
  • Must provide a protocol for connecting to a co= ntent repository containing SACM content
  • Must provide a protocol for querying= SACM content held in a content repository
  • Must provide a protocol of retriev= ing SACM content from a content repository
  • Must provide a protocol for curati= ng SACM content in a content repository

 

In addition to the above, I would like to suggest th= at we take certain = requirements from= CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control = 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inven= tory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Confi= guration for Hardware and Software on Mobile Devices, Laptops, Workstations= , and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Rem= ediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Confi= gurations for Network Devices such as Firewalls, Routers, and Switches=

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detaile= d requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given= Critical Control.  For example, we may not be in a position to expres= s "authorizations" for software installed on an operating system = in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Con= trol 1, for that matter), which is something with which we should be concer= ned.

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

 

 

 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12

--_000_F1DFC16DCAA7D3468651A5A776D5796E068E4EF4SN2PRD0510MB372_-- From amontville@tripwire.com Thu Dec 13 07:37:09 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC6A21F8B26 for ; Thu, 13 Dec 2012 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ry2Iu0pSbPp for ; Thu, 13 Dec 2012 07:37:06 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9B821F88F6 for ; Thu, 13 Dec 2012 07:36:59 -0800 (PST) Received: from mail74-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 15:36:58 +0000 Received: from mail74-co9 (localhost [127.0.0.1]) by mail74-co9-R.bigfish.com (Postfix) with ESMTP id BFBBE260206 for ; Thu, 13 Dec 2012 15:36:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zzbb2dI98dI9371Id6eah9f17Rc85eh1102I148cI1432I4015I11fbIzz1de0h1202h1e76h1d1ah1d2ahzz8275ch18c673h17326ah18602eh8275bh8275dh1033IL1954cbhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail74-co9 (localhost.localdomain [127.0.0.1]) by mail74-co9 (MessageSwitch) id 1355412885573229_13518; Thu, 13 Dec 2012 15:34:45 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.244]) by mail74-co9.bigfish.com (Postfix) with ESMTP id 7BEB44E0058 for ; Thu, 13 Dec 2012 15:34:45 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 15:33:15 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id A352C232124A for ; Thu, 13 Dec 2012 07:21:34 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id D20FD23211D0; Thu, 13 Dec 2012 07:21:33 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Thu, 13 Dec 2012 07:37:35 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Thu, 13 Dec 2012 07:33:08 -0800 From: Adam Montville To: Stephen Hanna Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIABZkSAgAB6igCAAA+tAIAABQiAgAAH3IA= Date: Thu, 13 Dec 2012 15:33:07 +0000 Message-ID: <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_9AC807E5276443AA82BB1796EBC167E8tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: a472dc49-7990-4770-a9ee-a57447837e33 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "bchandra@secpod.com" , "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:37:09 -0000 --_000_9AC807E5276443AA82BB1796EBC167E8tripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 13, 2012, at 7:04 AM, Stephen Hanna > wrote: Chandra wrote: > it is desirable in my view to use references so data collector could pull= the content or data collector knows how to get the content based on the in= structions given by the requestor. Chandra, As I recall, you are the founder of a company (SecPod) that develops and pr= ovides SCAP content on a subscription basis. SecPod was the first company t= o create an SCAP Content Repository and to provide a standard protocol for = accessing it. With all due respect and appreciation for your work (which I = think is of the highest quality), you may have a personal bias toward stand= ardizing a content repository protocol. Could you offer a compelling techni= cal rationale for doing so at this time and as a part of UC1? I=92d also li= ke to hear from other SACM participants on this topic. Let's look at this from the end goal. Imagine that we're "done" with Use C= ase 1. A set of standards that allow us to: 1) define the target system, 2= ) select acceptable state policy, 3) retrieve data collection instructions,= 4) collect actual state values, and 5) compare actual state values. There are two ways we can deal with the selection and retrieval of policy a= nd collection instructions (steps 2 and 3, respectively). We can leave it = up to specific implementations to figure it out on their own and end up wit= h proprietary solutions, or, as presented in Atlanta, we can specify the me= thod(s) by which implementations can connect to and interact with the stora= ge of that information. I ask myself this question: How useful is it to define a content-driven ass= essment method without providing the accompanying method of transmitting th= at content? To me, it's not a benefit to the community at all without addr= essing the basic requirement of getting the content from one place to anoth= er. The goal here is automation, and without that, we're keeping one of th= e worst manual processes around. While this may not be a "technical" reason for keeping the content reposito= ry in scope, I really can't imagine a truly useful set of standards without= one. If there's one thing I think we've learned in the security automatio= n community so far, it's that you can spec schema all day long, but if you = don't have a good way to interoperate in an automated way with other tools = and/or external entities, you're treading water. So, I'm a strong advocate for explicitly recognizing the need for defining = the method by which implementations should expect to connect to a content r= epository, and, therefore, for keeping that squarely in scope for UC1. Thanks, Steve From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 9:47 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Chandra wrote: >> Data collector needs to have the assessment content for performing the t= ask >> the data requestor asked for. This is 4.1.4 from use case document. >Perhaps. If the communications between the data requestor and the data col= lector included all the necessary >content, this interaction could take pla= ce without needing a separate content repository. Maybe this would not >be = efficient so it=92s desirable to use references to content instead of sendi= ng the content itself. Is this true? That could be another scenario. In which case, data requestor is behaving l= ike a content repository with a push model. But, it is desirable in my view= to use references so data collector could pull the content or data collect= or knows how to get the content based on the instructions given by the requ= estor. Chandra. From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository= for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How= do we expect to get information from one place to the next without at leas= t defining what an access API might look like, what supported transport pro= tocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the ta= rget system identification and data collection instructions to the data col= lector and for getting back the state values. I just don=92t understand why= we need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying tha= t one party (call it the =93data requestor=94) asks a second party (call it= the =93data collector=94) to gather data (=93state values=94) relating to = the security of a third party (the =93target system=94). So we need standar= d protocols and data formats that the data requestor can use when talking t= o the data collector. To give a concrete example, the data requestor might = say =93Send me the list of software installed on device 374629=94 and the d= ata collector might respond with a list of installed software. >With that model, the question of how the data collector gathers data about= the target system (through the NEA protocols or via WMI or SSH) is not our= problem. And how the data requestor determines the list of state values to= request is not our problem. Arguably, even the nature of the policies used= by the data requestor to determine whether it likes the state values may n= ot be our problem. But I certainly don=92t see any need for content reposit= ory protocols in this model. >Do you have a different model for UC1? I realize that this is straying int= o architecture somewhat but I don=92t think we=92ll be able to come up with= a set of requirements unless we have a common model for what the actors in= the system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task= the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It=92s a fact of life in en= terprise networks today. If people agree, I would recommend changing your s= econd requirement to add this at the end: =93or brought and owned by end us= ers=94. This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I=92m glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_9AC807E5276443AA82BB1796EBC167E8tripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 13, 2012, at 7:04 AM, Stephen Hanna <shanna@juniper.net> wrote:

Chandra wrote:
> it is desirable in my view to use references so data= collector could pull the content or data collector knows how to get the co= ntent based on the instructions given by the requestor.
 
Chandra,
 
As I recall, you are the founder of a company (SecPod) th= at develops and provides SCAP content on a subscription basis. SecPod was t= he first company to create an SCAP Content Repository and to provide a standard protocol for accessing it. Wi= th all due respect and appreciation for your work (which I think is of the = highest quality), you may have a personal bias toward standardizing a conte= nt repository protocol. Could you offer a compelling technical rationale for doing so at this time and as a = part of UC1? I=92d also like to hear from other SACM participants on this t= opic.


Let's look at this from the end goal.  Imagine that we're "d= one" with Use Case 1.  A set of standards that allow us to: 1) de= fine the target system, 2) select acceptable state policy, 3) retrieve data= collection instructions, 4) collect actual state values, and 5) compare actual state values.  

There are two ways we can deal with the selection and retrieval of pol= icy and collection instructions (steps 2 and 3, respectively).  We can= leave it up to specific implementations to figure it out on their own and = end up with proprietary solutions, or, as presented in Atlanta, we can specify the method(s) by which implementat= ions can connect to and interact with the storage of that information.

I ask myself this question: How useful is it to define a content-drive= n assessment method without providing the accompanying method of transmitti= ng that content?  To me, it's not a benefit to the community at all wi= thout addressing the basic requirement of getting the content from one place to another.  The goal here is a= utomation, and without that, we're keeping one of the worst manual processe= s around.

While this may not be a "technical" reason for keeping the c= ontent repository in scope, I really can't imagine a truly useful set of st= andards without one.  If there's one thing I think we've learned in th= e security automation community so far, it's that you can spec schema all day long, but if you don't have a good way to inte= roperate in an automated way with other tools and/or external entities, you= 're treading water.

So, I'm a strong advocate for explicitly recognizing the need for defi= ning the method by which implementations should expect to connect to a cont= ent repository, and, therefore, for keeping that squarely in scope for UC1.=




 
Thanks,

Steve
 
From:=  Chandrashekhar B [mai= lto:bchandra@secpod.com] 
Sent: Thursday, De= cember 13, 2012 9:47 AM
To: Stephen Hanna;= 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm= ] SACM UC1 And Related Requirements
 
>Chandra wrote:
>> Data collector needs to have the assessment cont= ent for performing the task
>> the data requestor asked for. This is 4.1.4 from= use case document.
 
>Perhaps. If the communications between the data reque= stor and the data collector included all the necessary >content, this in= teraction could take place without needing a separate content repository. Maybe this would not >be efficient so it= =92s desirable to use references to content instead of sending the content = itself. Is this true?
 
That could be another scenario. In which case, data reque= stor is behaving like a content repository with a push model. But, it is de= sirable in my view to use references so data collector could pull the content or data collector knows how to ge= t the content based on the instructions given by the requestor.<= /span>
 
Chandra.
 
 
From:=  Chandrashekhar B [mailto:bchandra@secpod.com] 
Sent: Thursday, De= cember 13, 2012 1:32 AM
To: Stephen Hanna;= 'Adam Montville'
Cc: sa= cm@ietf.org
Subject: RE: [sacm= ] SACM UC1 And Related Requirements
 
>Adam Montville wrote:
>> > 2)      Do we real= ly need protocols for accessing a content repository for UC1? Why?
>> 
>> It seems to me that these are likely to be "= ;light," but are needed.  How do we expect to get information fro= m one place to the next without at least defining what an access API might look like, what supported transport protocols exist fo= r the given technology, and what identifiers to use, etc.=
 
> I understand why we want to have a standard protocol= for conveying the target system identification and data collection instruc= tions to the data collector and for getting back the state values. I just don=92t understand why we need a standard pr= otocol for talking to a content repository for UC1.
 
>Maybe we have a different idea of how UC1 works. I th= ink UC1 is saying that one party (call it the =93data requestor=94) asks a = second party (call it the =93data collector=94) to gather data (=93state values=94) relating to the security of a third pa= rty (the =93target system=94). So we need standard protocols and data forma= ts that the data requestor can use when talking to the data collector. To g= ive a concrete example, the data requestor might say =93Send me the list of software installed on device 374629=94 an= d the data collector might respond with a list of installed software.<= /o:p>
 
>With that model, the question of how the data collect= or gathers data about the target system (through the NEA protocols or via W= MI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not o= ur problem. Arguably, even the nature of the policies used by the data requ= estor to determine whether it likes the state values may not be our problem= . But I certainly don=92t see any need for content repository protocols in this model.
 
>Do you have a different model for UC1? I realize that= this is straying into architecture somewhat but I don=92t think we=92ll be= able to come up with a set of requirements unless we have a common model for what the actors in the system are and ho= w they interact to achieve the goals of the use case.
 
Data collector needs to have the assessment content for p= erforming the task the data requestor asked for. This is 4.1.4 from use cas= e document.
 
Chandra.
 
 
From:=  Adam Montville [mailto:amontville@tripwire.com] 
Sent: Wednesday, D= ecember 12, 2012 12:09 PM
To: Stephen Hanna<= br> Cc: sa= cm@ietf.org
Subject: Re: SACM = UC1 And Related Requirements
 
 
On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juni= per.net> wrote:

 

Adam,
 
Thanks for putting together this initial list of requirem= ents. This is a good start. I do have some questions:
 

1)      Is BYOD in scope? I think it should be. It=92s a fact of life in enterprise n= etworks today. If people agree, I would recommend changing your second requ= irement to add this at the end: =93or brought and owned by end users=94.

 
This change seems reasonable to me.  We can ensure we address the issu= e, and then leave it to organizations using implementations of the standard= s/guidelines we produce as to how they want to apply the technology.
 

 

2)      Do we really need protocols for accessing a content repository for UC1? Why?<= /span>
 
It seems to me that these are likely to be "light," but are neede= d.  How do we expect to get information from one place to the next wit= hout at least defining what an access API might look like, what supported t= ransport protocols exist for the given technology, and what identifiers to use, etc. 
 
I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response.
 
Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think.

 

 
I=92m glad to see us moving forward with this and other i= ssues.
 
Take care,
 
Steve
 
From:=  sa= cm-bounces@ietf.org [= mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montv= ille
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sa= cm@ietf.org
Subject: [sacm] SA= CM UC1 And Related Requirements
 
All:
 
After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: 
 
  • UC1 must provide coverage for enterprises of various sizes and include supp= ort for assets delivered by third-parties
  • Asset representation/identification should support those delivered by a giv= en Service Provider (SP)
  • Supporting data formats and/or protocols should support assessment of SP-pr= ovided assets
  • Must provide a method of defining a target system (asset identification; as= set classification)
  • Must provide a method of retrieving data collection instructions (activity = class: configuration, patch, vulnerability, inventory; object representatio= n; state representation)
  • Must provide a method of expressing state collection values (collection lan= guage: technical, interrogative; object representation)
  • Must provide a method of comparing actual to expected state values (test ev= aluation; test expression)
  • Must provide a protocol for connecting to a content repository containing S= ACM content
  • Must provide a protocol for querying SACM content held in a content reposit= ory
  • Must provide a protocol of retrieving SACM content from a content repositor= y
  • Must provide a protocol for curating SACM content in a content repository
 
In addition to the above, I would like to suggest that we take certain requirements<= span class=3D"apple-converted-space"> from CSIS 20 Critical Sec= urity Controls [1] under the following controls:
 
  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software<= /o:p>
  • Critical Control 3: Secure Configuration for Hardware and Software on Mobil= e Devices, Laptops, Workstations, and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Remediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Configurations for Network Devices such as Fire= walls, Routers, and Switches
 
 
I have not yet<= /i> parsed through each o= f the Critical Controls, but anticipate more detailed requirements to come = out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control. &= nbsp;For example, we may not be in a position to express "authorizatio= ns" for software installed on an operating system in a given context. =  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that = matter), which is something with which we should be concerned.
 
I have this Friday (12/14) dedicated to fleshing out these requirements. &n= bsp;If you have contributions to make, I respectfully request that you do s= o before then.
 
Regards,
 
Adam
 
 


Adam W. Montville | Security and Compliance Architect

Direct: = 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com

 = ;
 
 
No virus found in this message.
Checked by AVG - 
No virus found in this message.
Checked by AVG - sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_9AC807E5276443AA82BB1796EBC167E8tripwirecom_-- From david.waltermire@nist.gov Thu Dec 13 07:58:13 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62EF21F8AC6 for ; Thu, 13 Dec 2012 07:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efgdTAnrJIq8 for ; Thu, 13 Dec 2012 07:58:05 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 62C9821F8AA6 for ; Thu, 13 Dec 2012 07:58:04 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 13 Dec 2012 10:57:57 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 13 Dec 2012 10:58:03 -0500 From: "Waltermire, David A." To: Adam Montville , Stephen Hanna Date: Thu, 13 Dec 2012 10:58:02 -0500 Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIABZkSAgAB6igCAAA+tAIAABQiAgAAH3ID//3ylkA== Message-ID: References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> In-Reply-To: <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.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_D7A0423E5E193F40BE6E94126930C4930BAD85C538MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "bchandra@secpod.com" , "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:58:13 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BAD85C538MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, +1. Your point is well stated IMHO. Content management has been a significant barrier to useful adoption of sec= urity automation approaches to date. I reviewed the TCG's IF-M for SCAP du= ring the development of that document and raised these issues. At the time= we decided to keep content management out-of-band for the document, relyin= g on proprietary methods to insure the delivery of content. My concerns we= re around the potential mismatch between what content is expected to be on = the access requestor and what content is being used to satisfy a health che= ck. If the content is handled out-of-band, this may be a more regular occur= rence and is certainly a challenge to contend with in multi-vendor interope= rability scenarios. This all works better if the content is managed proper= ly and if both the access requestor and the policy evaluator have the same = content. Of course there are still some circumstances where it is impossib= le to deploy the latest content (e.g. long-term disconnection from the netw= ork), but this is a secondary issue. The best way to ensure that content is managed properly is to keep it in sc= ope as part of the orchestration process for collection. To support this, = we probably need to support a mechanism that allows content to be pulled by= reference. We may also need a method to "package" the content along with = instructions that are exchanged over the control channel allowing a "push".= The latter would enable tightly managed clients. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Thursday, December 13, 2012 10:33 AM To: Stephen Hanna Cc: bchandra@secpod.com; sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements On Dec 13, 2012, at 7:04 AM, Stephen Hanna > wrote: Chandra wrote: > it is desirable in my view to use references so data collector could pull= the content or data collector knows how to get the content based on the in= structions given by the requestor. Chandra, As I recall, you are the founder of a company (SecPod) that develops and pr= ovides SCAP content on a subscription basis. SecPod was the first company t= o create an SCAP Content Repository and to provide a standard protocol for = accessing it. With all due respect and appreciation for your work (which I = think is of the highest quality), you may have a personal bias toward stand= ardizing a content repository protocol. Could you offer a compelling techni= cal rationale for doing so at this time and as a part of UC1? I'd also like= to hear from other SACM participants on this topic. Let's look at this from the end goal. Imagine that we're "done" with Use C= ase 1. A set of standards that allow us to: 1) define the target system, 2= ) select acceptable state policy, 3) retrieve data collection instructions,= 4) collect actual state values, and 5) compare actual state values. There are two ways we can deal with the selection and retrieval of policy a= nd collection instructions (steps 2 and 3, respectively). We can leave it = up to specific implementations to figure it out on their own and end up wit= h proprietary solutions, or, as presented in Atlanta, we can specify the me= thod(s) by which implementations can connect to and interact with the stora= ge of that information. I ask myself this question: How useful is it to define a content-driven ass= essment method without providing the accompanying method of transmitting th= at content? To me, it's not a benefit to the community at all without addr= essing the basic requirement of getting the content from one place to anoth= er. The goal here is automation, and without that, we're keeping one of th= e worst manual processes around. While this may not be a "technical" reason for keeping the content reposito= ry in scope, I really can't imagine a truly useful set of standards without= one. If there's one thing I think we've learned in the security automatio= n community so far, it's that you can spec schema all day long, but if you = don't have a good way to interoperate in an automated way with other tools = and/or external entities, you're treading water. So, I'm a strong advocate for explicitly recognizing the need for defining = the method by which implementations should expect to connect to a content r= epository, and, therefore, for keeping that squarely in scope for UC1. Thanks, Steve From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 9:47 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Chandra wrote: >> Data collector needs to have the assessment content for performing the t= ask >> the data requestor asked for. This is 4.1.4 from use case document. >Perhaps. If the communications between the data requestor and the data col= lector included all the necessary >content, this interaction could take pla= ce without needing a separate content repository. Maybe this would not >be = efficient so it's desirable to use references to content instead of sending= the content itself. Is this true? That could be another scenario. In which case, data requestor is behaving l= ike a content repository with a push model. But, it is desirable in my view= to use references so data collector could pull the content or data collect= or knows how to get the content based on the instructions given by the requ= estor. Chandra. From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository= for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How= do we expect to get information from one place to the next without at leas= t defining what an access API might look like, what supported transport pro= tocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the ta= rget system identification and data collection instructions to the data col= lector and for getting back the state values. I just don't understand why w= e need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying tha= t one party (call it the "data requestor") asks a second party (call it the= "data collector") to gather data ("state values") relating to the security= of a third party (the "target system"). So we need standard protocols and = data formats that the data requestor can use when talking to the data colle= ctor. To give a concrete example, the data requestor might say "Send me the= list of software installed on device 374629" and the data collector might = respond with a list of installed software. >With that model, the question of how the data collector gathers data about= the target system (through the NEA protocols or via WMI or SSH) is not our= problem. And how the data requestor determines the list of state values to= request is not our problem. Arguably, even the nature of the policies used= by the data requestor to determine whether it likes the state values may n= ot be our problem. But I certainly don't see any need for content repositor= y protocols in this model. >Do you have a different model for UC1? I realize that this is straying int= o architecture somewhat but I don't think we'll be able to come up with a s= et of requirements unless we have a common model for what the actors in the= system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task= the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in ente= rprise networks today. If people agree, I would recommend changing your sec= ond requirement to add this at the end: "or brought and owned by end users"= . This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and include= support for assets delivered by third-parties * Asset representation/identification should support those delivered by = a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of = SP-provided assets * Must provide a method of defining a target system (asset identificatio= n; asset classification) * Must provide a method of selecting acceptable state policy (test expre= ssion) * Must provide a method of retrieving data collection instructions (acti= vity class: configuration, patch, vulnerability, inventory; object represen= tation; state representation) * Must provide a method of expressing state collection values (collectio= n language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (te= st evaluation; test expression) * Must provide a protocol for connecting to a content repository contain= ing SACM content * Must provide a protocol for querying SACM content held in a content re= pository * Must provide a protocol of retrieving SACM content from a content repo= sitory * Must provide a protocol for curating SACM content in a content reposit= ory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on = Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediatio= n * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such as= Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_D7A0423E5E193F40BE6E94126930C4930BAD85C538MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1t c2c6Ly8xNTMvIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlv bnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRpbWVzOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNl DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEzNzEwMzU2MTc7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjcyNjA0MjgwNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjE0ODE5MjYyNDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzc0 MTc0Njg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBC NzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMg bGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BZGFtLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ KzEuJm5ic3A7IFlvdXIgcG9pbnQgaXMgd2VsbCBzdGF0ZWQgSU1ITy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkNvbnRlbnQgbWFuYWdlbWVudCBoYXMgYmVlbiBhIHNpZ25pZmljYW50IGJhcnJpZXIgdG8g dXNlZnVsIGFkb3B0aW9uIG9mIHNlY3VyaXR5IGF1dG9tYXRpb24gYXBwcm9hY2hlcyB0byBkYXRl LiZuYnNwOyBJIHJldmlld2VkIHRoZSBUQ0cmIzgyMTc7cyBJRi1NIGZvciBTQ0FQIGR1cmluZyB0 aGUgZGV2ZWxvcG1lbnQgb2YgdGhhdCBkb2N1bWVudCBhbmQgcmFpc2VkIHRoZXNlIGlzc3Vlcy4m bmJzcDsgQXQgdGhlIHRpbWUgd2UgZGVjaWRlZCB0byBrZWVwIGNvbnRlbnQgbWFuYWdlbWVudCBv dXQtb2YtYmFuZCBmb3IgdGhlIGRvY3VtZW50LCByZWx5aW5nIG9uIHByb3ByaWV0YXJ5IG1ldGhv ZHMgdG8gaW5zdXJlIHRoZSBkZWxpdmVyeSBvZiBjb250ZW50LiZuYnNwOyBNeSBjb25jZXJucyB3 ZXJlIGFyb3VuZCB0aGUgcG90ZW50aWFsIG1pc21hdGNoIGJldHdlZW4gd2hhdCBjb250ZW50IGlz IGV4cGVjdGVkIHRvIGJlIG9uIHRoZSBhY2Nlc3MgcmVxdWVzdG9yIGFuZCB3aGF0IGNvbnRlbnQg aXMgYmVpbmcgdXNlZCB0byBzYXRpc2Z5IGEgaGVhbHRoIGNoZWNrLiBJZiB0aGUgY29udGVudCBp cyBoYW5kbGVkIG91dC1vZi1iYW5kLCB0aGlzIG1heSBiZSBhIG1vcmUgcmVndWxhciBvY2N1cnJl bmNlIGFuZCBpcyBjZXJ0YWlubHkgYSBjaGFsbGVuZ2UgdG8gY29udGVuZCB3aXRoIGluIG11bHRp LXZlbmRvciBpbnRlcm9wZXJhYmlsaXR5IHNjZW5hcmlvcy4mbmJzcDsgVGhpcyBhbGwgd29ya3Mg YmV0dGVyIGlmIHRoZSBjb250ZW50IGlzIG1hbmFnZWQgcHJvcGVybHkgYW5kIGlmIGJvdGggdGhl IGFjY2VzcyByZXF1ZXN0b3IgYW5kIHRoZSBwb2xpY3kgZXZhbHVhdG9yIGhhdmUgdGhlIHNhbWUg Y29udGVudC4mbmJzcDsgT2YgY291cnNlIHRoZXJlIGFyZSBzdGlsbCBzb21lIGNpcmN1bXN0YW5j ZXMgd2hlcmUgaXQgaXMgaW1wb3NzaWJsZSB0byBkZXBsb3kgdGhlIGxhdGVzdCBjb250ZW50IChl LmcuIGxvbmctdGVybSBkaXNjb25uZWN0aW9uIGZyb20gdGhlIG5ldHdvcmspLCBidXQgdGhpcyBp cyBhIHNlY29uZGFyeSBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBiZXN0IHdheSB0byBl bnN1cmUgdGhhdCBjb250ZW50IGlzIG1hbmFnZWQgcHJvcGVybHkgaXMgdG8ga2VlcCBpdCBpbiBz Y29wZSBhcyBwYXJ0IG9mIHRoZSBvcmNoZXN0cmF0aW9uIHByb2Nlc3MgZm9yIGNvbGxlY3Rpb24u Jm5ic3A7IFRvIHN1cHBvcnQgdGhpcywgd2UgcHJvYmFibHkgbmVlZCB0byBzdXBwb3J0IGEgbWVj aGFuaXNtIHRoYXQgYWxsb3dzIGNvbnRlbnQgdG8gYmUgcHVsbGVkIGJ5IHJlZmVyZW5jZS4mbmJz cDsgV2UgbWF5IGFsc28gbmVlZCBhIG1ldGhvZCB0byAmIzgyMjA7cGFja2FnZSYjODIyMTsgdGhl IGNvbnRlbnQgYWxvbmcgd2l0aCBpbnN0cnVjdGlvbnMgdGhhdCBhcmUgZXhjaGFuZ2VkIG92ZXIg dGhlIGNvbnRyb2wgY2hhbm5lbCBhbGxvd2luZyBhICYjODIyMDtwdXNoJiM4MjIxOy4mbmJzcDsg VGhlIGxhdHRlciB3b3VsZCBlbmFibGUgdGlnaHRseSBtYW5hZ2VkIGNsaWVudHMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5TaW5jZXJlbHksPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBzYWNtLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+QWRh bSBNb250dmlsbGU8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAxMywgMjAxMiAx MDozMyBBTTxicj48Yj5Ubzo8L2I+IFN0ZXBoZW4gSGFubmE8YnI+PGI+Q2M6PC9iPiBiY2hhbmRy YUBzZWNwb2QuY29tOyBzYWNtQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhY21d IFNBQ00gVUMxIEFuZCBSZWxhdGVkIFJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+T24gRGVjIDEzLCAyMDEyLCBhdCA3OjA0IEFNLCBTdGVwaGVuIEhhbm5hICZsdDs8YSBo cmVmPSJtYWlsdG86c2hhbm5hQGp1bmlwZXIubmV0Ij5zaGFubmFAanVuaXBlci5uZXQ8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48 bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Q2hhbmRyYSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7IGl0IGlzIGRlc2ly YWJsZSBpbiBteSB2aWV3IHRvIHVzZSByZWZlcmVuY2VzIHNvIGRhdGEgY29sbGVjdG9yIGNvdWxk IHB1bGwgdGhlIGNvbnRlbnQgb3IgZGF0YSBjb2xsZWN0b3Iga25vd3MgaG93IHRvIGdldCB0aGUg Y29udGVudCBiYXNlZCBvbiB0aGUgaW5zdHJ1Y3Rpb25zIGdpdmVuIGJ5IHRoZSByZXF1ZXN0b3Iu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2hhbmRyYSw8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BcyBJIHJlY2FsbCwgeW91IGFyZSB0 aGUgZm91bmRlciBvZiBhIGNvbXBhbnkgKFNlY1BvZCkgdGhhdCBkZXZlbG9wcyBhbmQgcHJvdmlk ZXMgU0NBUCBjb250ZW50IG9uIGEgc3Vic2NyaXB0aW9uIGJhc2lzLiBTZWNQb2Qgd2FzIHRoZSBm aXJzdCBjb21wYW55IHRvIGNyZWF0ZSBhbiBTQ0FQIENvbnRlbnQgUmVwb3NpdG9yeSBhbmQgdG8g cHJvdmlkZSBhIHN0YW5kYXJkIHByb3RvY29sIGZvciBhY2Nlc3NpbmcgaXQuIFdpdGggYWxsIGR1 ZSByZXNwZWN0IGFuZCBhcHByZWNpYXRpb24gZm9yIHlvdXIgd29yayAod2hpY2ggSSB0aGluayBp cyBvZiB0aGUgaGlnaGVzdCBxdWFsaXR5KSwgeW91IG1heSBoYXZlIGEgcGVyc29uYWwgYmlhcyB0 b3dhcmQgc3RhbmRhcmRpemluZyBhIGNvbnRlbnQgcmVwb3NpdG9yeSBwcm90b2NvbC4gQ291bGQg eW91IG9mZmVyIGEgY29tcGVsbGluZyB0ZWNobmljYWwgcmF0aW9uYWxlIGZvciBkb2luZyBzbyBh dCB0aGlzIHRpbWUgYW5kIGFzIGEgcGFydCBvZiBVQzE/IEkmIzgyMTc7ZCBhbHNvIGxpa2UgdG8g aGVhciBmcm9tIG90aGVyIFNBQ00gcGFydGljaXBhbnRzIG9uIHRoaXMgdG9waWMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkxldCdzIGxvb2sgYXQgdGhpcyBm cm9tIHRoZSBlbmQgZ29hbC4gJm5ic3A7SW1hZ2luZSB0aGF0IHdlJ3JlICZxdW90O2RvbmUmcXVv dDsgd2l0aCBVc2UgQ2FzZSAxLiAmbmJzcDtBIHNldCBvZiBzdGFuZGFyZHMgdGhhdCBhbGxvdyB1 cyB0bzogMSkgZGVmaW5lIHRoZSB0YXJnZXQgc3lzdGVtLCAyKSBzZWxlY3QgYWNjZXB0YWJsZSBz dGF0ZSBwb2xpY3ksIDMpIHJldHJpZXZlIGRhdGEgY29sbGVjdGlvbiBpbnN0cnVjdGlvbnMsIDQp IGNvbGxlY3QgYWN0dWFsIHN0YXRlIHZhbHVlcywgYW5kIDUpIGNvbXBhcmUgYWN0dWFsIHN0YXRl IHZhbHVlcy4gJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhl cmUgYXJlIHR3byB3YXlzIHdlIGNhbiBkZWFsIHdpdGggdGhlIHNlbGVjdGlvbiBhbmQgcmV0cmll dmFsIG9mIHBvbGljeSBhbmQgY29sbGVjdGlvbiBpbnN0cnVjdGlvbnMgKHN0ZXBzIDIgYW5kIDMs IHJlc3BlY3RpdmVseSkuICZuYnNwO1dlIGNhbiBsZWF2ZSBpdCB1cCB0byBzcGVjaWZpYyBpbXBs ZW1lbnRhdGlvbnMgdG8gZmlndXJlIGl0IG91dCBvbiB0aGVpciBvd24gYW5kIGVuZCB1cCB3aXRo IHByb3ByaWV0YXJ5IHNvbHV0aW9ucywgb3IsIGFzIHByZXNlbnRlZCBpbiBBdGxhbnRhLCB3ZSBj YW4gc3BlY2lmeSB0aGUgbWV0aG9kKHMpIGJ5IHdoaWNoIGltcGxlbWVudGF0aW9ucyBjYW4gY29u bmVjdCB0byBhbmQgaW50ZXJhY3Qgd2l0aCB0aGUgc3RvcmFnZSBvZiB0aGF0IGluZm9ybWF0aW9u LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgYXNrIG15c2VsZiB0aGlz IHF1ZXN0aW9uOiBIb3cgdXNlZnVsIGlzIGl0IHRvIGRlZmluZSBhIGNvbnRlbnQtZHJpdmVuIGFz c2Vzc21lbnQgbWV0aG9kIHdpdGhvdXQgcHJvdmlkaW5nIHRoZSBhY2NvbXBhbnlpbmcgbWV0aG9k IG9mIHRyYW5zbWl0dGluZyB0aGF0IGNvbnRlbnQ/ICZuYnNwO1RvIG1lLCBpdCdzIG5vdCBhIGJl bmVmaXQgdG8gdGhlIGNvbW11bml0eSBhdCBhbGwgd2l0aG91dCBhZGRyZXNzaW5nIHRoZSBiYXNp YyByZXF1aXJlbWVudCBvZiBnZXR0aW5nIHRoZSBjb250ZW50IGZyb20gb25lIHBsYWNlIHRvIGFu b3RoZXIuICZuYnNwO1RoZSBnb2FsIGhlcmUgaXMgYXV0b21hdGlvbiwgYW5kIHdpdGhvdXQgdGhh dCwgd2UncmUga2VlcGluZyBvbmUgb2YgdGhlIHdvcnN0IG1hbnVhbCBwcm9jZXNzZXMgYXJvdW5k LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldoaWxlIHRoaXMgbWF5IG5v dCBiZSBhICZxdW90O3RlY2huaWNhbCZxdW90OyByZWFzb24gZm9yIGtlZXBpbmcgdGhlIGNvbnRl bnQgcmVwb3NpdG9yeSBpbiBzY29wZSwgSSByZWFsbHkgY2FuJ3QgaW1hZ2luZSBhIHRydWx5IHVz ZWZ1bCBzZXQgb2Ygc3RhbmRhcmRzIHdpdGhvdXQgb25lLiAmbmJzcDtJZiB0aGVyZSdzIG9uZSB0 aGluZyBJIHRoaW5rIHdlJ3ZlIGxlYXJuZWQgaW4gdGhlIHNlY3VyaXR5IGF1dG9tYXRpb24gY29t bXVuaXR5IHNvIGZhciwgaXQncyB0aGF0IHlvdSBjYW4gc3BlYyBzY2hlbWEgYWxsIGRheSBsb25n LCBidXQgaWYgeW91IGRvbid0IGhhdmUgYSBnb29kIHdheSB0byBpbnRlcm9wZXJhdGUgaW4gYW4g YXV0b21hdGVkIHdheSB3aXRoIG90aGVyIHRvb2xzIGFuZC9vciBleHRlcm5hbCBlbnRpdGllcywg eW91J3JlIHRyZWFkaW5nIHdhdGVyLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPlNvLCBJJ20gYSBzdHJvbmcgYWR2b2NhdGUgZm9yIGV4cGxpY2l0bHkgcmVjb2duaXppbmcg dGhlIG5lZWQgZm9yIGRlZmluaW5nIHRoZSBtZXRob2QgYnkgd2hpY2ggaW1wbGVtZW50YXRpb25z IHNob3VsZCBleHBlY3QgdG8gY29ubmVjdCB0byBhIGNvbnRlbnQgcmVwb3NpdG9yeSwgYW5kLCB0 aGVyZWZvcmUsIGZvciBrZWVwaW5nIHRoYXQgc3F1YXJlbHkgaW4gc2NvcGUgZm9yIFVDMS48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxicj5TdGV2ZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5DaGFuZHJhc2hla2hhciBCIFttYWls dG86YmNoYW5kcmFAPGEgaHJlZj0iaHR0cDovL3NlY3BvZC5jb20iPnNlY3BvZC5jb208L2E+XTxz cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPjxiPlNlbnQ6 PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+VGh1cnNk YXksIERlY2VtYmVyIDEzLCAyMDEyIDk6NDcgQU08YnI+PGI+VG86PC9iPjxzcGFuIGNsYXNzPWFw cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+U3RlcGhlbiBIYW5uYTsgJ0FkYW0gTW9u dHZpbGxlJzxicj48Yj5DYzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwv YT48YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj5SRTogW3NhY21dIFNBQ00gVUMxIEFuZCBSZWxhdGVkIFJlcXVpcmVtZW50czwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDtDaGFuZHJhIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZndDsmZ3Q7IERhdGEgY29sbGVjdG9yIG5lZWRzIHRvIGhhdmUgdGhlIGFzc2Vzc21lbnQgY29u dGVudCBmb3IgcGVyZm9ybWluZyB0aGUgdGFzazwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDsmZ3Q7IHRo ZSBkYXRhIHJlcXVlc3RvciBhc2tlZCBmb3IuIFRoaXMgaXMgNC4xLjQgZnJvbSB1c2UgY2FzZSBk b2N1bWVudC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7UGVy aGFwcy4gSWYgdGhlIGNvbW11bmljYXRpb25zIGJldHdlZW4gdGhlIGRhdGEgcmVxdWVzdG9yIGFu ZCB0aGUgZGF0YSBjb2xsZWN0b3IgaW5jbHVkZWQgYWxsIHRoZSBuZWNlc3NhcnkgJmd0O2NvbnRl bnQsIHRoaXMgaW50ZXJhY3Rpb24gY291bGQgdGFrZSBwbGFjZSB3aXRob3V0IG5lZWRpbmcgYSBz ZXBhcmF0ZSBjb250ZW50IHJlcG9zaXRvcnkuIE1heWJlIHRoaXMgd291bGQgbm90ICZndDtiZSBl ZmZpY2llbnQgc28gaXQmIzgyMTc7cyBkZXNpcmFibGUgdG8gdXNlIHJlZmVyZW5jZXMgdG8gY29u dGVudCBpbnN0ZWFkIG9mIHNlbmRpbmcgdGhlIGNvbnRlbnQgaXRzZWxmLiBJcyB0aGlzIHRydWU/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhdCBjb3VsZCBiZSBh bm90aGVyIHNjZW5hcmlvLiBJbiB3aGljaCBjYXNlLCBkYXRhIHJlcXVlc3RvciBpcyBiZWhhdmlu ZyBsaWtlIGEgY29udGVudCByZXBvc2l0b3J5IHdpdGggYSBwdXNoIG1vZGVsLiBCdXQsIGl0IGlz IGRlc2lyYWJsZSBpbiBteSB2aWV3IHRvIHVzZSByZWZlcmVuY2VzIHNvIGRhdGEgY29sbGVjdG9y IGNvdWxkIHB1bGwgdGhlIGNvbnRlbnQgb3IgZGF0YSBjb2xsZWN0b3Iga25vd3MgaG93IHRvIGdl dCB0aGUgY29udGVudCBiYXNlZCBvbiB0aGUgaW5zdHJ1Y3Rpb25zIGdpdmVuIGJ5IHRoZSByZXF1 ZXN0b3IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2hhbmRyYS48 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z cGFuPjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+Q2hhbmRyYXNoZWtoYXIgQiBbPGEgaHJlZj0ibWFpbHRvOmJj aGFuZHJhQHNlY3BvZC5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUnPm1haWx0bzpiY2hh bmRyYUBzZWNwb2QuY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNw YWNlPiZuYnNwOzwvc3Bhbj48YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgRGVjZW1iZXIgMTMsIDIwMTIgMTozMiBB TTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj5TdGVwaGVuIEhhbm5hOyAnQWRhbSBNb250dmlsbGUnPGJyPjxiPkNjOjwvYj48c3BhbiBj bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpz YWNtQGlldGYub3JnIj48c3BhbiBzdHlsZT0nY29sb3I6cHVycGxlJz5zYWNtQGlldGYub3JnPC9z cGFuPjwvYT48YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNw YWNlPiZuYnNwOzwvc3Bhbj5SRTogW3NhY21dIFNBQ00gVUMxIEFuZCBSZWxhdGVkIFJlcXVpcmVt ZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDtBZGFtIE1vbnR2aWxsZSB3cm90ZTo8L3Nw YW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4mZ3Q7Jmd0OyAmZ3Q7IDIpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IERvIHdlIHJlYWxseSBuZWVkIHByb3RvY29scyBmb3IgYWNjZXNzaW5nIGEgY29udGVudCBy ZXBvc2l0b3J5IGZvciBVQzE/IFdoeT88L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7Jmd0OyZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZndDsmZ3Q7IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlc2UgYXJlIGxp a2VseSB0byBiZSAmcXVvdDtsaWdodCwmcXVvdDsgYnV0IGFyZSBuZWVkZWQuJm5ic3A7IEhvdyBk byB3ZSBleHBlY3QgdG8gZ2V0IGluZm9ybWF0aW9uIGZyb20gb25lIHBsYWNlIHRvIHRoZSBuZXh0 IHdpdGhvdXQgYXQgbGVhc3QgZGVmaW5pbmcgd2hhdCBhbiBhY2Nlc3MgQVBJIG1pZ2h0IGxvb2sg bGlrZSwgd2hhdCBzdXBwb3J0ZWQgdHJhbnNwb3J0IHByb3RvY29scyBleGlzdCBmb3IgdGhlIGdp dmVuIHRlY2hub2xvZ3ksIGFuZCB3aGF0IGlkZW50aWZpZXJzIHRvIHVzZSwgZXRjLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDsgSSB1bmRlcnN0YW5kIHdoeSB3 ZSB3YW50IHRvIGhhdmUgYSBzdGFuZGFyZCBwcm90b2NvbCBmb3IgY29udmV5aW5nIHRoZSB0YXJn ZXQgc3lzdGVtIGlkZW50aWZpY2F0aW9uIGFuZCBkYXRhIGNvbGxlY3Rpb24gaW5zdHJ1Y3Rpb25z IHRvIHRoZSBkYXRhIGNvbGxlY3RvciBhbmQgZm9yIGdldHRpbmcgYmFjayB0aGUgc3RhdGUgdmFs dWVzLiBJIGp1c3QgZG9uJiM4MjE3O3QgdW5kZXJzdGFuZCB3aHkgd2UgbmVlZCBhIHN0YW5kYXJk IHByb3RvY29sIGZvciB0YWxraW5nIHRvIGEgY29udGVudCByZXBvc2l0b3J5IGZvciBVQzEuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jmd0O01heWJlIHdlIGhhdmUg YSBkaWZmZXJlbnQgaWRlYSBvZiBob3cgVUMxIHdvcmtzLiBJIHRoaW5rIFVDMSBpcyBzYXlpbmcg dGhhdCBvbmUgcGFydHkgKGNhbGwgaXQgdGhlICYjODIyMDtkYXRhIHJlcXVlc3RvciYjODIyMTsp IGFza3MgYSBzZWNvbmQgcGFydHkgKGNhbGwgaXQgdGhlICYjODIyMDtkYXRhIGNvbGxlY3RvciYj ODIyMTspIHRvIGdhdGhlciBkYXRhICgmIzgyMjA7c3RhdGUgdmFsdWVzJiM4MjIxOykgcmVsYXRp bmcgdG8gdGhlIHNlY3VyaXR5IG9mIGEgdGhpcmQgcGFydHkgKHRoZSAmIzgyMjA7dGFyZ2V0IHN5 c3RlbSYjODIyMTspLiBTbyB3ZSBuZWVkIHN0YW5kYXJkIHByb3RvY29scyBhbmQgZGF0YSBmb3Jt YXRzIHRoYXQgdGhlIGRhdGEgcmVxdWVzdG9yIGNhbiB1c2Ugd2hlbiB0YWxraW5nIHRvIHRoZSBk YXRhIGNvbGxlY3Rvci4gVG8gZ2l2ZSBhIGNvbmNyZXRlIGV4YW1wbGUsIHRoZSBkYXRhIHJlcXVl c3RvciBtaWdodCBzYXkgJiM4MjIwO1NlbmQgbWUgdGhlIGxpc3Qgb2Ygc29mdHdhcmUgaW5zdGFs bGVkIG9uIGRldmljZSAzNzQ2MjkmIzgyMjE7IGFuZCB0aGUgZGF0YSBjb2xsZWN0b3IgbWlnaHQg cmVzcG9uZCB3aXRoIGEgbGlzdCBvZiBpbnN0YWxsZWQgc29mdHdhcmUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jmd0O1dpdGggdGhhdCBtb2RlbCwgdGhlIHF1ZXN0 aW9uIG9mIGhvdyB0aGUgZGF0YSBjb2xsZWN0b3IgZ2F0aGVycyBkYXRhIGFib3V0IHRoZSB0YXJn ZXQgc3lzdGVtICh0aHJvdWdoIHRoZSBORUEgcHJvdG9jb2xzIG9yIHZpYSBXTUkgb3IgU1NIKSBp cyBub3Qgb3VyIHByb2JsZW0uIEFuZCBob3cgdGhlIGRhdGEgcmVxdWVzdG9yIGRldGVybWluZXMg dGhlIGxpc3Qgb2Ygc3RhdGUgdmFsdWVzIHRvIHJlcXVlc3QgaXMgbm90IG91ciBwcm9ibGVtLiBB cmd1YWJseSwgZXZlbiB0aGUgbmF0dXJlIG9mIHRoZSBwb2xpY2llcyB1c2VkIGJ5IHRoZSBkYXRh IHJlcXVlc3RvciB0byBkZXRlcm1pbmUgd2hldGhlciBpdCBsaWtlcyB0aGUgc3RhdGUgdmFsdWVz IG1heSBub3QgYmUgb3VyIHByb2JsZW0uIEJ1dCBJIGNlcnRhaW5seSBkb24mIzgyMTc7dCBzZWUg YW55IG5lZWQgZm9yIGNvbnRlbnQgcmVwb3NpdG9yeSBwcm90b2NvbHMgaW4gdGhpcyBtb2RlbC48 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7RG8geW91IGhhdmUg YSBkaWZmZXJlbnQgbW9kZWwgZm9yIFVDMT8gSSByZWFsaXplIHRoYXQgdGhpcyBpcyBzdHJheWlu ZyBpbnRvIGFyY2hpdGVjdHVyZSBzb21ld2hhdCBidXQgSSBkb24mIzgyMTc7dCB0aGluayB3ZSYj ODIxNztsbCBiZSBhYmxlIHRvIGNvbWUgdXAgd2l0aCBhIHNldCBvZiByZXF1aXJlbWVudHMgdW5s ZXNzIHdlIGhhdmUgYSBjb21tb24gbW9kZWwgZm9yIHdoYXQgdGhlIGFjdG9ycyBpbiB0aGUgc3lz dGVtIGFyZSBhbmQgaG93IHRoZXkgaW50ZXJhY3QgdG8gYWNoaWV2ZSB0aGUgZ29hbHMgb2YgdGhl IHVzZSBjYXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMEIwRjAnPkRhdGEg Y29sbGVjdG9yIG5lZWRzIHRvIGhhdmUgdGhlIGFzc2Vzc21lbnQgY29udGVudCBmb3IgcGVyZm9y bWluZyB0aGUgdGFzayB0aGUgZGF0YSByZXF1ZXN0b3IgYXNrZWQgZm9yLiBUaGlzIGlzIDQuMS40 IGZyb20gdXNlIGNhc2UgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwQjBGMCc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzAwQjBGMCc+Q2hhbmRyYS48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+QWRhbSBNb250dmlsbGUgWzxh IGhyZWY9Im1haWx0bzphbW9udHZpbGxlQHRyaXB3aXJlLmNvbSI+PHNwYW4gc3R5bGU9J2NvbG9y OnB1cnBsZSc+bWFpbHRvOmFtb250dmlsbGVAdHJpcHdpcmUuY29tPC9zcGFuPjwvYT5dPHNwYW4g Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+PGI+U2VudDo8L2I+ PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXks IERlY2VtYmVyIDEyLCAyMDEyIDEyOjA5IFBNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFzcz1hcHBs ZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPlN0ZXBoZW4gSGFubmE8YnI+PGI+Q2M6PC9i PjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnNhY21AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUnPnNhY21AaWV0 Zi5vcmc8L3NwYW4+PC9hPjxicj48Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPlJlOiBTQUNNIFVDMSBBbmQgUmVsYXRlZCBSZXF1aXJl bWVudHM8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPk9uIERlYyAxMiwgMjAxMiwgYXQgOTowMiBBTSwgU3RlcGhlbiBIYW5uYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNoYW5uYUBqdW5pcGVyLm5ldCI+PHNwYW4gc3R5bGU9J2NvbG9yOnB1 cnBsZSc+c2hhbm5hQGp1bmlwZXIubmV0PC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFkYW0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyBmb3IgcHV0dGlu ZyB0b2dldGhlciB0aGlzIGluaXRpYWwgbGlzdCBvZiByZXF1aXJlbWVudHMuIFRoaXMgaXMgYSBn b29kIHN0YXJ0LiBJIGRvIGhhdmUgc29tZSBxdWVzdGlvbnM6PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu dDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+MSk8L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklzIEJZT0QgaW4gc2NvcGU/IEkgdGhpbmsgaXQgc2hvdWxk IGJlLiBJdCYjODIxNztzIGEgZmFjdCBvZiBsaWZlIGluIGVudGVycHJpc2UgbmV0d29ya3MgdG9k YXkuIElmIHBlb3BsZSBhZ3JlZSwgSSB3b3VsZCByZWNvbW1lbmQgY2hhbmdpbmcgeW91ciBzZWNv bmQgcmVxdWlyZW1lbnQgdG8gYWRkIHRoaXMgYXQgdGhlIGVuZDogJiM4MjIwO29yIGJyb3VnaHQg YW5kIG93bmVkIGJ5IGVuZCB1c2VycyYjODIyMTsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGlzIGNoYW5nZSBzZWVtcyByZWFz b25hYmxlIHRvIG1lLiAmbmJzcDtXZSBjYW4gZW5zdXJlIHdlIGFkZHJlc3MgdGhlIGlzc3VlLCBh bmQgdGhlbiBsZWF2ZSBpdCB0byBvcmdhbml6YXRpb25zIHVzaW5nIGltcGxlbWVudGF0aW9ucyBv ZiB0aGUgc3RhbmRhcmRzL2d1aWRlbGluZXMgd2UgcHJvZHVjZSBhcyB0byBob3cgdGhleSB3YW50 IHRvIGFwcGx5IHRoZSB0ZWNobm9sb2d5LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+Jm5ic3A7PG86 cD48L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjIpPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3 RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EbyB3 ZSByZWFsbHkgbmVlZCBwcm90b2NvbHMgZm9yIGFjY2Vzc2luZyBhIGNvbnRlbnQgcmVwb3NpdG9y eSBmb3IgVUMxPyBXaHk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkl0IHNlZW1zIHRvIG1lIHRoYXQg dGhlc2UgYXJlIGxpa2VseSB0byBiZSAmcXVvdDtsaWdodCwmcXVvdDsgYnV0IGFyZSBuZWVkZWQu ICZuYnNwO0hvdyBkbyB3ZSBleHBlY3QgdG8gZ2V0IGluZm9ybWF0aW9uIGZyb20gb25lIHBsYWNl IHRvIHRoZSBuZXh0IHdpdGhvdXQgYXQgbGVhc3QgZGVmaW5pbmcgd2hhdCBhbiBhY2Nlc3MgQVBJ IG1pZ2h0IGxvb2sgbGlrZSwgd2hhdCBzdXBwb3J0ZWQgdHJhbnNwb3J0IHByb3RvY29scyBleGlz dCBmb3IgdGhlIGdpdmVuIHRlY2hub2xvZ3ksIGFuZCB3aGF0IGlkZW50aWZpZXJzIHRvIHVzZSwg ZXRjLiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5JIGRvbid0IHRoaW5rIHdlIG5lZWQgYW55dGhpbmcgaGVhdnksIGp1c3Qg ZW5vdWdoIHRvIHNheTogSWYgeW91IHdhbnQgdG8gZ2V0IGFzc2Vzc21lbnQgY29udGVudCwgZmlu ZCB0aGUgY29udGVudCByZXBvc2l0b3J5LCBhbmQgZm9ybSB5b3VyIHJlcXVlc3QgbGlrZSB0aGlz LCBhbmQgeW91J2xsIGdldCB5b3VyIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Ob3Rpb25hbGx5LCBpdCdzIGVhc3kg Zm9yIG1lIHRvIHNlZSBhIHNlcnZpY2Utb3JpZW50ZWQgaW50ZXJmYWNlIHVzaW5nIGEgUkVTVCBB UEkgdG8gZ2V0IHRoaXMgdHlwZSBvZiB0aGluZyBkb25lLCBidXQgdGhhdCdzIGdldHRpbmcgdGhl IGNhcnQgYmVmb3JlIHRoZSBob3JzZSwgSSB0aGluay48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4m bmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkm IzgyMTc7bSBnbGFkIHRvIHNlZSB1cyBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRoaXMgYW5kIG90aGVy IGlzc3Vlcy48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+VGFrZSBjYXJlLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TdGV2ZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjxhIGhy ZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJw bGUnPnNhY20tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5bbWFpbHRvOnNhY20tPGEgaHJlZj0ibWFpbHRvOmJv dW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUnPmJvdW5jZXNAaWV0Zi5v cmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z cGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJz cDs8L3NwYW4+PC9iPkFkYW0gTW9udHZpbGxlPGJyPjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPWFw cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIgMTEsIDIw MTIgMTozOSBQTTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNl PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 J2NvbG9yOnB1cnBsZSc+c2FjbUBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPjxiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+W3NhY21dIFNB Q00gVUMxIEFuZCBSZWxhdGVkIFJlcXVpcmVtZW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QWxsOjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5B ZnRlciB0cm9sbGluZyB0aHJvdWdoIHNvbWUgb2YgdGhlIFNBQ00gbWFpbGluZyBsaXN0LCBhbmQg cmV2aWV3aW5nIFNBQ00gQm9GIG1pbnV0ZXMgZnJvbSBJRVRGIDg1IGFuZCB0aGUgY3VycmVudCBV c2UgQ2FzZSBkcmFmdCBsb29raW5nIGZvciByZXF1aXJlbWVudHMsIGFuZCBoZXJlJ3Mgd2hhdCBJ J3ZlIHB1bGxlZCB0b2dldGhlciBzbyBmYXI6Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2Pjx1bCBzdHlsZT0nbWFyZ2luLXRvcDowaW4nIHR5cGU9ZGlzYz48bGkgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+VUMxIG11c3QgcHJv dmlkZSBjb3ZlcmFnZSBmb3IgZW50ZXJwcmlzZXMgb2YgdmFyaW91cyBzaXplcyBhbmQgaW5jbHVk ZSBzdXBwb3J0IGZvciBhc3NldHMgZGVsaXZlcmVkIGJ5IHRoaXJkLXBhcnRpZXM8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEn PkFzc2V0IHJlcHJlc2VudGF0aW9uL2lkZW50aWZpY2F0aW9uIHNob3VsZCBzdXBwb3J0IHRob3Nl IGRlbGl2ZXJlZCBieSBhIGdpdmVuIFNlcnZpY2UgUHJvdmlkZXIgKFNQKTxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+U3Vw cG9ydGluZyBkYXRhIGZvcm1hdHMgYW5kL29yIHByb3RvY29scyBzaG91bGQgc3VwcG9ydCBhc3Nl c3NtZW50IG9mIFNQLXByb3ZpZGVkIGFzc2V0czxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+TXVzdCBwcm92aWRlIGEgbWV0 aG9kIG9mIGRlZmluaW5nIGEgdGFyZ2V0IHN5c3RlbSAoYXNzZXQgaWRlbnRpZmljYXRpb247IGFz c2V0IGNsYXNzaWZpY2F0aW9uKTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+TXVzdCBwcm92aWRlIGEgbWV0aG9kIG9mIHNl bGVjdGluZyBhY2NlcHRhYmxlIHN0YXRlIHBvbGljeSAodGVzdCBleHByZXNzaW9uKTxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZv MSc+TXVzdCBwcm92aWRlIGEgbWV0aG9kIG9mIHJldHJpZXZpbmcgZGF0YSBjb2xsZWN0aW9uIGlu c3RydWN0aW9ucyAoYWN0aXZpdHkgY2xhc3M6IGNvbmZpZ3VyYXRpb24sIHBhdGNoLCB2dWxuZXJh YmlsaXR5LCBpbnZlbnRvcnk7IG9iamVjdCByZXByZXNlbnRhdGlvbjsgc3RhdGUgcmVwcmVzZW50 YXRpb24pPG86cD48L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1saXN0 OmwwIGxldmVsMSBsZm8xJz5NdXN0IHByb3ZpZGUgYSBtZXRob2Qgb2YgZXhwcmVzc2luZyBzdGF0 ZSBjb2xsZWN0aW9uIHZhbHVlcyAoY29sbGVjdGlvbiBsYW5ndWFnZTogdGVjaG5pY2FsLCBpbnRl cnJvZ2F0aXZlOyBvYmplY3QgcmVwcmVzZW50YXRpb24pPG86cD48L286cD48L2xpPjxsaSBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1saXN0OmwwIGxldmVsMSBsZm8xJz5NdXN0IHByb3ZpZGUg YSBtZXRob2Qgb2YgY29tcGFyaW5nIGFjdHVhbCB0byBleHBlY3RlZCBzdGF0ZSB2YWx1ZXMgKHRl c3QgZXZhbHVhdGlvbjsgdGVzdCBleHByZXNzaW9uKTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+TXVzdCBwcm92aWRlIGEg cHJvdG9jb2wgZm9yIGNvbm5lY3RpbmcgdG8gYSBjb250ZW50IHJlcG9zaXRvcnkgY29udGFpbmlu ZyBTQUNNIGNvbnRlbnQ8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPk11c3QgcHJvdmlkZSBhIHByb3RvY29sIGZvciBxdWVy eWluZyBTQUNNIGNvbnRlbnQgaGVsZCBpbiBhIGNvbnRlbnQgcmVwb3NpdG9yeTxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+ TXVzdCBwcm92aWRlIGEgcHJvdG9jb2wgb2YgcmV0cmlldmluZyBTQUNNIGNvbnRlbnQgZnJvbSBh IGNvbnRlbnQgcmVwb3NpdG9yeTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+TXVzdCBwcm92aWRlIGEgcHJvdG9jb2wgZm9y IGN1cmF0aW5nIFNBQ00gY29udGVudCBpbiBhIGNvbnRlbnQgcmVwb3NpdG9yeTxvOnA+PC9vOnA+ PC9saT48L3VsPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JbiBhZGRp dGlvbiB0byB0aGUgYWJvdmUsIEkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRoYXQgd2UgdGFrZTxz cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGk+PHU+Y2VydGFp biByZXF1aXJlbWVudHM8L3U+PC9pPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4m bmJzcDs8L3NwYW4+ZnJvbSBDU0lTIDIwIENyaXRpY2FsIFNlY3VyaXR5IENvbnRyb2xzIFsxXSB1 bmRlciB0aGUgZm9sbG93aW5nIGNvbnRyb2xzOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PGRpdj48dWwgc3R5bGU9J21hcmdpbi10b3A6MGluJyB0eXBlPWRpc2M+PGxpIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPkNyaXRpY2FsIENvbnRyb2wg MTogSW52ZW50b3J5IG9mIEF1dGhvcml6ZWQgYW5kIFVuYXV0aG9yaXplZCBEZXZpY2VzPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1saXN0OmwxIGxldmVsMSBs Zm8yJz5Dcml0aWNhbCBDb250cm9sIDI6IEludmVudG9yeSBvZiBBdXRob3JpemVkIGFuZCBVbmF1 dGhvcml6ZWQgU29mdHdhcmU8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPkNyaXRpY2FsIENvbnRyb2wgMzogU2VjdXJlIENv bmZpZ3VyYXRpb24gZm9yIEhhcmR3YXJlIGFuZCBTb2Z0d2FyZSBvbiBNb2JpbGUgRGV2aWNlcywg TGFwdG9wcywgV29ya3N0YXRpb25zLCBhbmQgU2VydmVyczxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+Q3JpdGljYWwgQ29u dHJvbCA0OiBDb250aW51b3VzIFZ1bG5lcmFiaWxpdHkgQXNzZXNzbWVudCBhbmQgUmVtZWRpYXRp b248bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzInPkNyaXRpY2FsIENvbnRyb2wgNTogTWFsd2FyZSBEZWZlbnNlczxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGlzdDpsMSBsZXZlbDEgbGZv Mic+Q3JpdGljYWwgQ29udHJvbCAxMDogU2VjdXJlIENvbmZpZ3VyYXRpb25zIGZvciBOZXR3b3Jr IERldmljZXMgc3VjaCBhcyBGaXJld2FsbHMsIFJvdXRlcnMsIGFuZCBTd2l0Y2hlczxvOnA+PC9v OnA+PC9saT48L3VsPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgaGF2 ZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGk+PHU+bm90 IHlldDwvdT48L2k+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bh bj5wYXJzZWQgdGhyb3VnaCBlYWNoIG9mIHRoZSBDcml0aWNhbCBDb250cm9scywgYnV0IGFudGlj aXBhdGUgbW9yZSBkZXRhaWxlZCByZXF1aXJlbWVudHMgdG8gY29tZSBvdXQgb2YgdGhlbS4gJm5i c3A7SSBlbXBoYXNpemUgdGhhdCB3ZSB3aWxsIG5vdCBiZSBzZWVraW5nIHRvIG1lZXQgZXZlcnkg cmVxdWlyZW1lbnQgZXhwcmVzc2VkIGJ5IGEgZ2l2ZW4gQ3JpdGljYWwgQ29udHJvbC4gJm5ic3A7 Rm9yIGV4YW1wbGUsIHdlIG1heSBub3QgYmUgaW4gYSBwb3NpdGlvbiB0byBleHByZXNzICZxdW90 O2F1dGhvcml6YXRpb25zJnF1b3Q7IGZvciBzb2Z0d2FyZSBpbnN0YWxsZWQgb24gYW4gb3BlcmF0 aW5nIHN5c3RlbSBpbiBhIGdpdmVuIGNvbnRleHQuICZuYnNwO0J1dCwgQ3JpdGljYWwgQ29udHJv bCAyIGRvZXMgcmVxdWlyZSBhY2N1cmF0ZSBhbmQgbWVhbmluZ2Z1bCBhc3NldCBpZGVudGlmaWNh dGlvbiAoYXMgZG9lcyBDcml0aWNhbCBDb250cm9sIDEsIGZvciB0aGF0IG1hdHRlciksIHdoaWNo IGlzIHNvbWV0aGluZyB3aXRoIHdoaWNoIHdlIHNob3VsZCBiZSBjb25jZXJuZWQuPG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgaGF2 ZSB0aGlzIEZyaWRheSAoMTIvMTQpIGRlZGljYXRlZCB0byBmbGVzaGluZyBvdXQgdGhlc2UgcmVx dWlyZW1lbnRzLiAmbmJzcDtJZiB5b3UgaGF2ZSBjb250cmlidXRpb25zIHRvIG1ha2UsIEkgcmVz cGVjdGZ1bGx5IHJlcXVlc3QgdGhhdCB5b3UgZG8gc28gYmVmb3JlIHRoZW4uPG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlJlZ2FyZHMs PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4m bmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPkFkYW08bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5zYW5zLm9yZy9jcml0aWNh bC1zZWN1cml0eS1jb250cm9scy8iPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUnPmh0dHA6Ly93 d3cuc2Fucy5vcmcvY3JpdGljYWwtc2VjdXJpdHktY29udHJvbHMvPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIHN0eWxlPSdtYXJn aW4tYm90dG9tOjEwLjVwdDtvcnBoYW5zOiAyO3RleHQtYWxpZ246LXdlYmtpdC1hdXRvO3dpZG93 czogMjstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PGJyPkFkYW0gVy4gTW9udHZp bGxlJm5ic3A7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPnwgU2VjdXJpdHkgYW5kIENvbXBsaWFuY2UgQXJj aGl0ZWN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEwLjVw dDtvcnBoYW5zOiAyO3RleHQtYWxpZ246LXdlYmtpdC1hdXRvO3dpZG93czogMjstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+RGlyZWN0OiA1MDMgMjc2LTc2NjE8YnI+TW9iaWxlOiAzNjAg NDcxLTc4MTUgJm5ic3A7ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMC41cHQ7b3JwaGFuczogMjt0ZXh0LWFsaWduOi13ZWJraXQtYXV0bzt3aWRv d3M6IDI7LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Jz48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJyPjwvc3Bhbj48L2k+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+VFJJUFdJUkU8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFj ZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPnw8c3BhbiBjbGFzcz1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyIsInNlcmlmIic+Q09ORklERU5DRTwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz46 PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48Yj5TRUNVUkVE PC9iPjxicj48YSBocmVmPSJodHRwOi8vd3d3LnRyaXB3aXJlLmNvbS8iPjxzcGFuIHN0eWxlPSdj b2xvcjpwdXJwbGUnPnd3dy50cmlwd2lyZS5jb208L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50 ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBub3No YWRlIHN0eWxlPSdjb2xvcjojQTBBMEEwJyBhbGlnbj1jZW50ZXI+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Tm8gdmlydXMgZm91bmQgaW4gdGhpcyBtZXNzYWdlLjxicj5DaGVja2VkIGJ5 IEFWRyAtPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJodHRwOi8vd3d3LmF2Zy5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUnPnd3dy5h dmcuY29tPC9zcGFuPjwvYT48YnI+VmVyc2lvbjogMjAxMy4wLjI4MDUgLyBWaXJ1cyBEYXRhYmFz ZTogMjYzNC81OTUzIC0gUmVsZWFzZSBEYXRlOiAxMi8xMi8xMjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGln bjpjZW50ZXInPjxociBzaXplPTEgd2lkdGg9IjEwMCUiIG5vc2hhZGUgc3R5bGU9J2NvbG9yOiNB MEEwQTAnIGFsaWduPWNlbnRlcj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ObyB2aXJ1 cyBmb3VuZCBpbiB0aGlzIG1lc3NhZ2UuPGJyPkNoZWNrZWQgYnkgQVZHIC08c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuYXZn LmNvbSI+PHNwYW4gc3R5bGU9J2NvbG9yOnB1cnBsZSc+d3d3LmF2Zy5jb208L3NwYW4+PC9hPjxi cj5WZXJzaW9uOiAyMDEzLjAuMjgwNSAvIFZpcnVzIERhdGFiYXNlOiAyNjM0LzU5NTQgLSBSZWxl YXNlIERhdGU6IDEyLzEyLzEyPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPnNhY20gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYu b3JnIj5zYWNtQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhY20iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FjbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEwLjVwdDttYXJnaW4tbGVm dDowaW47b3JwaGFuczogMjt0ZXh0LWFsaWduOi13ZWJraXQtYXV0bzt3aWRvd3M6IDI7LXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3 b3JkLXNwYWNpbmc6MHB4Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxicj5BZGFtIFcuIE1vbnR2 aWxsZSZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz58IFNlY3VyaXR5IGFuZCBD b21wbGlhbmNlIEFyY2hpdGVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTAuNXB0O21h cmdpbi1sZWZ0OjBpbjtvcnBoYW5zOiAyO3RleHQtYWxpZ246LXdlYmtpdC1hdXRvO3dpZG93czog Mjstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RGlyZWN0OiA1MDMg Mjc2LTc2NjE8YnI+TW9iaWxlOiAzNjAgNDcxLTc4MTUgJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206MTAuNXB0O21hcmdpbi1sZWZ0OjBpbjtvcnBoYW5zOiAyO3RleHQt YWxpZ246LXdlYmtpdC1hdXRvO3dpZG93czogMjstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgnPjxpPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz48YnI+PC9zcGFuPjwvaT48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5UUklQ V0lSRTwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+fDxzcGFuIGNs YXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIiwic2VyaWYiO2NvbG9yOmJsYWNr Jz5DT05GSURFTkNFPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjo8c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxiPlNFQ1VSRUQ8L2I+PGJyPjxhIGhyZWY9Imh0 dHA6Ly93d3cudHJpcHdpcmUuY29tLyI+d3d3LnRyaXB3aXJlLmNvbTwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930BAD85C538MBCLUSTERxcha_-- From mrex@sap.com Wed Dec 12 11:30:11 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73F721E8122 for ; Wed, 12 Dec 2012 11:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqGlzP7BhlU8 for ; Wed, 12 Dec 2012 11:30:10 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 925FF21E8121 for ; Wed, 12 Dec 2012 11:30:10 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qBCJU7e3022380; Wed, 12 Dec 2012 20:30:07 +0100 (MET) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA03E3E6@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" Date: Wed, 12 Dec 2012 20:30:07 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121212193007.95B781A3F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out X-Mailman-Approved-At: Thu, 13 Dec 2012 08:02:12 -0800 Cc: "david.oliva@verizon.net" , "mrex@sap.com" , "sacm@ietf.org" Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:30:11 -0000 David Oliva wrote: > > The monitoring which SACM performs is not about people's behavior. > The monitoring which SACM performs is of security mechanisms which > are of interest to organizations. > When organizations are expected by law to protect private information, > SACM monitors the security controls designed to protect privacy laws. Romascanu, Dan (Dan) wrote: > > I was also confused by the usage of the term ?monitoring? by the time > I was introducing myself in SACM. David Oliva ?s observation is correct, > ?monitoring? as used in SACM is about auditing the security controls > and mechanisms (although using ?auditing? instead could create other > confusions) Unless infected by malware and being turned into a remoted-controlled bot, a typical computing system will change its state based on user input, i.e. user behaviour. So if you track the state changes of a computer that is used by a user, you're actually tracking the behaviour of the user! Monitoring the which processes are started and stopped, monitoring which network ports they open and close and when and how much data they transfer, monitoring which files are written and read, even the DHCP address assigned to the machine is subject to the protections of the basic right of informational self-determination. what are the security mechanisms / security controls that you want to monitor? -Martin From mrex@sap.com Wed Dec 12 11:35:41 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCFC21E810D for ; Wed, 12 Dec 2012 11:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.989 X-Spam-Level: X-Spam-Status: No, score=-9.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVtHNSFk78JZ for ; Wed, 12 Dec 2012 11:35:40 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9949021E80F4 for ; Wed, 12 Dec 2012 11:35:40 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qBCJZZaj007884; Wed, 12 Dec 2012 20:35:35 +0100 (MET) In-Reply-To: <20121212193007.95B781A3F4@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Wed, 12 Dec 2012 20:35:35 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121212193535.490E01A3F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out X-Mailman-Approved-At: Thu, 13 Dec 2012 08:02:12 -0800 Cc: "david.oliva@verizon.net" , "Romascanu, Dan \(Dan\)" , "sacm@ietf.org" Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:35:41 -0000 Martin Rex wrote: > > David Oliva wrote: > > > > The monitoring which SACM performs is not about people's behavior. > > The monitoring which SACM performs is of security mechanisms which > > are of interest to organizations. > > When organizations are expected by law to protect private information, > > SACM monitors the security controls designed to protect privacy laws. > > Romascanu, Dan (Dan) wrote: > > > > I was also confused by the usage of the term ?monitoring? by the time > > I was introducing myself in SACM. David Oliva ?s observation is correct, > > ?monitoring? as used in SACM is about auditing the security controls > > and mechanisms (although using ?auditing? instead could create other > > confusions) > > Unless infected by malware and being turned into a remoted-controlled bot, > a typical computing system will change its state based on user input, > i.e. user behaviour. So if you track the state changes of a computer > that is used by a user, you're actually tracking the behaviour of the > user! > > Monitoring the which processes are started and stopped, monitoring which > network ports they open and close and when and how much data they transfer, > monitoring which files are written and read, even the DHCP address assigned > to the machine is subject to the protections of the basic right of > informational self-determination. > > > what are the security mechanisms / security controls that you want to monitor? actually, any processes that perform network communication, the ports they open, the data they transfer (including what they read from disk and write to disk or network shares) and the DHCP address assigned to the machine is subject to the protection of the constitutional telecommunication secrecy, and monitoring that information without an applicable statue law established by the parliamenarian legislator is not just illegal in Germany, it is a crime punishable with up to 5 years in prison. -Martin From solin@farnamhallventures.com Thu Dec 13 07:59:50 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACBD21F8B5A for ; Thu, 13 Dec 2012 07:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT-s-e0HSEA4 for ; Thu, 13 Dec 2012 07:59:45 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7592121F8B66 for ; Thu, 13 Dec 2012 07:59:45 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2308621oag.31 for ; Thu, 13 Dec 2012 07:59:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=oRbYQD8zDcwnNeFhsQxoz9kK0+vBmnwmtCsRbUSOyCA=; b=YXV3UJRIILWqu+dIeqcKsR0jB0sgwRoKA37qUeWwdXNwKfK/9E2SKk7zqY5hIXBa5F gif3i7s+aADS7Tq2PfxYufnYnnKxVRlhjHTSjY7meHF/+GgMwYPp2G98Ix7QeRUwI6dv 3ncb04xNDX2vu76dbEU0ViN1iCUEroI5ihHKrL3zfbLy8Jvs8ceWR5wsFSiD11kGzUHR fGf7HsArltp11UUfmH/knmaOXcdazD49zBbAes2tSJZcmhkBAEKNHisT3k4JXgHxS2WW kRzFNsaE8VSu5pmK/+AyBboNqmts7p+XHxKgrkvKqctmXYUZvL/Nv6016KoXZiOQbHjU Y5Fw== Received: by 10.60.32.73 with SMTP id g9mr1875879oei.134.1355414384669; Thu, 13 Dec 2012 07:59:44 -0800 (PST) Received: from [192.168.0.113] (99-57-135-11.lightspeed.austtx.sbcglobal.net. [99.57.135.11]) by mx.google.com with ESMTPS id u4sm1206009oeh.6.2012.12.13.07.59.43 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 07:59:43 -0800 (PST) Message-ID: <50C9FB6C.7000507@farnamhallventures.com> Date: Thu, 13 Dec 2012 09:59:40 -0600 From: David Solin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070005030901010801030104" X-Gm-Message-State: ALoCoQkVWYIFCSCuQh1M9u72dJ5lwnAkrq4VSZor1+eqnSFWzMvlQHUWSU79EHOBEIjzyV5uFrxq X-Mailman-Approved-At: Thu, 13 Dec 2012 08:02:12 -0800 Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:59:50 -0000 This is a multi-part message in MIME format. --------------070005030901010801030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have an opinion, but no commercial OVAL repository I'm selling... I do think it makes sense to introduce a standard protocol (or set of protocols) for interacting with a repository. We are already covering the format of the content, which is the biggest problem, so why not go the last mile and also specify a delivery protocol? If we do specify a protocol, it will be very easy for anyone to stand up their own content server that will plug-in with existing tools, to the immediate benefit of the entire community. For instance, if Juniper decided in the future to author its own SCAP content for its products, it could stand up a server that implements the specification and every user of every compliant product would immediately be able to take advantage of that. Now, having said that, I think that the protocol can be quite minimal in its design... but there's no need to design it unless we decide we need to have one, so I'll stop there! Regards, --David On 12/13/2012 9:04 AM, Stephen Hanna wrote: > > Chandra wrote: > > > it is desirable in my view to use references so data collector could > pull the content or data collector knows how to get the content based > on the instructions given by the requestor. > > Chandra, > > As I recall, you are the founder of a company (SecPod) that develops > and provides SCAP content on a subscription basis. SecPod was the > first company to create an SCAP Content Repository and to provide a > standard protocol for accessing it. With all due respect and > appreciation for your work (which I think is of the highest quality), > you may have a personal bias toward standardizing a content repository > protocol. Could you offer a compelling technical rationale for doing > so at this time and as a part of UC1? I'd also like to hear from other > SACM participants on this topic. > > Thanks, > > > Steve > > *From:*Chandrashekhar B [mailto:bchandra@secpod.com] > *Sent:* Thursday, December 13, 2012 9:47 AM > *To:* Stephen Hanna; 'Adam Montville' > *Cc:* sacm@ietf.org > *Subject:* RE: [sacm] SACM UC1 And Related Requirements > > >Chandra wrote: > > >> Data collector needs to have the assessment content for performing > the task > > >> the data requestor asked for. This is 4.1.4 from use case document. > > >Perhaps. If the communications between the data requestor and the data > collector included all the necessary >content, this interaction could > take place without needing a separate content repository. Maybe this > would not >be efficient so it's desirable to use references to content > instead of sending the content itself. Is this true? > > That could be another scenario. In which case, data requestor is > behaving like a content repository with a push model. But, it is > desirable in my view to use references so data collector could pull > the content or data collector knows how to get the content based on > the instructions given by the requestor. > > Chandra. > > *From:*Chandrashekhar B [mailto:bchandra@secpod.com] > *Sent:* Thursday, December 13, 2012 1:32 AM > *To:* Stephen Hanna; 'Adam Montville' > *Cc:* sacm@ietf.org > *Subject:* RE: [sacm] SACM UC1 And Related Requirements > > >Adam Montville wrote: > > >> > 2) Do we really need protocols for accessing a content > repository for UC1? Why? > > >> > > >> It seems to me that these are likely to be "light," but are needed. > How do we expect to get information from one place to the next without > at least defining what an access API might look like, what supported > transport protocols exist for the given technology, and what > identifiers to use, etc. > > > I understand why we want to have a standard protocol for conveying > the target system identification and data collection instructions to > the data collector and for getting back the state values. I just don't > understand why we need a standard protocol for talking to a content > repository for UC1. > > >Maybe we have a different idea of how UC1 works. I think UC1 is saying that > one party (call it the "data requestor") asks a second party (call it > the "data collector") to gather data ("state values") relating to the > security of a third party (the "target system"). So we need standard > protocols and data formats that the data requestor can use when > talking to the data collector. To give a concrete example, the data > requestor might say "Send me the list of software installed on device > 374629" and the data collector might respond with a list of installed > software. > > >With that model, the question of how the data collector gathers data about > the target system (through the NEA protocols or via WMI or SSH) is not > our problem. And how the data requestor determines the list of state > values to request is not our problem. Arguably, even the nature of the > policies used by the data requestor to determine whether it likes the > state values may not be our problem. But I certainly don't see any > need for content repository protocols in this model. > > >Do you have a different model for UC1? I realize that this is straying > into architecture somewhat but I don't think we'll be able to come up > with a set of requirements unless we have a common model for what the > actors in the system are and how they interact to achieve the goals of > the use case. > > Data collector needs to have the assessment content for performing the > task the data requestor asked for. This is 4.1.4 from use case document. > > Chandra. > > *From:*Adam Montville [mailto:amontville@tripwire.com] > *Sent:* Wednesday, December 12, 2012 12:09 PM > *To:* Stephen Hanna > *Cc:* sacm@ietf.org > *Subject:* Re: SACM UC1 And Related Requirements > > On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: > > Adam, > > Thanks for putting together this initial list of requirements. This is > a good start. I do have some questions: > > 1)Is BYOD in scope? I think it should be. It's a fact of life in > enterprise networks today. If people agree, I would recommend changing > your second requirement to add this at the end: "or brought and owned > by end users". > > This change seems reasonable to me. We can ensure we address the > issue, and then leave it to organizations using implementations of the > standards/guidelines we produce as to how they want to apply the > technology. > > 2)Do we really need protocols for accessing a content repository for > UC1? Why? > > It seems to me that these are likely to be "light," but are needed. > How do we expect to get information from one place to the next > without at least defining what an access API might look like, what > supported transport protocols exist for the given technology, and what > identifiers to use, etc. > > I don't think we need anything heavy, just enough to say: If you want > to get assessment content, find the content repository, and form your > request like this, and you'll get your response. > > Notionally, it's easy for me to see a service-oriented interface using > a REST API to get this type of thing done, but that's getting the cart > before the horse, I think. > > I'm glad to see us moving forward with this and other issues. > > Take care, > > Steve > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org ]*On Behalf > Of*Adam Montville > *Sent:*Tuesday, December 11, 2012 1:39 PM > *To:*sacm@ietf.org > *Subject:*[sacm] SACM UC1 And Related Requirements > > All: > > After trolling through some of the SACM mailing list, and reviewing > SACM BoF minutes from IETF 85 and the current Use Case draft looking > for requirements, and here's what I've pulled together so far: > > * UC1 must provide coverage for enterprises of various sizes and > include support for assets delivered by third-parties > * Asset representation/identification should support those delivered > by a given Service Provider (SP) > * Supporting data formats and/or protocols should support assessment > of SP-provided assets > * Must provide a method of defining a target system (asset > identification; asset classification) > * Must provide a method of selecting acceptable state policy (test > expression) > * Must provide a method of retrieving data collection instructions > (activity class: configuration, patch, vulnerability, inventory; > object representation; state representation) > * Must provide a method of expressing state collection values > (collection language: technical, interrogative; object representation) > * Must provide a method of comparing actual to expected state values > (test evaluation; test expression) > * Must provide a protocol for connecting to a content repository > containing SACM content > * Must provide a protocol for querying SACM content held in a > content repository > * Must provide a protocol of retrieving SACM content from a content > repository > * Must provide a protocol for curating SACM content in a content > repository > > In addition to the above, I would like to suggest that we > take/_certain requirements_/from CSIS 20 Critical Security Controls > [1] under the following controls: > > * Critical Control 1: Inventory of Authorized and Unauthorized Devices > * Critical Control 2: Inventory of Authorized and Unauthorized Software > * Critical Control 3: Secure Configuration for Hardware and Software > on Mobile Devices, Laptops, Workstations, and Servers > * Critical Control 4: Continuous Vulnerability Assessment and > Remediation > * Critical Control 5: Malware Defenses > * Critical Control 10: Secure Configurations for Network Devices > such as Firewalls, Routers, and Switches > > I have/_not yet_/parsed through each of the Critical Controls, but > anticipate more detailed requirements to come out of them. I > emphasize that we will not be seeking to meet every requirement > expressed by a given Critical Control. For example, we may not be in > a position to express "authorizations" for software installed on an > operating system in a given context. But, Critical Control 2 does > require accurate and meaningful asset identification (as does Critical > Control 1, for that matter), which is something with which we should > be concerned. > > I have this Friday (12/14) dedicated to fleshing out these > requirements. If you have contributions to make, I respectfully > request that you do so before then. > > Regards, > > Adam > > [1] http://www.sans.org/critical-security-controls/ > > * > Adam W. Montville *| Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > / > /*TRIPWIRE*|CONFIDENCE:*SECURED* > www.tripwire.com > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --------------070005030901010801030104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have an opinion, but no commercial OVAL repository I'm selling...

I do think it makes sense to introduce a standard protocol (or set of protocols) for interacting with a repository.  We are already covering the format of the content, which is the biggest problem, so why not go the last mile and also specify a delivery protocol?

If we do specify a protocol, it will be very easy for anyone to stand up their own content server that will plug-in with existing tools, to the immediate benefit of the entire community.  For instance, if Juniper decided in the future to author its own SCAP content for its products, it could stand up a server that implements the specification and every user of every compliant product would immediately be able to take advantage of that.

Now, having said that, I think that the protocol can be quite minimal in its design... but there's no need to design it unless we decide we need to have one, so I'll stop there!

Regards,
--David

On 12/13/2012 9:04 AM, Stephen Hanna wrote:

Chandra wrote:

> it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor.

 

Chandra,

 

As I recall, you are the founder of a company (SecPod) that develops and provides SCAP content on a subscription basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol for accessing it. With all due respect and appreciation for your work (which I think is of the highest quality), you may have a personal bias toward standardizing a content repository protocol. Could you offer a compelling technical rationale for doing so at this time and as a part of UC1? I’d also like to hear from other SACM participants on this topic.

 

Thanks,


Steve

 

From: Chandrashekhar B [mailto:bchandra@secpod.com]
Sent: Thursday, December 13, 2012 9:47 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Chandra wrote:

>> Data collector needs to have the assessment content for performing the task

>> the data requestor asked for. This is 4.1.4 from use case document.

 

>Perhaps. If the communications between the data requestor and the data collector included all the necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficient so it’s desirable to use references to content instead of sending the content itself. Is this true?

 

That could be another scenario. In which case, data requestor is behaving like a content repository with a push model. But, it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor.

 

Chandra.

 

 

From: Chandrashekhar B [mailto:bchandra@secpod.com]
Sent: Thursday, December 13, 2012 1:32 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Adam Montville wrote:

>> > 2)      Do we really need protocols for accessing a content repository for UC1? Why?

>> 

>> It seems to me that these are likely to be "light," but are needed.  How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc.

 

> I understand why we want to have a standard protocol for conveying the target system identification and data collection instructions to the data collector and for getting back the state values. I just don’t understand why we need a standard protocol for talking to a content repository for UC1.

 

>Maybe we have a different idea of how UC1 works. I think UC1 is saying that one party (call it the “data requestor”) asks a second party (call it the “data collector”) to gather data (“state values”) relating to the security of a third party (the “target system”). So we need standard protocols and data formats that the data requestor can use when talking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on device 374629” and the data collector might respond with a list of installed software.

 

>With that model, the question of how the data collector gathers data about the target system (through the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not our problem. Arguably, even the nature of the policies used by the data requestor to determine whether it likes the state values may not be our problem. But I certainly don’t see any need for content repository protocols in this model.

 

>Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don’t think we’ll be able to come up with a set of requirements unless we have a common model for what the actors in the system are and how they interact to achieve the goals of the use case.

 

Data collector needs to have the assessment content for performing the task the data requestor asked for. This is 4.1.4 from use case document.

 

Chandra.

 

 

From: Adam Montville [mailto:amontville@tripwire.com]
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: sacm@ietf.org
Subject: Re: SACM UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> wrote:

 

Adam,

 

Thanks for putting together this initial list of requirements. This is a good start. I do have some questions:

 

1)      Is BYOD in scope? I think it should be. It’s a fact of life in enterprise networks today. If people agree, I would recommend changing your second requirement to add this at the end: “or brought and owned by end users”.

 

This change seems reasonable to me.  We can ensure we address the issue, and then leave it to organizations using implementations of the standards/guidelines we produce as to how they want to apply the technology.

 

 

2)      Do we really need protocols for accessing a content repository for UC1? Why?

 

It seems to me that these are likely to be "light," but are needed.  How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to say: If you want to get assessment content, find the content repository, and form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-oriented interface using a REST API to get this type of thing done, but that's getting the cart before the horse, I think.

 

 

I’m glad to see us moving forward with this and other issues.

 

Take care,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SACM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far: 

 

  • UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties
  • Asset representation/identification should support those delivered by a given Service Provider (SP)
  • Supporting data formats and/or protocols should support assessment of SP-provided assets
  • Must provide a method of defining a target system (asset identification; asset classification)
  • Must provide a method of selecting acceptable state policy (test expression)
  • Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation)
  • Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation)
  • Must provide a method of comparing actual to expected state values (test evaluation; test expression)
  • Must provide a protocol for connecting to a content repository containing SACM content
  • Must provide a protocol for querying SACM content held in a content repository
  • Must provide a protocol of retrieving SACM content from a content repository
  • Must provide a protocol for curating SACM content in a content repository

 

In addition to the above, I would like to suggest that we take certain requirements from CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Remediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detailed requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control.  For example, we may not be in a position to express "authorizations" for software installed on an operating system in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned.

 

I have this Friday (12/14) dedicated to fleshing out these requirements.  If you have contributions to make, I respectfully request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com

 

 

 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12



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

--------------070005030901010801030104-- From solin@farnamhallventures.com Thu Dec 13 08:07:37 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9F921F8BD2 for ; Thu, 13 Dec 2012 08:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJSLBy5XVoAo for ; Thu, 13 Dec 2012 08:07:31 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1455D21F8B6B for ; Thu, 13 Dec 2012 08:07:31 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2324985oag.31 for ; Thu, 13 Dec 2012 08:07:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type:x-gm-message-state; bh=7qW1pVZts9ERDN7+yz/hQO421/BIFfNIrxTI0SjEuVk=; b=QrtS9gZzu7BMhW58iuZ+En/4AxP39QCwgehwFrscOGkA8KlJ8WFBnAzxd3i+1QlylQ /MlS4NUk0KAjmXDBC60TuTgvty3lO892ddR41yTnZWzMwRdJXBzZt+48fat2cQL54/xL rpMlWbDjfZdmIZM++oESithWj3Xl9+xB6zvQe7Bg3KTMz4LDTAxDmduh3OQuBLP4KIZ9 GBJ1ajq/f3WdKp6x59LCTd3OPOtoTFczg760kuaBT6zZNC89xzVghlmD6cpgY6qjCsnu EDXKAkdTaGGzOhn7rijXfDAcilIs9XG1rR6dPPggQSq48FV9+j7HA/PQcPBAESSg5iV+ UzYA== Received: by 10.60.154.169 with SMTP id vp9mr1843470oeb.109.1355414850270; Thu, 13 Dec 2012 08:07:30 -0800 (PST) Received: from [192.168.0.113] (99-57-135-11.lightspeed.austtx.sbcglobal.net. [99.57.135.11]) by mx.google.com with ESMTPS id yn8sm1202615obb.12.2012.12.13.08.07.28 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:07:29 -0800 (PST) Sender: David Solin Message-ID: <50C9FD3E.3060304@joval.org> Date: Thu, 13 Dec 2012 10:07:26 -0600 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Waltermire, David A." References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060809030001020202040509" X-Gm-Message-State: ALoCoQl3/bv1111Rd6z3zmYb+Qwlzr0k8xeowgvV58zqNyvLmHe6cRnuxikfzWBZ0sXlRX4WOjrZ Cc: Stephen Hanna , "bchandra@secpod.com" , "sacm@ietf.org" , Adam Montville Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:07:37 -0000 This is a multi-part message in MIME format. --------------060809030001020202040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 Adam -- and I think utility does qualify as a "technical" reason. I would add that (as someone without a repository to sell) I do think it makes sense to introduce a standard protocol (or set of protocols) for interacting with a repository. We are already covering the format of the content, which is the biggest problem, so why not go the last mile and also specify a delivery protocol? If we do specify a protocol, it will be very easy for anyone to stand up their own content server that will plug-in with existing tools, to the immediate benefit of the entire community. For instance, if Juniper decided in the future to author its own SCAP content for its products, it could stand up a server that implements the specification and every user of every compliant product would immediately be able to take advantage of that. On the other hand, "content management" (which Dave brought up), is perhaps a different matter from mere transmission, and could substantially increase the complexity of the protocol we need to specify. All we need, in my opinion, is a way to enumerate and download content from a repository, and probably also, to identify a delta that is needed to update from a previous repository snapshot. Regards, --David On 12/13/2012 9:58 AM, Waltermire, David A. wrote: > > Adam, > > +1. Your point is well stated IMHO. > > Content management has been a significant barrier to useful adoption > of security automation approaches to date. I reviewed the TCG's IF-M > for SCAP during the development of that document and raised these > issues. At the time we decided to keep content management out-of-band > for the document, relying on proprietary methods to insure the > delivery of content. My concerns were around the potential mismatch > between what content is expected to be on the access requestor and > what content is being used to satisfy a health check. If the content > is handled out-of-band, this may be a more regular occurrence and is > certainly a challenge to contend with in multi-vendor interoperability > scenarios. This all works better if the content is managed properly > and if both the access requestor and the policy evaluator have the > same content. Of course there are still some circumstances where it > is impossible to deploy the latest content (e.g. long-term > disconnection from the network), but this is a secondary issue. > > The best way to ensure that content is managed properly is to keep it > in scope as part of the orchestration process for collection. To > support this, we probably need to support a mechanism that allows > content to be pulled by reference. We may also need a method to > "package" the content along with instructions that are exchanged over > the control channel allowing a "push". The latter would enable > tightly managed clients. > > Sincerely, > > Dave > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Adam Montville > *Sent:* Thursday, December 13, 2012 10:33 AM > *To:* Stephen Hanna > *Cc:* bchandra@secpod.com; sacm@ietf.org > *Subject:* Re: [sacm] SACM UC1 And Related Requirements > > On Dec 13, 2012, at 7:04 AM, Stephen Hanna > wrote: > > > > Chandra wrote: > > > it is desirable in my view to use references so data collector could > pull the content or data collector knows how to get the content based > on the instructions given by the requestor. > > Chandra, > > As I recall, you are the founder of a company (SecPod) that develops > and provides SCAP content on a subscription basis. SecPod was the > first company to create an SCAP Content Repository and to provide a > standard protocol for accessing it. With all due respect and > appreciation for your work (which I think is of the highest quality), > you may have a personal bias toward standardizing a content repository > protocol. Could you offer a compelling technical rationale for doing > so at this time and as a part of UC1? I'd also like to hear from other > SACM participants on this topic. > > Let's look at this from the end goal. Imagine that we're "done" with > Use Case 1. A set of standards that allow us to: 1) define the target > system, 2) select acceptable state policy, 3) retrieve data collection > instructions, 4) collect actual state values, and 5) compare actual > state values. > > There are two ways we can deal with the selection and retrieval of > policy and collection instructions (steps 2 and 3, respectively). We > can leave it up to specific implementations to figure it out on their > own and end up with proprietary solutions, or, as presented in > Atlanta, we can specify the method(s) by which implementations can > connect to and interact with the storage of that information. > > I ask myself this question: How useful is it to define a > content-driven assessment method without providing the accompanying > method of transmitting that content? To me, it's not a benefit to the > community at all without addressing the basic requirement of getting > the content from one place to another. The goal here is automation, > and without that, we're keeping one of the worst manual processes around. > > While this may not be a "technical" reason for keeping the content > repository in scope, I really can't imagine a truly useful set of > standards without one. If there's one thing I think we've learned in > the security automation community so far, it's that you can spec > schema all day long, but if you don't have a good way to interoperate > in an automated way with other tools and/or external entities, you're > treading water. > > So, I'm a strong advocate for explicitly recognizing the need for > defining the method by which implementations should expect to connect > to a content repository, and, therefore, for keeping that squarely in > scope for UC1. > > > > Thanks, > > > Steve > > *From:*Chandrashekhar B [mailto:bchandra@secpod.com ] > *Sent:*Thursday, December 13, 2012 9:47 AM > *To:*Stephen Hanna; 'Adam Montville' > *Cc:*sacm@ietf.org > *Subject:*RE: [sacm] SACM UC1 And Related Requirements > > >Chandra wrote: > > >> Data collector needs to have the assessment content for performing > the task > > >> the data requestor asked for. This is 4.1.4 from use case document. > > >Perhaps. If the communications between the data requestor and the data > collector included all the necessary >content, this interaction could > take place without needing a separate content repository. Maybe this > would not >be efficient so it's desirable to use references to content > instead of sending the content itself. Is this true? > > That could be another scenario. In which case, data requestor is > behaving like a content repository with a push model. But, it is > desirable in my view to use references so data collector could pull > the content or data collector knows how to get the content based on > the instructions given by the requestor. > > Chandra. > > *From:*Chandrashekhar B [mailto:bchandra@secpod.com] > *Sent:*Thursday, December 13, 2012 1:32 AM > *To:*Stephen Hanna; 'Adam Montville' > *Cc:*sacm@ietf.org > *Subject:*RE: [sacm] SACM UC1 And Related Requirements > > >Adam Montville wrote: > > >> > 2) Do we really need protocols for accessing a content > repository for UC1? Why? > > >> > > >> It seems to me that these are likely to be "light," but are needed. > How do we expect to get information from one place to the next without > at least defining what an access API might look like, what supported > transport protocols exist for the given technology, and what > identifiers to use, etc. > > > I understand why we want to have a standard protocol for conveying > the target system identification and data collection instructions to > the data collector and for getting back the state values. I just don't > understand why we need a standard protocol for talking to a content > repository for UC1. > > >Maybe we have a different idea of how UC1 works. I think UC1 is saying that > one party (call it the "data requestor") asks a second party (call it > the "data collector") to gather data ("state values") relating to the > security of a third party (the "target system"). So we need standard > protocols and data formats that the data requestor can use when > talking to the data collector. To give a concrete example, the data > requestor might say "Send me the list of software installed on device > 374629" and the data collector might respond with a list of installed > software. > > >With that model, the question of how the data collector gathers data about > the target system (through the NEA protocols or via WMI or SSH) is not > our problem. And how the data requestor determines the list of state > values to request is not our problem. Arguably, even the nature of the > policies used by the data requestor to determine whether it likes the > state values may not be our problem. But I certainly don't see any > need for content repository protocols in this model. > > >Do you have a different model for UC1? I realize that this is straying > into architecture somewhat but I don't think we'll be able to come up > with a set of requirements unless we have a common model for what the > actors in the system are and how they interact to achieve the goals of > the use case. > > Data collector needs to have the assessment content for performing the > task the data requestor asked for. This is 4.1.4 from use case document. > > Chandra. > > *From:*Adam Montville [mailto:amontville@tripwire.com] > *Sent:*Wednesday, December 12, 2012 12:09 PM > *To:*Stephen Hanna > *Cc:*sacm@ietf.org > *Subject:*Re: SACM UC1 And Related Requirements > > On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: > > Adam, > > Thanks for putting together this initial list of requirements. This is > a good start. I do have some questions: > > 1)Is BYOD in scope? I think it should be. It's a fact of life in > enterprise networks today. If people agree, I would recommend changing > your second requirement to add this at the end: "or brought and owned > by end users". > > This change seems reasonable to me. We can ensure we address the > issue, and then leave it to organizations using implementations of the > standards/guidelines we produce as to how they want to apply the > technology. > > 2)Do we really need protocols for accessing a content repository for > UC1? Why? > > It seems to me that these are likely to be "light," but are needed. > How do we expect to get information from one place to the next > without at least defining what an access API might look like, what > supported transport protocols exist for the given technology, and what > identifiers to use, etc. > > I don't think we need anything heavy, just enough to say: If you want > to get assessment content, find the content repository, and form your > request like this, and you'll get your response. > > Notionally, it's easy for me to see a service-oriented interface using > a REST API to get this type of thing done, but that's getting the cart > before the horse, I think. > > I'm glad to see us moving forward with this and other issues. > > Take care, > > Steve > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org > ]*On Behalf Of*Adam Montville > *Sent:*Tuesday, December 11, 2012 1:39 PM > *To:*sacm@ietf.org > *Subject:*[sacm] SACM UC1 And Related Requirements > > All: > > After trolling through some of the SACM mailing list, and reviewing > SACM BoF minutes from IETF 85 and the current Use Case draft looking > for requirements, and here's what I've pulled together so far: > > * UC1 must provide coverage for enterprises of various sizes and > include support for assets delivered by third-parties > * Asset representation/identification should support those delivered > by a given Service Provider (SP) > * Supporting data formats and/or protocols should support assessment > of SP-provided assets > * Must provide a method of defining a target system (asset > identification; asset classification) > * Must provide a method of selecting acceptable state policy (test > expression) > * Must provide a method of retrieving data collection instructions > (activity class: configuration, patch, vulnerability, inventory; > object representation; state representation) > * Must provide a method of expressing state collection values > (collection language: technical, interrogative; object representation) > * Must provide a method of comparing actual to expected state values > (test evaluation; test expression) > * Must provide a protocol for connecting to a content repository > containing SACM content > * Must provide a protocol for querying SACM content held in a > content repository > * Must provide a protocol of retrieving SACM content from a content > repository > * Must provide a protocol for curating SACM content in a content > repository > > In addition to the above, I would like to suggest that we > take/_certain requirements_/from CSIS 20 Critical Security Controls > [1] under the following controls: > > * Critical Control 1: Inventory of Authorized and Unauthorized Devices > * Critical Control 2: Inventory of Authorized and Unauthorized Software > * Critical Control 3: Secure Configuration for Hardware and Software > on Mobile Devices, Laptops, Workstations, and Servers > * Critical Control 4: Continuous Vulnerability Assessment and > Remediation > * Critical Control 5: Malware Defenses > * Critical Control 10: Secure Configurations for Network Devices > such as Firewalls, Routers, and Switches > > I have/_not yet_/parsed through each of the Critical Controls, but > anticipate more detailed requirements to come out of them. I > emphasize that we will not be seeking to meet every requirement > expressed by a given Critical Control. For example, we may not be in > a position to express "authorizations" for software installed on an > operating system in a given context. But, Critical Control 2 does > require accurate and meaningful asset identification (as does Critical > Control 1, for that matter), which is something with which we should > be concerned. > > I have this Friday (12/14) dedicated to fleshing out these > requirements. If you have contributions to make, I respectfully > request that you do so before then. > > Regards, > > Adam > > [1] http://www.sans.org/critical-security-controls/ > > * > Adam W. Montville *| Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > / > /*TRIPWIRE*|CONFIDENCE:*SECURED* > www.tripwire.com > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG -www.avg.com > Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG -www.avg.com > Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > * > Adam W. Montville *| Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > / > /*TRIPWIRE*|CONFIDENCE:*SECURED* > www.tripwire.com > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm -- jOVAL.org: SCAP Simplified. Learn More | Features | Download --------------060809030001020202040509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 Adam -- and I think utility does qualify as a "technical" reason.

I would add that (as someone without a repository to sell) I do think it makes sense to introduce a standard protocol (or set of protocols) for interacting with a repository.  We are already covering the format of the content, which is the biggest problem, so why not go the last mile and also specify a delivery protocol?

If we do specify a protocol, it will be very easy for anyone to stand up their own content server that will plug-in with existing tools, to the immediate benefit of the entire community.  For instance, if Juniper decided in the future to author its own SCAP content for its products, it could stand up a server that implements the specification and every user of every compliant product would immediately be able to take advantage of that.

On the other hand, "content management" (which Dave brought up), is perhaps a different matter from mere transmission, and could substantially increase the complexity of the protocol we need to specify.  All we need, in my opinion, is a way to enumerate and download content from a repository, and probably also, to identify a delta that is needed to update from a previous repository snapshot.

Regards,
--David

On 12/13/2012 9:58 AM, Waltermire, David A. wrote:

Adam,

 

+1.  Your point is well stated IMHO.

 

Content management has been a significant barrier to useful adoption of security automation approaches to date.  I reviewed the TCG’s IF-M for SCAP during the development of that document and raised these issues.  At the time we decided to keep content management out-of-band for the document, relying on proprietary methods to insure the delivery of content.  My concerns were around the potential mismatch between what content is expected to be on the access requestor and what content is being used to satisfy a health check. If the content is handled out-of-band, this may be a more regular occurrence and is certainly a challenge to contend with in multi-vendor interoperability scenarios.  This all works better if the content is managed properly and if both the access requestor and the policy evaluator have the same content.  Of course there are still some circumstances where it is impossible to deploy the latest content (e.g. long-term disconnection from the network), but this is a secondary issue.

 

The best way to ensure that content is managed properly is to keep it in scope as part of the orchestration process for collection.  To support this, we probably need to support a mechanism that allows content to be pulled by reference.  We may also need a method to “package” the content along with instructions that are exchanged over the control channel allowing a “push”.  The latter would enable tightly managed clients.

 

Sincerely,

Dave

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Thursday, December 13, 2012 10:33 AM
To: Stephen Hanna
Cc: bchandra@secpod.com; sacm@ietf.org
Subject: Re: [sacm] SACM UC1 And Related Requirements

 

 

On Dec 13, 2012, at 7:04 AM, Stephen Hanna <shanna@juniper.net> wrote:



Chandra wrote:

> it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor.

 

Chandra,

 

As I recall, you are the founder of a company (SecPod) that develops and provides SCAP content on a subscription basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol for accessing it. With all due respect and appreciation for your work (which I think is of the highest quality), you may have a personal bias toward standardizing a content repository protocol. Could you offer a compelling technical rationale for doing so at this time and as a part of UC1? I’d also like to hear from other SACM participants on this topic.

 

 

Let's look at this from the end goal.  Imagine that we're "done" with Use Case 1.  A set of standards that allow us to: 1) define the target system, 2) select acceptable state policy, 3) retrieve data collection instructions, 4) collect actual state values, and 5) compare actual state values.  

 

There are two ways we can deal with the selection and retrieval of policy and collection instructions (steps 2 and 3, respectively).  We can leave it up to specific implementations to figure it out on their own and end up with proprietary solutions, or, as presented in Atlanta, we can specify the method(s) by which implementations can connect to and interact with the storage of that information.

 

I ask myself this question: How useful is it to define a content-driven assessment method without providing the accompanying method of transmitting that content?  To me, it's not a benefit to the community at all without addressing the basic requirement of getting the content from one place to another.  The goal here is automation, and without that, we're keeping one of the worst manual processes around.

 

While this may not be a "technical" reason for keeping the content repository in scope, I really can't imagine a truly useful set of standards without one.  If there's one thing I think we've learned in the security automation community so far, it's that you can spec schema all day long, but if you don't have a good way to interoperate in an automated way with other tools and/or external entities, you're treading water.

 

So, I'm a strong advocate for explicitly recognizing the need for defining the method by which implementations should expect to connect to a content repository, and, therefore, for keeping that squarely in scope for UC1.

 

 

 



 

Thanks,


Steve

 

From: Chandrashekhar B [mailto:bchandra@secpod.com] 
Sent: Thursday, December 13, 2012 9:47 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Chandra wrote:

>> Data collector needs to have the assessment content for performing the task

>> the data requestor asked for. This is 4.1.4 from use case document.

 

>Perhaps. If the communications between the data requestor and the data collector included all the necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficient so it’s desirable to use references to content instead of sending the content itself. Is this true?

 

That could be another scenario. In which case, data requestor is behaving like a content repository with a push model. But, it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor.

 

Chandra.

 

 

From: Chandrashekhar B [mailto:bchandra@secpod.com] 
Sent: Thursday, December 13, 2012 1:32 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Adam Montville wrote:

>> > 2)      Do we really need protocols for accessing a content repository for UC1? Why?

>> 

>> It seems to me that these are likely to be "light," but are needed.  How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc.

 

> I understand why we want to have a standard protocol for conveying the target system identification and data collection instructions to the data collector and for getting back the state values. I just don’t understand why we need a standard protocol for talking to a content repository for UC1.

 

>Maybe we have a different idea of how UC1 works. I think UC1 is saying that one party (call it the “data requestor”) asks a second party (call it the “data collector”) to gather data (“state values”) relating to the security of a third party (the “target system”). So we need standard protocols and data formats that the data requestor can use when talking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on device 374629” and the data collector might respond with a list of installed software.

 

>With that model, the question of how the data collector gathers data about the target system (through the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not our problem. Arguably, even the nature of the policies used by the data requestor to determine whether it likes the state values may not be our problem. But I certainly don’t see any need for content repository protocols in this model.

 

>Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don’t think we’ll be able to come up with a set of requirements unless we have a common model for what the actors in the system are and how they interact to achieve the goals of the use case.

 

Data collector needs to have the assessment content for performing the task the data requestor asked for. This is 4.1.4 from use case document.

 

Chandra.

 

 

From: Adam Montville [mailto:amontville@tripwire.com] 
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: sacm@ietf.org
Subject: Re: SACM UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> wrote:

 

Adam,

 

Thanks for putting together this initial list of requirements. This is a good start. I do have some questions:

 

1)      Is BYOD in scope? I think it should be. It’s a fact of life in enterprise networks today. If people agree, I would recommend changing your second requirement to add this at the end: “or brought and owned by end users”.

 

This change seems reasonable to me.  We can ensure we address the issue, and then leave it to organizations using implementations of the standards/guidelines we produce as to how they want to apply the technology.

 

 

2)      Do we really need protocols for accessing a content repository for UC1? Why?

 

It seems to me that these are likely to be "light," but are needed.  How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to say: If you want to get assessment content, find the content repository, and form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-oriented interface using a REST API to get this type of thing done, but that's getting the cart before the horse, I think.

 

 

I’m glad to see us moving forward with this and other issues.

 

Take care,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SACM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far: 

 

  • UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties
  • Asset representation/identification should support those delivered by a given Service Provider (SP)
  • Supporting data formats and/or protocols should support assessment of SP-provided assets
  • Must provide a method of defining a target system (asset identification; asset classification)
  • Must provide a method of selecting acceptable state policy (test expression)
  • Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation)
  • Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation)
  • Must provide a method of comparing actual to expected state values (test evaluation; test expression)
  • Must provide a protocol for connecting to a content repository containing SACM content
  • Must provide a protocol for querying SACM content held in a content repository
  • Must provide a protocol of retrieving SACM content from a content repository
  • Must provide a protocol for curating SACM content in a content repository

 

In addition to the above, I would like to suggest that we take certain requirements from CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Remediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detailed requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control.  For example, we may not be in a position to express "authorizations" for software installed on an operating system in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned.

 

I have this Friday (12/14) dedicated to fleshing out these requirements.  If you have contributions to make, I respectfully request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com

 

 

 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12

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

 


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com

 

 

 



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


--

jOVAL.org: SCAP Simplified.
Learn More | Features | Download

--------------060809030001020202040509-- From solin@farnamhallventures.com Thu Dec 13 08:13:35 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F9621F8994 for ; Thu, 13 Dec 2012 08:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5y8xNXlZb0O for ; Thu, 13 Dec 2012 08:13:34 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8512121F898D for ; Thu, 13 Dec 2012 08:13:34 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2334961oag.31 for ; Thu, 13 Dec 2012 08:13:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=tGTL4SboEphqnllP/hfV4zRydqfbGLAtMlgJKMOVM34=; b=jXGnDVJrAmlb0LBo2/aKhIl9k8hqc0tHlAAgWcU/wkIMgHPNXNvcSfoVB+nE6CXcJB DONKqJv3jqNzkb2lJn92x5XyHBmcO+qk8VeI42qiYuHxk2sts1Z/3EO5tjc1kbZJZXke uyi9DzyNLBFZ3UjgKDfoUAcI+Njiqa/kWru4T0c+vtiLUZrgNEwHM/iZrO7JhleOwraW qZv+bpeQuF51tCgDK4T4sfHsyrVE01QcvG3jIGBrneX2ShPbT5HdpkJmw4VUstjxwvyz beFDXR0Xl/WuhxYmv8UMeObLzDoWx7Il9SECJGFutIhLWALppmg3zTtFTwck/jRUsZ5h 0wGQ== Received: by 10.60.168.198 with SMTP id zy6mr1960576oeb.89.1355415213904; Thu, 13 Dec 2012 08:13:33 -0800 (PST) Received: from [192.168.0.113] (99-57-135-11.lightspeed.austtx.sbcglobal.net. [99.57.135.11]) by mx.google.com with ESMTPS id zz6sm1252691oeb.1.2012.12.13.08.13.32 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:13:33 -0800 (PST) Sender: David Solin Message-ID: <50C9FEAA.4040405@joval.org> Date: Thu, 13 Dec 2012 10:13:30 -0600 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <20121212193535.490E01A3F4@ld9781.wdf.sap.corp> In-Reply-To: <20121212193535.490E01A3F4@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------040307060700080701080305" X-Gm-Message-State: ALoCoQnMtAorbP/JTaXNtl+hPZb1UYmkRr4efrb7xRsnCzxVr2Ehzmt/bpy3P8L3plvR/yEriudl Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:13:35 -0000 This is a multi-part message in MIME format. --------------040307060700080701080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, You are saying that, if I have infected your computer with malware, it is illegal in Germany for you to do anything that would make you aware of that fact. Is that correct? Regards, --David Solin On 12/12/2012 1:35 PM, Martin Rex wrote: > Martin Rex wrote: >> David Oliva wrote: >>> The monitoring which SACM performs is not about people's behavior. >>> The monitoring which SACM performs is of security mechanisms which >>> are of interest to organizations. >>> When organizations are expected by law to protect private information, >>> SACM monitors the security controls designed to protect privacy laws. >> Romascanu, Dan (Dan) wrote: >>> I was also confused by the usage of the term ?monitoring? by the time >>> I was introducing myself in SACM. David Oliva ?s observation is correct, >>> ?monitoring? as used in SACM is about auditing the security controls >>> and mechanisms (although using ?auditing? instead could create other >>> confusions) >> Unless infected by malware and being turned into a remoted-controlled bot, >> a typical computing system will change its state based on user input, >> i.e. user behaviour. So if you track the state changes of a computer >> that is used by a user, you're actually tracking the behaviour of the >> user! >> >> Monitoring the which processes are started and stopped, monitoring which >> network ports they open and close and when and how much data they transfer, >> monitoring which files are written and read, even the DHCP address assigned >> to the machine is subject to the protections of the basic right of >> informational self-determination. >> >> >> what are the security mechanisms / security controls that you want to monitor? > actually, any processes that perform network communication, the ports they > open, the data they transfer (including what they read from disk and write to disk or network shares) and the DHCP address assigned to the machine > is subject to the protection of the constitutional telecommunication > secrecy, and monitoring that information without an applicable statue law > established by the parliamenarian legislator is not just illegal in Germany, > it is a crime punishable with up to 5 years in prison. > > > -Martin > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm -- jOVAL.org: SCAP Simplified. Learn More | Features | Download --------------040307060700080701080305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Martin,

You are saying that, if I have infected your computer with malware, it is illegal in Germany for you to do anything that would make you aware of that fact.  Is that correct?

Regards,
--David Solin

On 12/12/2012 1:35 PM, Martin Rex wrote:
Martin Rex wrote:

David Oliva wrote:

The monitoring which SACM performs is not about people's behavior.
The monitoring which SACM performs is of security mechanisms which
are of interest to organizations.
When organizations are expected by law to protect private information,
SACM monitors the security controls designed to protect privacy laws.

Romascanu, Dan (Dan) wrote:

I was also confused by the usage of the term ?monitoring? by the time
I was introducing myself in SACM. David Oliva ?s observation is correct,
?monitoring? as used in SACM is about auditing the security controls
and mechanisms (although using ?auditing? instead could create other
confusions)

Unless infected by malware and being turned into a remoted-controlled bot,
a typical computing system will change its state based on user input,
i.e. user behaviour.  So if you track the state changes of a computer
that is used by a user, you're actually tracking the behaviour of the
user!

Monitoring the which processes are started and stopped, monitoring which
network ports they open and close and when and how much data they transfer,
monitoring which files are written and read, even the DHCP address assigned
to the machine is subject to the protections of the basic right of
informational self-determination.


what are the security mechanisms / security controls that you want to monitor?

actually, any processes that perform network communication, the ports they
open, the data they transfer (including what they read from disk and write to disk or network shares) and the DHCP address assigned to the machine
is subject to the protection of the constitutional telecommunication
secrecy, and monitoring that information without an applicable statue law
established by the parliamenarian legislator is not just illegal in Germany,
it is a crime punishable with up to 5 years in prison.


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


--

jOVAL.org: SCAP Simplified.
Learn More | Features | Download

--------------040307060700080701080305-- From ggolovinsky@qualys.com Thu Dec 13 08:14:23 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CBC21F898D for ; Thu, 13 Dec 2012 08:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYYa2qwOCzpu for ; Thu, 13 Dec 2012 08:14:23 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97221F8645 for ; Thu, 13 Dec 2012 08:14:23 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so1771161qca.31 for ; Thu, 13 Dec 2012 08:14:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Cufe1iwE+YD0VM6WPdIU5fgSpPcnK9s30oJ7VNwGSFQ=; b=S4x2lPaFtmNK/4aZqbKnD4Nf6XUJaITrm3ObCs9WaUa+JHu0+U6+bz8G4drXh4/7jS EzjewmKrM6gzgInhJLOrW9kUYJjcg7YLt8/LBqU/xRZ1StMaaUmFG8pqCRnke0mmc4IL g2TV0+yatfGrHFEVlvxQxZHN1Ac8CV33tmRqDANB/cA9dgYD7/8vnhU/6gJmbDrw26If DFP0GjtXOyTQtQNZf3wAAx5EgFLuFGPCd3STEhIDMEZ++aEmzAAQHUSLzXkjLoNgVcek iz3ftzBBX/3VdOqQmAjl03Po7YeHmgCX0VmGvdytCRXGDiIX0YRMoUcRR/2bmCO/xoKW Q5Fg== Received: by 10.224.110.2 with SMTP id l2mr1194330qap.35.1355415262615; Thu, 13 Dec 2012 08:14:22 -0800 (PST) From: Gene Golovinsky References: <20121212193007.95B781A3F4@ld9781.wdf.sap.corp> <20121212193535.490E01A3F4@ld9781.wdf.sap.corp> In-Reply-To: <20121212193535.490E01A3F4@ld9781.wdf.sap.corp> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDa7c+DYb9aGB8ycdTv7ioHSmcvAJn8u/IA Date: Thu, 13 Dec 2012 08:14:22 -0800 Message-ID: <4fbc459b39af67338487e3822b59e9ce@mail.gmail.com> To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn+wIcmXtuMowKIR7fJr5y0qo5by6iGqKTKZ5w9OTJiKPYzL0MvJAIa0FWAHMCbDCwYMti/ Cc: david.oliva@verizon.net, "Romascanu, Dan \(Dan\)" , sacm@ietf.org Subject: Re: [sacm] Mis-understanding of the term monitoring X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:14:24 -0000 Martin. This feels a bit too broad. We can take it to the extreme and declare all the system monitoring tool that exist and used for a few decades now completely illegal. Not to mention, that well-being of us as law abiding citizens very much depends on various intrusion detection systems, anti-virus software, malware detection software ability to see activities that can be deemed as dangerous and block, disrupt, report. I think SACM is making a good and noble attempt to make these various already existing and well accepted software to work better together and improve when possible. If what you telling is really the case, then it should mean that German banks and manufacturers run NO security software or if they do, then they all breaking the law... --Gene -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Martin Rex Sent: Wednesday, December 12, 2012 11:36 AM To: mrex@sap.com Cc: david.oliva@verizon.net; Romascanu, Dan (Dan); sacm@ietf.org Subject: Re: [sacm] Mis-understanding of the term monitoring Martin Rex wrote: > > David Oliva wrote: > > > > The monitoring which SACM performs is not about people's behavior. > > The monitoring which SACM performs is of security mechanisms which > > are of interest to organizations. > > When organizations are expected by law to protect private > > information, SACM monitors the security controls designed to protect privacy laws. > > Romascanu, Dan (Dan) wrote: > > > > I was also confused by the usage of the term ?monitoring? by the > > time I was introducing myself in SACM. David Oliva ?s observation is > > correct, ?monitoring? as used in SACM is about auditing the security > > controls and mechanisms (although using ?auditing? instead could > > create other > > confusions) > > Unless infected by malware and being turned into a remoted-controlled > bot, a typical computing system will change its state based on user > input, i.e. user behaviour. So if you track the state changes of a > computer that is used by a user, you're actually tracking the > behaviour of the user! > > Monitoring the which processes are started and stopped, monitoring > which network ports they open and close and when and how much data > they transfer, monitoring which files are written and read, even the > DHCP address assigned to the machine is subject to the protections of > the basic right of informational self-determination. > > > what are the security mechanisms / security controls that you want to monitor? actually, any processes that perform network communication, the ports they open, the data they transfer (including what they read from disk and write to disk or network shares) and the DHCP address assigned to the machine is subject to the protection of the constitutional telecommunication secrecy, and monitoring that information without an applicable statue law established by the parliamenarian legislator is not just illegal in Germany, it is a crime punishable with up to 5 years in prison. -Martin _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From Kent_Landfield@mcafee.com Thu Dec 13 08:17:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4B21F8A15 for ; Thu, 13 Dec 2012 08:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI7Rdh1Vy28P for ; Thu, 13 Dec 2012 08:17:14 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5621F8A0A for ; Thu, 13 Dec 2012 08:17:13 -0800 (PST) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 6a42_288e_7b031345_d60f_4d39_9031_d58aaba8ec50; Thu, 13 Dec 2012 10:17:06 -0600 Received: from MIVEXAPP2N1.corp.nai.org (10.48.48.71) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 13 Dec 2012 11:14:55 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.159]) by MIVEXAPP2N1.corp.nai.org ([169.254.2.103]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 11:14:55 -0500 From: To: , , Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIABM/mAgAB6igCAAA+tAIAABQmA//+vYIA= Date: Thu, 13 Dec 2012 16:14:54 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF09E6A2@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [172.25.124.141] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF09E6A2MIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:17:16 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF09E6A2MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Steve, This is a core problem we as a community need to address very soon. With S= CAP and other content standardization efforts we are creating a situation w= here the content (checks, benchmarks, enumerated support information) is co= nsumable by may different applications in multiple security technologies. E= fforts like SCAP are validating if products and services process content th= e same way, producing the same results from the same content. This is of b= enefit to the industry as it is creating a level playing field and a benefi= t to the customers of these products. We are breaking down the proprietary= walls that lock in information and economically tie an organization's hand= to a specific vendor's product because the organization has invested so mu= ch to get a security technology fielded. We are seeing that play out today= . While this is a great goal, there are headaches developing we have creat= ed with this approach. That is what we hope to solve with a standardized r= epository interface to distributing standardized content=85 So what it the problem we have/are making for ourselves=85 With that standard content there is always a need to tweak, correct, update= or replace the checks in the content for the local organizational needs. = Sites use that standard content format to implement their own security poli= cy validation content that they wish to comply with and measure against. T= hey want to take advantage of the multiple security related products that u= se the standardized content so they have many different compliant products = supporting various aspects of the security infrastructure. When staff want= s to make a change, they edit the content and then wish to push it out to t= he compliant products for use as their 'authoritative' content for evaluati= on. Today, what we have seen is that each product has it's own means for distri= buting content. Some use FTP, some use Sharepoint, some use web repositori= es, some have manual means and some have proprietary means. Operationally t= his has created a nightmare for the staff. We now require the operations s= taff to go to each product's management facilities, insert the new checks, = content, support information into that specific product's distribution mech= anism and push it out. The larger the network, the bigger the problem. So= what we have seen with SCAP is that while we have standardized content for= mats and consistent processing we are missing a critical piece needed to re= duce the workload and increase the speed with which content updates are dis= tributed. A standard content repository interface to retrieve the content provides a = solution to the problem we are creating. It also allows for additional capa= bilities to be associated, such as integrated content management (creation,= edit, update) which the site could leverage. And I have not even mentioned the need for industry organizations such as C= IS to distribute their benchmarks and checks when changes are made, bugs ar= e fixed, new platforms are supported. I see the local issues as the most c= ritical at this point but there are also additional capabilities needed dow= n the road. There is absolutely a need for this type of content repository / distributi= on. We have no standards around content distribution today and as the compl= iant products / technologies proliferate, the problem will get bigger and n= egatively impact the move towards standards. This is absolutely in scope fo= r this working group. Side note, Chandra has always been a proponent of this long before he set u= p his SCAP content feed service. He is an supporter in this effort and I s= ee nothing biased in anything he has done / stated to date. Thanks. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Thursday, December 13, 2012 9:04 AM To: "bchandra@secpod.com" >, Adam Montville > Cc: "sacm@ietf.org" > Subject: Re: [sacm] SACM UC1 And Related Requirements Chandra wrote: > it is desirable in my view to use references so data collector could pull= the content or data collector knows how to get the content based on the in= structions given by the requestor. Chandra, As I recall, you are the founder of a company (SecPod) that develops and pr= ovides SCAP content on a subscription basis. SecPod was the first company t= o create an SCAP Content Repository and to provide a standard protocol for = accessing it. With all due respect and appreciation for your work (which I = think is of the highest quality), you may have a personal bias toward stand= ardizing a content repository protocol. Could you offer a compelling techni= cal rationale for doing so at this time and as a part of UC1? I=92d also li= ke to hear from other SACM participants on this topic. Thanks, Steve From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 9:47 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Chandra wrote: >> Data collector needs to have the assessment content for performing the t= ask >> the data requestor asked for. This is 4.1.4 from use case document. >Perhaps. If the communications between the data requestor and the data col= lector included all the necessary >content, this interaction could take pla= ce without needing a separate content repository. Maybe this would not >be = efficient so it=92s desirable to use references to content instead of sendi= ng the content itself. Is this true? That could be another scenario. In which case, data requestor is behaving l= ike a content repository with a push model. But, it is desirable in my view= to use references so data collector could pull the content or data collect= or knows how to get the content based on the instructions given by the requ= estor. Chandra. From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository= for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How= do we expect to get information from one place to the next without at leas= t defining what an access API might look like, what supported transport pro= tocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the ta= rget system identification and data collection instructions to the data col= lector and for getting back the state values. I just don=92t understand why= we need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying tha= t one party (call it the =93data requestor=94) asks a second party (call it= the =93data collector=94) to gather data (=93state values=94) relating to = the security of a third party (the =93target system=94). So we need standar= d protocols and data formats that the data requestor can use when talking t= o the data collector. To give a concrete example, the data requestor might = say =93Send me the list of software installed on device 374629=94 and the d= ata collector might respond with a list of installed software. >With that model, the question of how the data collector gathers data about= the target system (through the NEA protocols or via WMI or SSH) is not our= problem. And how the data requestor determines the list of state values to= request is not our problem. Arguably, even the nature of the policies used= by the data requestor to determine whether it likes the state values may n= ot be our problem. But I certainly don=92t see any need for content reposit= ory protocols in this model. >Do you have a different model for UC1? I realize that this is straying int= o architecture somewhat but I don=92t think we=92ll be able to come up with= a set of requirements unless we have a common model for what the actors in= the system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task= the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It=92s a fact of life in en= terprise networks today. If people agree, I would recommend changing your s= econd requirement to add this at the end: =93or brought and owned by end us= ers=94. This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I=92m glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 --_000_3CBA099FBA0AB843895D72474092B8CF09E6A2MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Steve, 

This is a core problem we as a community need to address very soon. &n= bsp;With SCAP and other content standardization efforts we are creating a s= ituation where the content (checks, benchmarks, enumerated support informat= ion) is consumable by may different applications in multiple security technologies. Efforts like SCAP are validating if pro= ducts and services process content the same way, producing the same results= from the same content.  This is of benefit to the industry as it is c= reating a level playing field and a benefit to the customers of these products.  We are breaking down the proprie= tary walls that lock in information and economically tie an organization's = hand to a specific vendor's product because the organization has invested s= o much to get a security technology fielded.  We are seeing that play out today.  While this is a great goal,= there are headaches developing we have created with this approach.  T= hat is what we hope to solve with a standardized repository interface to di= stributing standardized content=85

So what it the problem we have/are making for ourselves=85

With that standard content there is always a need to tweak, correct, u= pdate or replace the checks in the content for the local organizational nee= ds.  Sites use that standard content format to implement their own sec= urity policy validation content that they wish to comply with and measure against.  They want to take adva= ntage of the multiple security related products that use the standardized c= ontent so they have many different compliant products supporting various as= pects of the security infrastructure.  When staff wants to make a change, they edit the content and then wi= sh to push it out to the compliant products for use as their 'authoritative= ' content for evaluation. 

Today, what we have seen is that each product has it's own means for d= istributing content.  Some use FTP, some use Sharepoint, some use web = repositories, some have manual means and some have proprietary means. Opera= tionally this has created a nightmare for the staff.  We now require the operations staff to go to each pro= duct's management facilities, insert the new checks, content, support infor= mation into that specific product's distribution mechanism and push it out.=  The larger the network, the bigger the problem.  So what we have seen with SCAP is that while we have st= andardized content formats and consistent processing we are missing a criti= cal piece needed to reduce the workload and increase the speed with which c= ontent updates are distributed.

A standard content repository interface to retrieve the content provid= es a solution to the problem we are creating. It also allows for additional= capabilities to be associated, such as integrated content management (crea= tion, edit, update) which the site could leverage.  

And I have not even mentioned the need for industry organizations such= as CIS to distribute their benchmarks and checks when changes are made, bu= gs are fixed, new platforms are supported.  I see the local issues as = the most critical at this point but there are also additional capabilities needed down the road.

There is absolutely a need for this type of content repository / distr= ibution. We have no standards around content distribution today and as the = compliant products / technologies proliferate, the problem will get bigger = and negatively impact the move towards standards. This is absolutely in scope for this working group.

Side note, Chandra has always been a proponent of this long before he = set up his SCAP content feed service.  He is an supporter in this effo= rt and I see nothing biased in anything he has done / stated to date.  = ;

Thanks.

Kent Landfield

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

From: Stephen Hanna <shanna@juniper.net>
Date: Thursday, December 13, 2012 9= :04 AM
To: "bchandra@secpod.com" <bchandra@secpod.com>, Adam Montville <amontville@tripwire.com>
Cc: "sacm@ietf.org" <sacm@i= etf.org>
Subject: Re: [sacm] SACM UC1 And Re= lated Requirements

Chandra wrote:

> it is desirable in my view to= use references so data collector could pull the content or data collector = knows how to get the content based on the instructions given by the requestor.

 

Chandra,

 

As I recall, you are the founder o= f a company (SecPod) that develops and provides SCAP content on a subscript= ion basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol fo= r accessing it. With all due respect and appreciation for your work (which = I think is of the highest quality), you may have a personal bias toward sta= ndardizing a content repository protocol. Could you offer a compelling technical rationale for doing so at= this time and as a part of UC1? I=92d also like to hear from other SACM pa= rticipants on this topic.

 

Thanks,


Steve

 

From: Chandrashekhar B [mailto:bchandra@secpod.com]
Sent: Thursday, December 13, 2012 9:47 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Chandra wrote:

>> Data collector needs to h= ave the assessment content for performing the task

>> the data requestor asked = for. This is 4.1.4 from use case document.

 

>Perhaps. If the communications= between the data requestor and the data collector included all the necessa= ry >content, this interaction could take place without needing a separate content repository. Maybe this would not = >be efficient so it=92s desirable to use references to content instead o= f sending the content itself. Is this true?

 

That could be another scenario. In= which case, data requestor is behaving like a content repository with a pu= sh model. But, it is desirable in my view to use references so data collector could pull the content or data co= llector knows how to get the content based on the instructions given by the= requestor.

 

Chandra.

 

 

From: Chandrashekhar B [mailto:bchandra@secpod.com]
Sent: Thursday, December 13, 2012 1:32 AM
To: Stephen Hanna; 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm] SACM UC1 And Related Requirements

 

>Adam Montville wrote:

>> > 2)   =    Do we really need protocols for accessing a content repository= for UC1? Why?

>> 

>> It seems to me that these= are likely to be "light," but are needed.  How do we expect= to get information from one place to the next without at least defining what an access API might look like, what supported transpor= t protocols exist for the given technology, and what identifiers to use, et= c.

 

> I understand why we want to h= ave a standard protocol for conveying the target system identification and = data collection instructions to the data collector and for getting back the state values. I just don=92t understand= why we need a standard protocol for talking to a content repository for UC= 1.

 

>Maybe we have a different idea= of how UC1 works. I think UC1 is saying that one party (call it the =93dat= a requestor=94) asks a second party (call it the =93data collector=94) to gather data (=93state values=94) relating to = the security of a third party (the =93target system=94). So we need standar= d protocols and data formats that the data requestor can use when talking t= o the data collector. To give a concrete example, the data requestor might say =93Send me the list of software installed on = device 374629=94 and the data collector might respond with a list of instal= led software.

 

>With that model, the question = of how the data collector gathers data about the target system (through the= NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state value= s to request is not our problem. Arguably, even the nature of the policies = used by the data requestor to determine whether it likes the state values m= ay not be our problem. But I certainly don=92t see any need for content repository protocols in this model.<= /o:p>

 

>Do you have a different model = for UC1? I realize that this is straying into architecture somewhat but I d= on=92t think we=92ll be able to come up with a set of requirements unless we have a common model for what the actors in= the system are and how they interact to achieve the goals of the use case.=

 

Data collector needs to have the a= ssessment content for performing the task the data requestor asked for. Thi= s is 4.1.4 from use case document.

 

Chandra.<= o:p>

 

 

From: Adam Montville [mailto:amontville@tripwire.com]
Sent: Wednesday, December 12, 2012 12:09 PM
To: Stephen Hanna
Cc: sacm@ietf.org
Subject: Re: SACM UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> wrote:

 

Adam,

 

Thanks for putting together this i= nitial list of requirements. This is a good start. I do have some questions= :

 

1)&n= bsp;     Is BYOD in scope? I think it should be. It=92s a fact of life in enterprise n= etworks today. If people agree, I would recommend changing your second requ= irement to add this at the end: =93or brought and owned by end users=94.

 

This change seems reasonable to me.  We can ens= ure we address the issue, and then leave it to organizations using implemen= tations of the standards/guidelines we produce as to how they want to apply= the technology.

 

 

2)    &= nbsp; Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

 

It seems to me that these are likely to be "lig= ht," but are needed.  How do we expect to get information from on= e place to the next without at least defining what an access API might look= like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to= say: If you want to get assessment content, find the content repository, a= nd form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-orient= ed interface using a REST API to get this type of thing done, but that's ge= tting the cart before the horse, I think.

 

 

I=92m glad to see us moving forwar= d with this and other issues.

 

Take care,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam= Montville
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org
Subject: [sacm] SA= CM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide = coverage for enterprises of various sizes and include support for assets de= livered by third-parties
  • Asset representation/identification should support t= hose delivered by a given Service Provider (SP)
  • Supporting data formats and/o= r protocols should support assessment of SP-provided assets
    • =
  • Must provide a me= thod of defining a target system (asset identification; asset classificatio= n)
  • Must provide a method of selecting acceptable state policy (test expressio= n)
  • Must provide a method of retrieving data collection instructions (activity= class: configuration, patch, vulnerability, inventory; object representati= on; state representation)
  • Must provide a method of expressing state collectio= n values (collection language: technical, interrogative; object representat= ion)
  • Must provide a method of comparing actual to expected state values (test= evaluation; test expression)
  • Must provide a protocol for connecting to a co= ntent repository containing SACM content
  • Must provide a protocol for querying= SACM content held in a content repository
  • Must provide a protocol of retriev= ing SACM content from a content repository
  • Must provide a protocol for curati= ng SACM content in a content repository

 

In addition to the above, I would like to suggest th= at we take certain = requirements from= CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control = 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inven= tory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Confi= guration for Hardware and Software on Mobile Devices, Laptops, Workstations= , and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Rem= ediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Confi= gurations for Network Devices such as Firewalls, Routers, and Switches=

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detaile= d requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given= Critical Control.  For example, we may not be in a position to expres= s "authorizations" for software installed on an operating system = in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Con= trol 1, for that matter), which is something with which we should be concer= ned.

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Compliance Architect=

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE=  | CONFIDENCE:&nbs= p;SECURED
www.tripwire.com=

 

 

 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12

 --_000_3CBA099FBA0AB843895D72474092B8CF09E6A2MIVEXAMER1N1corpn_-- From gunnar.engelbach@threatguard.com Thu Dec 13 08:21:21 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9AC21F8AA6 for ; Thu, 13 Dec 2012 08:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVdqW2QVm2V7 for ; Thu, 13 Dec 2012 08:21:20 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7A72A21F8AA0 for ; Thu, 13 Dec 2012 08:21:20 -0800 (PST) Received: (qmail 14051 invoked from network); 13 Dec 2012 08:25:32 -0800 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Dec 2012 08:25:32 -0800 Message-ID: <50CA0093.5000509@ThreatGuard.com> Date: Thu, 13 Dec 2012 11:21:39 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 CC: "sacm@ietf.org" References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:21:22 -0000 I have to agree with the arguments that Adam and Dave give, but I'm anxious to see what this boils down to as requirements are defined. Right now it looks like there needs to be a great deal of interaction between the content repository, the policy evaluator, and the access requestor. Noting the amount of data in current repositories and how quickly it grows, this approach is infeasible when talking about a single large repository such as Mitre/Secpod. Even moving the repository within the silo of each enterprise can end up generating huge amounts of network traffic if it isn't done very carefully, especially when "continuous" is thrown into the mix. Networks aren't built for the purpose of assessing networks, after all. And some networks are completely disconnected from Internet access. It sounds to me like there needs to be two types of repositories. One that is as local to the point of usage as possible and another that is a root or definitive data source, such as is provided by vendors. For the latter it's very much in line to seek input from commercial operators like Chandra to be sure that the needs of access control are addressed in a way that is sufficient and practical. --gun On 12/13/2012 10:58 AM, Waltermire, David A. wrote: > Adam, > > +1. Your point is well stated IMHO. > > Content management has been a significant barrier to useful adoption of > security automation approaches to date. I reviewed the TCG’s IF-M for > SCAP during the development of that document and raised these issues. > At the time we decided to keep content management out-of-band for the > document, relying on proprietary methods to insure the delivery of > content. My concerns were around the potential mismatch between what > content is expected to be on the access requestor and what content is > being used to satisfy a health check. If the content is handled > out-of-band, this may be a more regular occurrence and is certainly a > challenge to contend with in multi-vendor interoperability scenarios. > This all works better if the content is managed properly and if both the > access requestor and the policy evaluator have the same content. Of > course there are still some circumstances where it is impossible to > deploy the latest content (e.g. long-term disconnection from the > network), but this is a secondary issue. > > The best way to ensure that content is managed properly is to keep it in > scope as part of the orchestration process for collection. To support > this, we probably need to support a mechanism that allows content to be > pulled by reference. We may also need a method to “package” the content > along with instructions that are exchanged over the control channel > allowing a “push”. The latter would enable tightly managed clients. > > Sincerely, > > Dave > > *From:*sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] *On Behalf > Of *Adam Montville > *Sent:* Thursday, December 13, 2012 10:33 AM > *To:* Stephen Hanna > *Cc:* bchandra@secpod.com; sacm@ietf.org > *Subject:* Re: [sacm] SACM UC1 And Related Requirements > > On Dec 13, 2012, at 7:04 AM, Stephen Hanna > wrote: > > > > Chandra wrote: > >> it is desirable in my view to use references so data collector could pull the content or data collector knows how to get the content based on the instructions given by the requestor. > > Chandra, > > As I recall, you are the founder of a company (SecPod) that develops and > provides SCAP content on a subscription basis. SecPod was the first > company to create an SCAP Content Repository and to provide a standard > protocol for accessing it. With all due respect and appreciation for > your work (which I think is of the highest quality), you may have a > personal bias toward standardizing a content repository protocol. Could > you offer a compelling technical rationale for doing so at this time and > as a part of UC1? I’d also like to hear from other SACM participants on > this topic. > > Let's look at this from the end goal. Imagine that we're "done" with > Use Case 1. A set of standards that allow us to: 1) define the target > system, 2) select acceptable state policy, 3) retrieve data collection > instructions, 4) collect actual state values, and 5) compare actual > state values. > > There are two ways we can deal with the selection and retrieval of > policy and collection instructions (steps 2 and 3, respectively). We > can leave it up to specific implementations to figure it out on their > own and end up with proprietary solutions, or, as presented in Atlanta, > we can specify the method(s) by which implementations can connect to and > interact with the storage of that information. > > I ask myself this question: How useful is it to define a content-driven > assessment method without providing the accompanying method of > transmitting that content? To me, it's not a benefit to the community > at all without addressing the basic requirement of getting the content > from one place to another. The goal here is automation, and without > that, we're keeping one of the worst manual processes around. > > While this may not be a "technical" reason for keeping the content > repository in scope, I really can't imagine a truly useful set of > standards without one. If there's one thing I think we've learned in > the security automation community so far, it's that you can spec schema > all day long, but if you don't have a good way to interoperate in an > automated way with other tools and/or external entities, you're treading > water. > > So, I'm a strong advocate for explicitly recognizing the need for > defining the method by which implementations should expect to connect to > a content repository, and, therefore, for keeping that squarely in scope > for UC1. > > > > Thanks, > > > Steve > > *From:*Chandrashekhar B [mailto:bchandra@secpod.com ] > *Sent:*Thursday, December 13, 2012 9:47 AM > *To:*Stephen Hanna; 'Adam Montville' > *Cc:*sacm@ietf.org > *Subject:*RE: [sacm] SACM UC1 And Related Requirements > >>Chandra wrote: > >>> Data collector needs to have the assessment content for performing the task > >>> the data requestor asked for. This is 4.1.4 from use case document. > >>Perhaps. If the communications between the data requestor and the data collector included all the necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficient so it’s desirable to use references to content instead of sending the content itself. Is this true? > > That could be another scenario. In which case, data requestor is > behaving like a content repository with a push model. But, it is > desirable in my view to use references so data collector could pull the > content or data collector knows how to get the content based on the > instructions given by the requestor. > > Chandra. > > *From:*Chandrashekhar B [mailto:bchandra@secpod.com] > *Sent:*Thursday, December 13, 2012 1:32 AM > *To:*Stephen Hanna; 'Adam Montville' > *Cc:*sacm@ietf.org > *Subject:*RE: [sacm] SACM UC1 And Related Requirements > >>Adam Montville wrote: > >>> > 2) Do we really need protocols for accessing a content repository for UC1? Why? > >>> > >>> It seems to me that these are likely to be "light," but are needed. How do we expect to get information from one place to the next without at least defining what an access API might look like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. > >> I understand why we want to have a standard protocol for conveying the target system identification and data collection instructions to the data collector and for getting back the state values. I just don’t understand why we need a standard protocol for talking to a content repository for UC1. > >>Maybe we have a different idea of how UC1 works. I think UC1 is saying that one party (call it the “data requestor”) asks a second party (call it the “data collector”) to gather data (“state values”) relating to the security of a third party (the “target system”). So we need standard protocols and data formats that the data requestor can use when talking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on device 374629” and the data collector might respond with a list of installed software. > >>With that model, the question of how the data collector gathers data about the target system (through the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request is not our problem. Arguably, even the nature of the policies used by the data requestor to determine whether it likes the state values may not be our problem. But I certainly don’t see any need for content repository protocols in this model. > >>Do you have a different model for UC1? I realize that this is straying into architecture somewhat but I don’t think we’ll be able to come up with a set of requirements unless we have a common model for what the actors in the system are and how they interact to achieve the goals of the use case. > > Data collector needs to have the assessment content for performing the > task the data requestor asked for. This is 4.1.4 from use case document. > > Chandra. > > *From:*Adam Montville [mailto:amontville@tripwire.com] > *Sent:*Wednesday, December 12, 2012 12:09 PM > *To:*Stephen Hanna > *Cc:*sacm@ietf.org > *Subject:*Re: SACM UC1 And Related Requirements > > On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: > > Adam, > > Thanks for putting together this initial list of requirements. This is a > good start. I do have some questions: > > 1)Is BYOD in scope? I think it should be. It’s a fact of life in > enterprise networks today. If people agree, I would recommend changing > your second requirement to add this at the end: “or brought and owned by > end users”. > > This change seems reasonable to me. We can ensure we address the issue, > and then leave it to organizations using implementations of the > standards/guidelines we produce as to how they want to apply the technology. > > 2)Do we really need protocols for accessing a content repository for > UC1? Why? > > It seems to me that these are likely to be "light," but are needed. How > do we expect to get information from one place to the next without at > least defining what an access API might look like, what supported > transport protocols exist for the given technology, and what identifiers > to use, etc. > > I don't think we need anything heavy, just enough to say: If you want to > get assessment content, find the content repository, and form your > request like this, and you'll get your response. > > Notionally, it's easy for me to see a service-oriented interface using a > REST API to get this type of thing done, but that's getting the cart > before the horse, I think. > > I’m glad to see us moving forward with this and other issues. > > Take care, > > Steve > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org > ]*On Behalf Of*Adam Montville > *Sent:*Tuesday, December 11, 2012 1:39 PM > *To:*sacm@ietf.org > *Subject:*[sacm] SACM UC1 And Related Requirements > > All: > > After trolling through some of the SACM mailing list, and reviewing SACM > BoF minutes from IETF 85 and the current Use Case draft looking for > requirements, and here's what I've pulled together so far: > > * UC1 must provide coverage for enterprises of various sizes and > include support for assets delivered by third-parties > * Asset representation/identification should support those delivered > by a given Service Provider (SP) > * Supporting data formats and/or protocols should support assessment > of SP-provided assets > * Must provide a method of defining a target system (asset > identification; asset classification) > * Must provide a method of selecting acceptable state policy (test > expression) > * Must provide a method of retrieving data collection instructions > (activity class: configuration, patch, vulnerability, inventory; > object representation; state representation) > * Must provide a method of expressing state collection values > (collection language: technical, interrogative; object representation) > * Must provide a method of comparing actual to expected state values > (test evaluation; test expression) > * Must provide a protocol for connecting to a content repository > containing SACM content > * Must provide a protocol for querying SACM content held in a content > repository > * Must provide a protocol of retrieving SACM content from a content > repository > * Must provide a protocol for curating SACM content in a content > repository > > In addition to the above, I would like to suggest that we take/_certain > requirements_/from CSIS 20 Critical Security Controls [1] under the > following controls: > > * Critical Control 1: Inventory of Authorized and Unauthorized Devices > * Critical Control 2: Inventory of Authorized and Unauthorized Software > * Critical Control 3: Secure Configuration for Hardware and Software > on Mobile Devices, Laptops, Workstations, and Servers > * Critical Control 4: Continuous Vulnerability Assessment and Remediation > * Critical Control 5: Malware Defenses > * Critical Control 10: Secure Configurations for Network Devices such > as Firewalls, Routers, and Switches > > I have/_not yet_/parsed through each of the Critical Controls, but > anticipate more detailed requirements to come out of them. I emphasize > that we will not be seeking to meet every requirement expressed by a > given Critical Control. For example, we may not be in a position to > express "authorizations" for software installed on an operating system > in a given context. But, Critical Control 2 does require accurate and > meaningful asset identification (as does Critical Control 1, for that > matter), which is something with which we should be concerned. > > I have this Friday (12/14) dedicated to fleshing out these requirements. > If you have contributions to make, I respectfully request that you do > so before then. > > Regards, > > Adam > > [1] http://www.sans.org/critical-security-controls/ > > * > Adam W. Montville *| Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > / > /*TRIPWIRE*|CONFIDENCE:*SECURED* > www.tripwire.com > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG -www.avg.com > Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG -www.avg.com > Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > * > Adam W. Montville *| Security and Compliance Architect > > Direct: 503 276-7661 > Mobile: 360 471-7815 > > / > /*TRIPWIRE*|CONFIDENCE:*SECURED* > www.tripwire.com > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From solin@farnamhallventures.com Thu Dec 13 08:23:41 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EBE21F8AA5 for ; Thu, 13 Dec 2012 08:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDuW3xiOiJtv for ; Thu, 13 Dec 2012 08:23:38 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A39BF21F8AA2 for ; Thu, 13 Dec 2012 08:23:38 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2350529oag.31 for ; Thu, 13 Dec 2012 08:23:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=X7wj0/k+MgmcwnraNwZiVDUdXS/1Z3j5cFVGlV4w678=; b=TnEqim7cL4M/keMMgDNefIMr4uq6rifmpR9P81iPyfwvYjh4K115cLsrqnVUsaDWeQ iNhhXxM7UZBsdoL99SW9XYoYLLYx6aWdHK1oMD0MD9J+Zhb1ecurOSoupZr+/07GET+z SU+DEL/jyCk7VglmocYW5oe/0P29jEoy3nXxjxJ9HGcdiK8/rZd/GYYCEkeh/OWgBVeK 5IbCxBcpJb2XKqUJlCmHmPAmMoh4cOnRifMHaJISOXlvY9hZensEpQB9swqL7aoDnxVS PLb2V0i0GIVgTEXJymwyFkXDoWaa+MUA6G7cNDcnf78ek/ynQNgls0b6HePzTVyr15sp Odpg== Received: by 10.182.141.70 with SMTP id rm6mr1978584obb.59.1355415818065; Thu, 13 Dec 2012 08:23:38 -0800 (PST) Received: from [192.168.0.113] (99-57-135-11.lightspeed.austtx.sbcglobal.net. [99.57.135.11]) by mx.google.com with ESMTPS id hz6sm1229407obb.1.2012.12.13.08.23.36 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:23:37 -0800 (PST) Sender: David Solin Message-ID: <50CA0106.7000005@joval.org> Date: Thu, 13 Dec 2012 10:23:34 -0600 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> In-Reply-To: <50CA0093.5000509@ThreatGuard.com> Content-Type: multipart/alternative; boundary="------------040401040403050909050300" X-Gm-Message-State: ALoCoQn8goLLGJkwR8Abv7PjlE3Ig/x0uUqojysHhF8mxFA28DCpjjblGCJf6ZaclvEEx6qek/lt Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:23:41 -0000 This is a multi-part message in MIME format. --------------040401040403050909050300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 This is a well-stated point, and hopefully gets us all on the same page. It's communication with the latter type of repository that I believe we're all interested in standardizing. On 12/13/2012 10:21 AM, Gunnar Engelbach wrote: > > It sounds to me like there needs to be two types of repositories. One > that is as local to the point of usage as possible and another that is > a root or definitive data source, such as is provided by vendors. > > For the latter it's very much in line to seek input from commercial > operators like Chandra to be sure that the needs of access control are > addressed in a way that is sufficient and practical. -- jOVAL.org: SCAP Simplified. Learn More | Features | Download --------------040401040403050909050300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1

This is a well-stated point, and hopefully gets us all on the same page.  It's communication with the latter type of repository that I believe we're all interested in standardizing.

On 12/13/2012 10:21 AM, Gunnar Engelbach wrote:

It sounds to me like there needs to be two types of repositories.  One that is as local to the point of usage as possible and another that is a root or definitive data source, such as is provided by vendors.

For the latter it's very much in line to seek input from commercial operators like Chandra to be sure that the needs of access control are addressed in a way that is sufficient and practical.


--

jOVAL.org: SCAP Simplified.
Learn More | Features | Download

--------------040401040403050909050300-- From shanna@juniper.net Thu Dec 13 08:42:03 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371CE21F8B3D for ; Thu, 13 Dec 2012 08:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-tUe8Iil7Tf for ; Thu, 13 Dec 2012 08:41:53 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 486DF21F8B5F for ; Thu, 13 Dec 2012 08:41:53 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUMoFUekGRtlZxM+faIXcASrsR8f8T29y@postini.com; Thu, 13 Dec 2012 08:41:53 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 08:40:13 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 08:40:12 -0800 Received: from CH1EHSOBE007.bigfish.com (216.32.181.182) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 08:47:46 -0800 Received: from mail79-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 16:40:12 +0000 Received: from mail79-ch1 (localhost [127.0.0.1]) by mail79-ch1-R.bigfish.com (Postfix) with ESMTP id 2A54060402 for ; Thu, 13 Dec 2012 16:40:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -40 X-BigFish: PS-40(zzbb2dI98dI9371Id6eah9f17Rc85fh168aJ1102I148cI1432I4015I11fbIzz1de0h1202h1e76h1d1ah1d2ahzz8275ch18c673h17326ah18602eh8275bh8275dh1033IL1954cbhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail79-ch1 (localhost.localdomain [127.0.0.1]) by mail79-ch1 (MessageSwitch) id 1355416715313_7800; Thu, 13 Dec 2012 16:38:34 +0000 (UTC) Received: from CH1EHSMHS043.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail79-ch1.bigfish.com (Postfix) with ESMTP id 0B8C5E050D; Thu, 13 Dec 2012 16:38:32 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 16:36:26 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.140]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0245.002; Thu, 13 Dec 2012 16:36:25 +0000 From: Stephen Hanna To: "Waltermire, David A." , Adam Montville Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIAA4CiAgABN58CAADxPAIAAAbxwgAALKYCAAAb2AIAAAqgw Date: Thu, 13 Dec 2012 16:36:25 +0000 Message-ID: References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.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] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E068E5169SN2PRD0510MB372_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NIST.GOV$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TRIPWIRE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%SECPOD.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "bchandra@secpod.com" , "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:42:03 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E068E5169SN2PRD0510MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm glad to see such a clear consensus on this topic and such an active dis= cussion of it on the list. David, Adam, and others have presented clear arguments (both technical and = operational) for including a protocol for accessing a content repository in= our work at this time. Certainly, I don't want us to create an incomplete = solution that only works if additional proprietary protocols are used. And = I can see that it's much more efficient to send references to content and h= ave a separate protocol for fetching the actual content, given a reference. David Solin raises a good question: do we need to specify a protocol for cu= rating the content repository or is it enough to just have a protocol for r= etrieving content? Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Thursday, December 13, 2012 10:58 AM To: Adam Montville; Stephen Hanna Cc: bchandra@secpod.com; sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements Adam, +1. Your point is well stated IMHO. Content management has been a significant barrier to useful adoption of sec= urity automation approaches to date. I reviewed the TCG's IF-M for SCAP du= ring the development of that document and raised these issues. At the time= we decided to keep content management out-of-band for the document, relyin= g on proprietary methods to insure the delivery of content. My concerns we= re around the potential mismatch between what content is expected to be on = the access requestor and what content is being used to satisfy a health che= ck. If the content is handled out-of-band, this may be a more regular occur= rence and is certainly a challenge to contend with in multi-vendor interope= rability scenarios. This all works better if the content is managed proper= ly and if both the access requestor and the policy evaluator have the same = content. Of course there are still some circumstances where it is impossib= le to deploy the latest content (e.g. long-term disconnection from the netw= ork), but this is a secondary issue. The best way to ensure that content is managed properly is to keep it in sc= ope as part of the orchestration process for collection. To support this, = we probably need to support a mechanism that allows content to be pulled by= reference. We may also need a method to "package" the content along with = instructions that are exchanged over the control channel allowing a "push".= The latter would enable tightly managed clients. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Thursday, December 13, 2012 10:33 AM To: Stephen Hanna Cc: bchandra@secpod.com; sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements On Dec 13, 2012, at 7:04 AM, Stephen Hanna > wrote: Chandra wrote: > it is desirable in my view to use references so data collector could pull= the content or data collector knows how to get the content based on the in= structions given by the requestor. Chandra, As I recall, you are the founder of a company (SecPod) that develops and pr= ovides SCAP content on a subscription basis. SecPod was the first company t= o create an SCAP Content Repository and to provide a standard protocol for = accessing it. With all due respect and appreciation for your work (which I = think is of the highest quality), you may have a personal bias toward stand= ardizing a content repository protocol. Could you offer a compelling techni= cal rationale for doing so at this time and as a part of UC1? I'd also like= to hear from other SACM participants on this topic. Let's look at this from the end goal. Imagine that we're "done" with Use C= ase 1. A set of standards that allow us to: 1) define the target system, 2= ) select acceptable state policy, 3) retrieve data collection instructions,= 4) collect actual state values, and 5) compare actual state values. There are two ways we can deal with the selection and retrieval of policy a= nd collection instructions (steps 2 and 3, respectively). We can leave it = up to specific implementations to figure it out on their own and end up wit= h proprietary solutions, or, as presented in Atlanta, we can specify the me= thod(s) by which implementations can connect to and interact with the stora= ge of that information. I ask myself this question: How useful is it to define a content-driven ass= essment method without providing the accompanying method of transmitting th= at content? To me, it's not a benefit to the community at all without addr= essing the basic requirement of getting the content from one place to anoth= er. The goal here is automation, and without that, we're keeping one of th= e worst manual processes around. While this may not be a "technical" reason for keeping the content reposito= ry in scope, I really can't imagine a truly useful set of standards without= one. If there's one thing I think we've learned in the security automatio= n community so far, it's that you can spec schema all day long, but if you = don't have a good way to interoperate in an automated way with other tools = and/or external entities, you're treading water. So, I'm a strong advocate for explicitly recognizing the need for defining = the method by which implementations should expect to connect to a content r= epository, and, therefore, for keeping that squarely in scope for UC1. Thanks, Steve From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 9:47 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Chandra wrote: >> Data collector needs to have the assessment content for performing the t= ask >> the data requestor asked for. This is 4.1.4 from use case document. >Perhaps. If the communications between the data requestor and the data col= lector included all the necessary >content, this interaction could take pla= ce without needing a separate content repository. Maybe this would not >be = efficient so it's desirable to use references to content instead of sending= the content itself. Is this true? That could be another scenario. In which case, data requestor is behaving l= ike a content repository with a push model. But, it is desirable in my view= to use references so data collector could pull the content or data collect= or knows how to get the content based on the instructions given by the requ= estor. Chandra. From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository= for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How= do we expect to get information from one place to the next without at leas= t defining what an access API might look like, what supported transport pro= tocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the ta= rget system identification and data collection instructions to the data col= lector and for getting back the state values. I just don't understand why w= e need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying tha= t one party (call it the "data requestor") asks a second party (call it the= "data collector") to gather data ("state values") relating to the security= of a third party (the "target system"). So we need standard protocols and = data formats that the data requestor can use when talking to the data colle= ctor. To give a concrete example, the data requestor might say "Send me the= list of software installed on device 374629" and the data collector might = respond with a list of installed software. >With that model, the question of how the data collector gathers data about= the target system (through the NEA protocols or via WMI or SSH) is not our= problem. And how the data requestor determines the list of state values to= request is not our problem. Arguably, even the nature of the policies used= by the data requestor to determine whether it likes the state values may n= ot be our problem. But I certainly don't see any need for content repositor= y protocols in this model. >Do you have a different model for UC1? I realize that this is straying int= o architecture somewhat but I don't think we'll be able to come up with a s= et of requirements unless we have a common model for what the actors in the= system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task= the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It's a fact of life in ente= rprise networks today. If people agree, I would recommend changing your sec= ond requirement to add this at the end: "or brought and owned by end users"= . This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I'm glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_F1DFC16DCAA7D3468651A5A776D5796E068E5169SN2PRD0510MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m glad to see suc= h a clear consensus on this topic and such an active discussion of it on th= e list.

 <= /p>

David, Adam, and others h= ave presented clear arguments (both technical and operational) for includin= g a protocol for accessing a content repository in our work at this time. Certainly, I don’t want us to create an incomplete sol= ution that only works if additional proprietary protocols are used. And I c= an see that it’s much more efficient to send references to content an= d have a separate protocol for fetching the actual content, given a reference.

 <= /p>

David Solin raises a good= question: do we need to specify a protocol for curating the content reposi= tory or is it enough to just have a protocol for retrieving content?

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Thursday, December 13, 2012 10:58 AM
To: Adam Montville; Stephen Hanna
Cc: bchandra@secpod.com; sacm@ietf.org
Subject: Re: [sacm] SACM UC1 And Related Requirements

 

Adam,

 <= /p>

+1.  Your point = is well stated IMHO.

 <= /p>

Content management has be= en a significant barrier to useful adoption of security automation approach= es to date.  I reviewed the TCG’s IF-M for SCAP during the development of that document and raised these issues.  At the time we= decided to keep content management out-of-band for the document, relying o= n proprietary methods to insure the delivery of content.  My concerns = were around the potential mismatch between what content is expected to be on the access requestor and what content is= being used to satisfy a health check. If the content is handled out-of-ban= d, this may be a more regular occurrence and is certainly a challenge to co= ntend with in multi-vendor interoperability scenarios.  This all works better if the content is managed properly = and if both the access requestor and the policy evaluator have the same con= tent.  Of course there are still some circumstances where it is imposs= ible to deploy the latest content (e.g. long-term disconnection from the network), but this is a secondary issue.=

 <= /p>

The best way to ensure th= at content is managed properly is to keep it in scope as part of the orches= tration process for collection.  To support this, we probably need to support a mechanism that allows content to be pulled by reference.=   We may also need a method to “package” the content along= with instructions that are exchanged over the control channel allowing a &= #8220;push”.  The latter would enable tightly managed clients.

 <= /p>

Sincerely,

Dave

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Thursday, December 13, 2012 10:33 AM
To: Stephen Hanna
Cc: bchandra@secpod.com; = sacm@ietf.org
Subject: Re: [sacm] SACM UC1 And Related Requirements

 

 

On Dec 13, 2012, at 7:04 AM, Stephen Hanna <shanna@juniper.net> wrote:

 

Chandra wrote:

> it is desirable in m= y view to use references so data collector could pull the content or data c= ollector knows how to get the content based on the instructions given by the requestor.

 <= /p>

Chandra,

 <= /p>

As I recall, you are the = founder of a company (SecPod) that develops and provides SCAP content on a = subscription basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol for accessin= g it. With all due respect and appreciation for your work (which I think is= of the highest quality), you may have a personal bias toward standardizing= a content repository protocol. Could you offer a compelling technical rationale for doing so at this time= and as a part of UC1? I’d also like to hear from other SACM particip= ants on this topic.

 

 

Let's look at this from the end goal.  Imagine = that we're "done" with Use Case 1.  A set of standards that = allow us to: 1) define the target system, 2) select acceptable state policy= , 3) retrieve data collection instructions, 4) collect actual state values, and 5) compare actual state values.  =

 

There are two ways we can deal with the selection an= d retrieval of policy and collection instructions (steps 2 and 3, respectiv= ely).  We can leave it up to specific implementations to figure it out= on their own and end up with proprietary solutions, or, as presented in Atlanta, we can specify the method(s) by wh= ich implementations can connect to and interact with the storage of that in= formation.

 

I ask myself this question: How useful is it to defi= ne a content-driven assessment method without providing the accompanying me= thod of transmitting that content?  To me, it's not a benefit to the c= ommunity at all without addressing the basic requirement of getting the content from one place to another.  = The goal here is automation, and without that, we're keeping one of the wor= st manual processes around.

 

While this may not be a "technical" reason= for keeping the content repository in scope, I really can't imagine a trul= y useful set of standards without one.  If there's one thing I think w= e've learned in the security automation community so far, it's that you can spec schema all day long, but if you don't have = a good way to interoperate in an automated way with other tools and/or exte= rnal entities, you're treading water.

 

So, I'm a strong advocate for explicitly recognizing= the need for defining the method by which implementations should expect to= connect to a content repository, and, therefore, for keeping that squarely= in scope for UC1.

 

 

 

 

 <= /p>

Thanks,=


Steve

 <= /p>

From: Chandrashekhar B [mailto:bchandra@secpod.com] 
Sent: Thursday, De= cember 13, 2012 9:47 AM
To: Stephen Hanna;= 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm= ] SACM UC1 And Related Requirements

 

>Chandra wrote:=

>> Data collector n= eeds to have the assessment content for performing the task

>> the data request= or asked for. This is 4.1.4 from use case document.

 <= /p>

>Perhaps. If the commu= nications between the data requestor and the data collector included all th= e necessary >content, this interaction could take place without needing a separate content repository. Maybe this would not >be efficie= nt so it’s desirable to use references to content instead of sending = the content itself. Is this true?

 <= /p>

That could be another sce= nario. In which case, data requestor is behaving like a content repository = with a push model. But, it is desirable in my view to use references so data collector could pull the content or data collector know= s how to get the content based on the instructions given by the requestor.<= /span>

 <= /p>

Chandra.

 <= /p>

 <= /p>

From: Chandrashekhar B [mai= lto:bchandra@secpod.com]&n= bsp;
Sent: Thursday, De= cember 13, 2012 1:32 AM
To: Stephen Hanna;= 'Adam Montville'
Cc: sacm@ietf.org Subject: RE: [sacm= ] SACM UC1 And Related Requirements

 

>Adam Montville wrote:=

>> > 2) &nb= sp;    Do we really need protocols for accessing a content r= epository for UC1? Why?

>> 

>> It seems to me t= hat these are likely to be "light," but are needed.  How do = we expect to get information from one place to the next without at least de= fining what an access API might look like, what supported transport protocols exi= st for the given technology, and what identifiers to use, etc.<= /o:p>

 <= /p>

> I understand why we = want to have a standard protocol for conveying the target system identifica= tion and data collection instructions to the data collector and for getting back the state values. I just don’t understand why w= e need a standard protocol for talking to a content repository for UC1.

 <= /p>

>Maybe we have a diffe= rent idea of how UC1 works. I think UC1 is saying that one party (call it t= he “data requestor”) asks a second party (call it the “da= ta collector”) to gather data (“state values”) relating to = the security of a third party (the “target system”). So we need= standard protocols and data formats that the data requestor can use when t= alking to the data collector. To give a concrete example, the data requestor might say “Send me the list of software installed on = device 374629” and the data collector might respond with a list of in= stalled software.

 <= /p>

>With that model, the = question of how the data collector gathers data about the target system (th= rough the NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state values to request = is not our problem. Arguably, even the nature of the policies used by the d= ata requestor to determine whether it likes the state values may not be our= problem. But I certainly don’t see any need for content repository protocols in this model.

 <= /p>

>Do you have a differe= nt model for UC1? I realize that this is straying into architecture somewha= t but I don’t think we’ll be able to come up with a set of requirements unless we have a common model for what the actors in the syst= em are and how they interact to achieve the goals of the use case.

 <= /p>

Data collector needs to h= ave the assessment content for performing the task the data requestor asked= for. This is 4.1.4 from use case document.

 <= /p>

Chandra.

 <= /p>

 <= /p>

From: Adam Montville [mailto:amontville@tripwire.com] 
Sent: Wednesday, D= ecember 12, 2012 12:09 PM
To: Stephen Hanna<= br> Cc: sacm@ietf.org Subject: Re: SACM = UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@junipe= r.net> wrote:

 

Adam,

 <= /p>

Thanks for putting togeth= er this initial list of requirements. This is a good start. I do have some = questions:

 <= /p>

1)     =  Is BYOD in scope? I think it should be. It’s a fact of life in enterpri= se networks today. If people agree, I would recommend changing your second = requirement to add this at the end: “or brought and owned by end user= s”.

 

This change seems reasonable to me.  We can ens= ure we address the issue, and then leave it to organizations using implemen= tations of the standards/guidelines we produce as to how they want to apply= the technology.

 

 

2)  &nbs= p;   Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

 

It seems to me that these are likely to be "lig= ht," but are needed.  How do we expect to get information from on= e place to the next without at least defining what an access API might look= like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to= say: If you want to get assessment content, find the content repository, a= nd form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-orient= ed interface using a REST API to get this type of thing done, but that's ge= tting the cart before the horse, I think.

 

 <= /p>

I’m glad to see us = moving forward with this and other issues.

 <= /p>

Take care,

 <= /p>

Steve

 <= /p>

From: sacm-bounces@ietf.o= rg [mailto:sac= m-bounces@= ietf.org] O= n Behalf Of Adam Montv= ille
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org Subject: [sacm] SA= CM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide = coverage for enterprises of various sizes and include support for assets de= livered by third-parties
  • Asset representation/identification should support t= hose delivered by a given Service Provider (SP)
  • Supporting data formats and/o= r protocols should support assessment of SP-provided assets
    • =
  • Must provide a me= thod of defining a target system (asset identification; asset classificatio= n)
  • Must provide a method of selecting acceptable state policy (test expressio= n)
  • Must provide a method of retrieving data collection instructions (activity= class: configuration, patch, vulnerability, inventory; object representati= on; state representation)
  • Must provide a method of expressing state collectio= n values (collection language: technical, interrogative; object representat= ion)
  • Must provide a method of comparing actual to expected state values (test= evaluation; test expression)
  • Must provide a protocol for connecting to a co= ntent repository containing SACM content
  • Must provide a protocol for querying= SACM content held in a content repository
  • Must provide a protocol of retriev= ing SACM content from a content repository
  • Must provide a protocol for curati= ng SACM content in a content repository

 

In addition to the above, I would like to suggest th= at we take certain = requirements from= CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control = 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inven= tory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Confi= guration for Hardware and Software on Mobile Devices, Laptops, Workstations= , and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Rem= ediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Confi= gurations for Network Devices such as Firewalls, Routers, and Switches=

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detaile= d requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given= Critical Control.  For example, we may not be in a position to expres= s "authorizations" for software installed on an operating system = in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Con= trol 1, for that matter), which is something with which we should be concer= ned.

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Compliance Arc= hitect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripw= ire.com

 

 

 

No virus found in this message.
Checked by AVG - www.avg.com=
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

No virus found in this message.
Checked by AVG - www.avg.com=
Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12

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

 


Adam W. Montville | Security and Co= mpliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripwire.com=

 

 

 

--_000_F1DFC16DCAA7D3468651A5A776D5796E068E5169SN2PRD0510MB372_-- From Kent_Landfield@mcafee.com Thu Dec 13 09:12:54 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD73521F8807 for ; Thu, 13 Dec 2012 09:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfgB75xEOn2T for ; Thu, 13 Dec 2012 09:12:48 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id A92C221F8558 for ; Thu, 13 Dec 2012 09:12:47 -0800 (PST) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 6a5f_5fe3_bfa10532_c5c7_47fc_a169_469ffc51d92d; Thu, 13 Dec 2012 11:12:34 -0600 Received: from MIVEXAPP1N3.corp.nai.org (10.48.48.63) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 13 Dec 2012 12:09:18 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.159]) by MIVEXAPP1N3.corp.nai.org ([169.254.3.121]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 12:09:18 -0500 From: To: , , Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIABM/mAgAB6igCAAA+tAIAABQmAgAAH3ICAAAb2AIAACrmA//+lBgA= Date: Thu, 13 Dec 2012 17:09:18 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF09E9C3@MIVEXAMER1N1.corp.nai.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [172.25.124.141] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF09E9C3MIVEXAMER1N1corpn_" MIME-Version: 1.0 Cc: bchandra@secpod.com, sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:12:54 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF09E9C3MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Let's walk before we run=85 Where is the need the greatest? From my persp= ective it is the operational side of an organization. Changes are made qui= te often within an organization and excessive additional work, such as has = having to make that same change in 9 different products on potentially many= multiples of systems, seems like it will be most beneficial place to start= . Like to see your definition of curating a repository ;-) but the initial ne= ed is the retrieval of organizationally 'approved' content via a standard i= nterface that products can incorporate for retrieval of updates, etc. That said, it is easy to see how a protocol could be developed to not only = solve the local distribution issues but the larger distribution of 'authori= tative' content. By authoritative content, I mean content from policy guida= nce authors, such as primary source vendors, industry groups such as CIS, e= tc. If we are looking for initial scoping for the effort I would start with= the critical local distribution means but look at the overall problem so w= e know where to go next. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Thursday, December 13, 2012 10:36 AM To: David Waltermire >, Adam Montville > Cc: "bchandra@secpod.com" >, "sacm@ietf.org" > Subject: Re: [sacm] SACM UC1 And Related Requirements I=92m glad to see such a clear consensus on this topic and such an active d= iscussion of it on the list. David, Adam, and others have presented clear arguments (both technical and = operational) for including a protocol for accessing a content repository in= our work at this time. Certainly, I don=92t want us to create an incomplet= e solution that only works if additional proprietary protocols are used. An= d I can see that it=92s much more efficient to send references to content a= nd have a separate protocol for fetching the actual content, given a refere= nce. David Solin raises a good question: do we need to specify a protocol for cu= rating the content repository or is it enough to just have a protocol for r= etrieving content? Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Thursday, December 13, 2012 10:58 AM To: Adam Montville; Stephen Hanna Cc: bchandra@secpod.com; sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements Adam, +1. Your point is well stated IMHO. Content management has been a significant barrier to useful adoption of sec= urity automation approaches to date. I reviewed the TCG=92s IF-M for SCAP = during the development of that document and raised these issues. At the ti= me we decided to keep content management out-of-band for the document, rely= ing on proprietary methods to insure the delivery of content. My concerns = were around the potential mismatch between what content is expected to be o= n the access requestor and what content is being used to satisfy a health c= heck. If the content is handled out-of-band, this may be a more regular occ= urrence and is certainly a challenge to contend with in multi-vendor intero= perability scenarios. This all works better if the content is managed prop= erly and if both the access requestor and the policy evaluator have the sam= e content. Of course there are still some circumstances where it is imposs= ible to deploy the latest content (e.g. long-term disconnection from the ne= twork), but this is a secondary issue. The best way to ensure that content is managed properly is to keep it in sc= ope as part of the orchestration process for collection. To support this, = we probably need to support a mechanism that allows content to be pulled by= reference. We may also need a method to =93package=94 the content along w= ith instructions that are exchanged over the control channel allowing a =93= push=94. The latter would enable tightly managed clients. Sincerely, Dave From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Adam Montville Sent: Thursday, December 13, 2012 10:33 AM To: Stephen Hanna Cc: bchandra@secpod.com; sacm@ietf.org Subject: Re: [sacm] SACM UC1 And Related Requirements On Dec 13, 2012, at 7:04 AM, Stephen Hanna > wrote: Chandra wrote: > it is desirable in my view to use references so data collector could pull= the content or data collector knows how to get the content based on the in= structions given by the requestor. Chandra, As I recall, you are the founder of a company (SecPod) that develops and pr= ovides SCAP content on a subscription basis. SecPod was the first company t= o create an SCAP Content Repository and to provide a standard protocol for = accessing it. With all due respect and appreciation for your work (which I = think is of the highest quality), you may have a personal bias toward stand= ardizing a content repository protocol. Could you offer a compelling techni= cal rationale for doing so at this time and as a part of UC1? I=92d also li= ke to hear from other SACM participants on this topic. Let's look at this from the end goal. Imagine that we're "done" with Use C= ase 1. A set of standards that allow us to: 1) define the target system, 2= ) select acceptable state policy, 3) retrieve data collection instructions,= 4) collect actual state values, and 5) compare actual state values. There are two ways we can deal with the selection and retrieval of policy a= nd collection instructions (steps 2 and 3, respectively). We can leave it = up to specific implementations to figure it out on their own and end up wit= h proprietary solutions, or, as presented in Atlanta, we can specify the me= thod(s) by which implementations can connect to and interact with the stora= ge of that information. I ask myself this question: How useful is it to define a content-driven ass= essment method without providing the accompanying method of transmitting th= at content? To me, it's not a benefit to the community at all without addr= essing the basic requirement of getting the content from one place to anoth= er. The goal here is automation, and without that, we're keeping one of th= e worst manual processes around. While this may not be a "technical" reason for keeping the content reposito= ry in scope, I really can't imagine a truly useful set of standards without= one. If there's one thing I think we've learned in the security automatio= n community so far, it's that you can spec schema all day long, but if you = don't have a good way to interoperate in an automated way with other tools = and/or external entities, you're treading water. So, I'm a strong advocate for explicitly recognizing the need for defining = the method by which implementations should expect to connect to a content r= epository, and, therefore, for keeping that squarely in scope for UC1. Thanks, Steve From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 9:47 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Chandra wrote: >> Data collector needs to have the assessment content for performing the t= ask >> the data requestor asked for. This is 4.1.4 from use case document. >Perhaps. If the communications between the data requestor and the data col= lector included all the necessary >content, this interaction could take pla= ce without needing a separate content repository. Maybe this would not >be = efficient so it=92s desirable to use references to content instead of sendi= ng the content itself. Is this true? That could be another scenario. In which case, data requestor is behaving l= ike a content repository with a push model. But, it is desirable in my view= to use references so data collector could pull the content or data collect= or knows how to get the content based on the instructions given by the requ= estor. Chandra. From: Chandrashekhar B [mailto:bchandra@secpod.com] Sent: Thursday, December 13, 2012 1:32 AM To: Stephen Hanna; 'Adam Montville' Cc: sacm@ietf.org Subject: RE: [sacm] SACM UC1 And Related Requirements >Adam Montville wrote: >> > 2) Do we really need protocols for accessing a content repository= for UC1? Why? >> >> It seems to me that these are likely to be "light," but are needed. How= do we expect to get information from one place to the next without at leas= t defining what an access API might look like, what supported transport pro= tocols exist for the given technology, and what identifiers to use, etc. > I understand why we want to have a standard protocol for conveying the ta= rget system identification and data collection instructions to the data col= lector and for getting back the state values. I just don=92t understand why= we need a standard protocol for talking to a content repository for UC1. >Maybe we have a different idea of how UC1 works. I think UC1 is saying tha= t one party (call it the =93data requestor=94) asks a second party (call it= the =93data collector=94) to gather data (=93state values=94) relating to = the security of a third party (the =93target system=94). So we need standar= d protocols and data formats that the data requestor can use when talking t= o the data collector. To give a concrete example, the data requestor might = say =93Send me the list of software installed on device 374629=94 and the d= ata collector might respond with a list of installed software. >With that model, the question of how the data collector gathers data about= the target system (through the NEA protocols or via WMI or SSH) is not our= problem. And how the data requestor determines the list of state values to= request is not our problem. Arguably, even the nature of the policies used= by the data requestor to determine whether it likes the state values may n= ot be our problem. But I certainly don=92t see any need for content reposit= ory protocols in this model. >Do you have a different model for UC1? I realize that this is straying int= o architecture somewhat but I don=92t think we=92ll be able to come up with= a set of requirements unless we have a common model for what the actors in= the system are and how they interact to achieve the goals of the use case. Data collector needs to have the assessment content for performing the task= the data requestor asked for. This is 4.1.4 from use case document. Chandra. From: Adam Montville [mailto:amontville@tripwire.com] Sent: Wednesday, December 12, 2012 12:09 PM To: Stephen Hanna Cc: sacm@ietf.org Subject: Re: SACM UC1 And Related Requirements On Dec 12, 2012, at 9:02 AM, Stephen Hanna > wrote: Adam, Thanks for putting together this initial list of requirements. This is a go= od start. I do have some questions: 1) Is BYOD in scope? I think it should be. It=92s a fact of life in en= terprise networks today. If people agree, I would recommend changing your s= econd requirement to add this at the end: =93or brought and owned by end us= ers=94. This change seems reasonable to me. We can ensure we address the issue, an= d then leave it to organizations using implementations of the standards/gui= delines we produce as to how they want to apply the technology. 2) Do we really need protocols for accessing a content repository for = UC1? Why? It seems to me that these are likely to be "light," but are needed. How do= we expect to get information from one place to the next without at least d= efining what an access API might look like, what supported transport protoc= ols exist for the given technology, and what identifiers to use, etc. I don't think we need anything heavy, just enough to say: If you want to ge= t assessment content, find the content repository, and form your request li= ke this, and you'll get your response. Notionally, it's easy for me to see a service-oriented interface using a RE= ST API to get this type of thing done, but that's getting the cart before t= he horse, I think. I=92m glad to see us moving forward with this and other issues. Take care, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 11, 2012 1:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12 ________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_3CBA099FBA0AB843895D72474092B8CF09E9C3MIVEXAMER1N1corpn_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Let's walk before we run=85  Where is the need the greatest? &nbs= p;From my perspective it is the operational side of an organization.  = Changes are made quite often within an organization and excessive additiona= l work, such as has having to make that same change in 9 different products on potentially many multiples of systems, seems li= ke it will be most beneficial place to start.

Like to see your definition of curating a repository ;-) but the initi= al need is the retrieval of organizationally 'approved' content via a stand= ard interface that products can incorporate for retrieval of updates, etc. =  

That said, it is easy to see how a protocol could be developed to not = only solve the local distribution issues but the larger distribution of 'au= thoritative' content. By authoritative content, I mean content from policy = guidance authors, such as primary source vendors, industry groups such as CIS, etc. If we are looking for in= itial scoping for the effort I would start with the critical local distribu= tion means but look at the overall problem so we know where to go next.

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: Thursday, December 13, 2012 1= 0:36 AM
To: David Waltermire <david.waltermire@nist.gov>, Adam = Montville <amontville@tripwir= e.com>
Cc: "bchandra@secpod.com" <bchandra@secpod.com>, "sacm@ietf.org" <sacm@ietf= .org>
Subject: Re: [sacm] SACM UC1 And Re= lated Requirements

I=92m glad to see such a clear con= sensus on this topic and such an active discussion of it on the list.<= /o:p>

 

David, Adam, and others have prese= nted clear arguments (both technical and operational) for including a proto= col for accessing a content repository in our work at this time. Certainly, I don=92t want us to create an incomp= lete solution that only works if additional proprietary protocols are used.= And I can see that it=92s much more efficient to send references to conten= t and have a separate protocol for fetching the actual content, given a reference.

 

David Solin raises a good question= : do we need to specify a protocol for curating the content repository or i= s it enough to just have a protocol for retrieving content?

 

Thanks,

 

Steve

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A.
Sent: Thursday, December 13, 2012 10:58 AM
To: Adam Montville; Stephen Hanna
Cc: bchandra@secpod.com; = sacm@ietf.org
Subject: Re: [sacm] SACM UC1 And Related Requirements

 

Adam,

 

+1.  Your point is well s= tated IMHO.

 

Content management has been a sign= ificant barrier to useful adoption of security automation approaches to dat= e.  I reviewed the TCG=92s IF-M for SCAP during the development of that document and raised these issues.  At = the time we decided to keep content management out-of-band for the document= , relying on proprietary methods to insure the delivery of content.  M= y concerns were around the potential mismatch between what content is expected to be on the access requestor and what co= ntent is being used to satisfy a health check. If the content is handled ou= t-of-band, this may be a more regular occurrence and is certainly a challen= ge to contend with in multi-vendor interoperability scenarios.  This all works better if the content is = managed properly and if both the access requestor and the policy evaluator = have the same content.  Of course there are still some circumstances w= here it is impossible to deploy the latest content (e.g. long-term disconnection from the network), but this is a sec= ondary issue.

 

The best way to ensure that conten= t is managed properly is to keep it in scope as part of the orchestration p= rocess for collection.  To support this, we probably need to support a mechanism that allows content to be pulled b= y reference.  We may also need a method to =93package=94 the content a= long with instructions that are exchanged over the control channel allowing= a =93push=94.  The latter would enable tightly managed clients.

 

Sincerely,

Dave

 

From:sacm-bou= nces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Adam Montville
Sent: Thursday, December 13, 2012 10:33 AM
To: Stephen Hanna
Cc: bchandra@secpod.com; = sacm@ietf.org
Subject: Re: [sacm] SACM UC1 And Related Requirements

 

 

On Dec 13, 2012, at 7:04 AM, Stephen Hanna <shanna@juniper.net> wrote:

 

Chandra wrote:

> it is desirable in my view to= use references so data collector could pull the content or data collector = knows how to get the content based on the instructions given by the requestor.

 

Chandra,

 

As I recall, you are the founder o= f a company (SecPod) that develops and provides SCAP content on a subscript= ion basis. SecPod was the first company to create an SCAP Content Repository and to provide a standard protocol fo= r accessing it. With all due respect and appreciation for your work (which = I think is of the highest quality), you may have a personal bias toward sta= ndardizing a content repository protocol. Could you offer a compelling technical rationale for doing so at= this time and as a part of UC1? I=92d also like to hear from other SACM pa= rticipants on this topic.

 

 

Let's look at this from the end goal.  Imagine = that we're "done" with Use Case 1.  A set of standards that = allow us to: 1) define the target system, 2) select acceptable state policy= , 3) retrieve data collection instructions, 4) collect actual state values, and 5) compare actual state values.  =

 

There are two ways we can deal with the selection an= d retrieval of policy and collection instructions (steps 2 and 3, respectiv= ely).  We can leave it up to specific implementations to figure it out= on their own and end up with proprietary solutions, or, as presented in Atlanta, we can specify the method(s) by wh= ich implementations can connect to and interact with the storage of that in= formation.

 

I ask myself this question: How useful is it to defi= ne a content-driven assessment method without providing the accompanying me= thod of transmitting that content?  To me, it's not a benefit to the c= ommunity at all without addressing the basic requirement of getting the content from one place to another.  = The goal here is automation, and without that, we're keeping one of the wor= st manual processes around.

 

While this may not be a "technical" reason= for keeping the content repository in scope, I really can't imagine a trul= y useful set of standards without one.  If there's one thing I think w= e've learned in the security automation community so far, it's that you can spec schema all day long, but if you don't have = a good way to interoperate in an automated way with other tools and/or exte= rnal entities, you're treading water.

 

So, I'm a strong advocate for explicitly recognizing= the need for defining the method by which implementations should expect to= connect to a content repository, and, therefore, for keeping that squarely= in scope for UC1.

 

 

 

 

 

Thanks,


Steve

 

From: Chandrashekhar B [mailto:bchandra@secpod.com] <= br> Sent: Thursday, De= cember 13, 2012 9:47 AM
To: Stephen Hanna;= 'Adam Montville'
Cc: sacm@ietf.org
Subject: RE: [sacm= ] SACM UC1 And Related Requirements

 

>Chandra wrote:

>> Data collector needs to h= ave the assessment content for performing the task

>> the data requestor asked = for. This is 4.1.4 from use case document.

 

>Perhaps. If the communications= between the data requestor and the data collector included all the necessa= ry >content, this interaction could take place without needing a separate content repository. Maybe this would not = >be efficient so it=92s desirable to use references to content instead o= f sending the content itself. Is this true?

 

That could be another scenario. In= which case, data requestor is behaving like a content repository with a pu= sh model. But, it is desirable in my view to use references so data collector could pull the content or data co= llector knows how to get the content based on the instructions given by the= requestor.

 

Chandra.

 

 

From: Chandrashekhar B [mai= lto:bchandra@secpod.com]&n= bsp;
Sent: Thursday, De= cember 13, 2012 1:32 AM
To: Stephen Hanna;= 'Adam Montville'
Cc: sacm@ietf.org Subject: RE: [sacm= ] SACM UC1 And Related Requirements

 

>Adam Montville wrote:

>> > 2)   =    Do we really need protocols for accessing a content repository= for UC1? Why?

>> 

>> It seems to me that these= are likely to be "light," but are needed.  How do we expect= to get information from one place to the next without at least defining what an access API might look like, what supported transpor= t protocols exist for the given technology, and what identifiers to use, et= c.

 

> I understand why we want to h= ave a standard protocol for conveying the target system identification and = data collection instructions to the data collector and for getting back the state values. I just don=92t understand= why we need a standard protocol for talking to a content repository for UC= 1.

 

>Maybe we have a different idea= of how UC1 works. I think UC1 is saying that one party (call it the =93dat= a requestor=94) asks a second party (call it the =93data collector=94) to gather data (=93state values=94) relating to = the security of a third party (the =93target system=94). So we need standar= d protocols and data formats that the data requestor can use when talking t= o the data collector. To give a concrete example, the data requestor might say =93Send me the list of software installed on = device 374629=94 and the data collector might respond with a list of instal= led software.

 

>With that model, the question = of how the data collector gathers data about the target system (through the= NEA protocols or via WMI or SSH) is not our problem. And how the data requestor determines the list of state value= s to request is not our problem. Arguably, even the nature of the policies = used by the data requestor to determine whether it likes the state values m= ay not be our problem. But I certainly don=92t see any need for content repository protocols in this model.

 

>Do you have a different model = for UC1? I realize that this is straying into architecture somewhat but I d= on=92t think we=92ll be able to come up with a set of requirements unless we have a common model for what the actors in= the system are and how they interact to achieve the goals of the use case.=

 

Data collector needs to have the a= ssessment content for performing the task the data requestor asked for. Thi= s is 4.1.4 from use case document.

 

Chandra.

 

 

From: Adam Montville [mailto:amontville@tripwire.com] 
Sent: Wednesday, D= ecember 12, 2012 12:09 PM
To: Stephen Hanna<= br> Cc: sacm@ietf.org Subject: Re: SACM = UC1 And Related Requirements

 

 

On Dec 12, 2012, at 9:02 AM, Stephen Hanna <shanna@junipe= r.net> wrote:

 

Adam,

 

Thanks for putting together this i= nitial list of requirements. This is a good start. I do have some questions= :

 

1)&n= bsp;     Is BYOD in scope? I think it should be. It=92s a fact of life in enterprise n= etworks today. If people agree, I would recommend changing your second requ= irement to add this at the end: =93or brought and owned by end users=94.

 

This change seems reasonable to me.  We can ens= ure we address the issue, and then leave it to organizations using implemen= tations of the standards/guidelines we produce as to how they want to apply= the technology.

 

 

2)    &= nbsp; Do we really need protocols for accessing a content repository for UC1? Why?<= /span>

 

It seems to me that these are likely to be "lig= ht," but are needed.  How do we expect to get information from on= e place to the next without at least defining what an access API might look= like, what supported transport protocols exist for the given technology, and what identifiers to use, etc. 

 

I don't think we need anything heavy, just enough to= say: If you want to get assessment content, find the content repository, a= nd form your request like this, and you'll get your response.

 

Notionally, it's easy for me to see a service-orient= ed interface using a REST API to get this type of thing done, but that's ge= tting the cart before the horse, I think.

 

 

I=92m glad to see us moving forwar= d with this and other issues.

 

Take care,

 

Steve

 

From: sacm= -bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montv= ille
Sent: Tuesday, Dec= ember 11, 2012 1:39 PM
To: sacm@ietf.org Subject: [sacm] SA= CM UC1 And Related Requirements

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide = coverage for enterprises of various sizes and include support for assets de= livered by third-parties
  • Asset representation/identification should support t= hose delivered by a given Service Provider (SP)
  • Supporting data formats and/o= r protocols should support assessment of SP-provided assets
    • =
  • Must provide a me= thod of defining a target system (asset identification; asset classificatio= n)
  • Must provide a method of selecting acceptable state policy (test expressio= n)
  • Must provide a method of retrieving data collection instructions (activity= class: configuration, patch, vulnerability, inventory; object representati= on; state representation)
  • Must provide a method of expressing state collectio= n values (collection language: technical, interrogative; object representat= ion)
  • Must provide a method of comparing actual to expected state values (test= evaluation; test expression)
  • Must provide a protocol for connecting to a co= ntent repository containing SACM content
  • Must provide a protocol for querying= SACM content held in a content repository
  • Must provide a protocol of retriev= ing SACM content from a content repository
  • Must provide a protocol for curati= ng SACM content in a content repository

 

In addition to the above, I would like to suggest th= at we take certain = requirements from= CSIS 20 Critical Security Controls [1] under the following controls:

 

  • Critical Control = 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inven= tory of Authorized and Unauthorized Software
  • Critical Control 3: Secure Confi= guration for Hardware and Software on Mobile Devices, Laptops, Workstations= , and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Rem= ediation
  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Confi= gurations for Network Devices such as Firewalls, Routers, and Switches=

 

 

I have not yet parsed through each of the Critical Controls, but anticipate more detaile= d requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given= Critical Control.  For example, we may not be in a position to expres= s "authorizations" for software installed on an operating system = in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Con= trol 1, for that matter), which is something with which we should be concer= ned.

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 


Adam W. Montville | Security and Compliance Architect

Direct: = 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE: SECURED
www.tripw= ire.com

 

 

 

No virus found in this message.
Checked by AVG - www.avg.com=
Version: 2013.0.2805 / Virus Database: 2634/5953 - Release Date: 12/12/12

No virus found in this message.
Checked by AVG - www.avg.com=
Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12

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

 


Adam W. Montville | Security and Compliance Architect=

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE=  | CONFIDENCE:&nbs= p;SECURED
www.tripwire.com=

 

 

 

 --_000_3CBA099FBA0AB843895D72474092B8CF09E9C3MIVEXAMER1N1corpn_-- From dromasca@avaya.com Thu Dec 13 09:15:14 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2D621F8B24 for ; Thu, 13 Dec 2012 09:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L-ksHiAmLRm for ; Thu, 13 Dec 2012 09:15:11 -0800 (PST) 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 5116E21F8B16 for ; Thu, 13 Dec 2012 09:15:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAEvoFDGmAcF/2dsb2JhbABEgkkjwGmBCIIeAQEBAQMSG0EbAgEIDQEDBAEBCx0HMhQJCAIEARIIARmHaAEKniacAYwVhWlhA5wJijaCb4IZ X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208,217";a="40409969" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Dec 2012 12:05:53 -0500 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Dec 2012 12:12:20 -0500 Received: from AZ-FFEXHC01.global.avaya.com (135.64.58.11) by DC-US1HCEX1.global.avaya.com (135.11.52.36) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 13 Dec 2012 12:15:08 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 12:15:06 -0500 From: "Romascanu, Dan (Dan)" To: Adam Montville , "sacm@ietf.org" Thread-Topic: SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgW+O8g Date: Thu, 13 Dec 2012 17:15:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA03FDD8@AZ-FFEXMB04.global.avaya.com> References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> In-Reply-To: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.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_9904FB1B0159DA42B0B887B7FA8119CA03FDD8AZFFEXMB04globala_" MIME-Version: 1.0 Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:15:14 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA03FDD8AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This seems to me a good starting set. I have a few questions - see in-line. Thanks and Regards, Dan From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Tuesday, December 11, 2012 8:39 PM To: sacm@ietf.org Subject: [sacm] SACM UC1 And Related Requirements All: After trolling through some of the SACM mailing list, and reviewing SACM Bo= F minutes from IETF 85 and the current Use Case draft looking for requireme= nts, and here's what I've pulled together so far: * UC1 must provide coverage for enterprises of various sizes and includ= e support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Supporting data formats and/or protocols should support assessment of= SP-provided assets * Must provide a method of defining a target system (asset identificati= on; asset classification) * Must provide a method of selecting acceptable state policy (test expr= ession) * Must provide a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) * Must provide a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) * Must provide a method of comparing actual to expected state values (t= est evaluation; test expression) * Must provide a protocol for connecting to a content repository contai= ning SACM content * Must provide a protocol for querying SACM content held in a content r= epository * Must provide a protocol of retrieving SACM content from a content rep= ository * Must provide a protocol for curating SACM content in a content reposi= tory [[DR]] Assuming that the difference between 'method' and 'protocol' in the = above is intentional - why is a 'protocol' considered necessary for queryin= g SACM content? Can't this be some kind of remote procedure that can be lau= nched and results retrieved remotely by using the same 'protocol' used for = retrieving SACM content? I also assume that we agree that we need nod inven= t a new protocol for each one of these requirements, but rather use or exte= nd existing protocols? In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on [[DR]] The use of 'continuous' here scares me. What is the time granularity= we assume for assessment in SACM? * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches [[DR]] By 'secure configurations' we mean that the configurations are secur= ed, or that the configurations operations are secured, or both, or ...? I have not yet parsed through each of the Critical Controls, but anticipate= more detailed requirements to come out of them. I emphasize that we will = not be seeking to meet every requirement expressed by a given Critical Cont= rol. For example, we may not be in a position to express "authorizations" = for software installed on an operating system in a given context. But, Cri= tical Control 2 does require accurate and meaningful asset identification (= as does Critical Control 1, for that matter), which is something with which= we should be concerned. I have this Friday (12/14) dedicated to fleshing out these requirements. I= f you have contributions to make, I respectfully request that you do so bef= ore then. Regards, Adam [1] http://www.sans.org/critical-security-controls/ --_000_9904FB1B0159DA42B0B887B7FA8119CA03FDD8AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This seems to me a good s= tarting set. I have a few questions – see in-line.

 <= /p>

Thanks and Regards,<= /o:p>

 <= /p>

Dan

 <= /p>

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 8:39 PM
To: sacm@ietf.org
Subject: [sacm] SACM UC1 And Related Requirements<= /p>

 

All:

 

After trolling through some of the SACM mailing list= , and reviewing SACM BoF minutes from IETF 85 and the current Use Case draf= t looking for requirements, and here's what I've pulled together so far:&nb= sp;

 

  • UC1 must provide coverage for enterprises of various sizes and include supp= ort for assets delivered by third-parties
  • Asset representation/identification should support those delivered by a giv= en Service Provider (SP)
  • Supporting data formats and/or protocols should support assessment of SP-pr= ovided assets
  • Must provide a method of defining a target system (asset identification; as= set classification)
  • Must provide a method of selecting acceptable state policy (test expression= )
  • Must provide a method of retrieving data collection instructions (activity = class: configuration, patch, vulnerability, inventory; object representatio= n; state representation)
  • Must provide a method of expressing state collection values (collection lan= guage: technical, interrogative; object representation)
  • Must provide a method of comparing actual to expected state values (test ev= aluation; test expression)
  • Must provide a protocol for connecting to a content repository containing S= ACM content
  • Must provide a protocol for querying SACM content held in a content reposit= ory
  • Must provide a protocol of retrieving SACM content from a content repositor= y
  • Must provide a protocol for curating SACM content in a content repository

 

[[DR]] Assuming tha= t the difference between ‘method’ and ‘protocol’ in= the above is intentional – why is a ‘protocol’ considere= d necessary for querying SACM content? Can’t this be some kind of remote procedure that can b= e launched and results retrieved remotely by using the same ‘protocol= ’ used for retrieving SACM content? I also assume that we agree that = we need nod invent a new protocol for each one of these requirements, but rather use or extend existing protocols?

 <= /p>

In addition to the above, I would like to suggest th= at we take certain requirements from CSIS 20 Critical Security Controls = [1] under the following controls:

 

  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software<= /o:p>
  • Critical Control 3: Secure Configuration for Hardware and Software on Mobil= e Devices, Laptops, Workstations, and Servers
  • Critical Control 4: Continuous Vulnerability Assessment and Remediation

[[DR]] The use of ‘continuo= us’ here scares me. What is the time granularity we assume for assess= ment in SACM?

  • Critical Control 5: Malware Defenses
  • Critical Control 10: Secure Configurations for Network Devices such as Fire= walls, Routers, and Switches

[[DR]] By ‘secure configura= tions’ we mean that the configurations are secured, or that the configurations operations are secured, or both, or …?=

 

 

I have not yet parsed through each of = the Critical Controls, but anticipate more detailed requirements to come ou= t of them.  I emphasize that we will not be seeking to meet every requ= irement expressed by a given Critical Control.  For example, we may not be in a position to express "authorizat= ions" for software installed on an operating system in a given context= .  But, Critical Control 2 does require accurate and meaningful asset = identification (as does Critical Control 1, for that matter), which is something with which we should be concerned.<= /p>

 

I have this Friday (12/14) dedicated to fleshing out= these requirements.  If you have contributions to make, I respectfull= y request that you do so before then.

 

Regards,

 

Adam

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA03FDD8AZFFEXMB04globala_-- From gunnar.engelbach@threatguard.com Thu Dec 13 09:17:02 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93921F8B5D for ; Thu, 13 Dec 2012 09:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IymYEXT1+FIa for ; Thu, 13 Dec 2012 09:17:02 -0800 (PST) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id F0A5821F8B24 for ; Thu, 13 Dec 2012 09:17:01 -0800 (PST) Received: (qmail 16281 invoked from network); 13 Dec 2012 09:21:15 -0800 Received: from h69-131-112-165.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (69.131.112.165) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Dec 2012 09:21:15 -0800 Message-ID: <50CA0DA1.30805@ThreatGuard.com> Date: Thu, 13 Dec 2012 12:17:21 -0500 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> <50CA0106.7000005@joval.org> In-Reply-To: <50CA0106.7000005@joval.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:17:03 -0000 Both are needed, really, but with the part inside the enterprise being the more critical. The content has to originate somewhere, which would be the root (or "source" or whatever) repositories, and which could also include a local source used for custom content within a single enterprise. And with multiple source repositories there's also the possibility of having more than one test for the same thing, so some sort of deconfliction becomes beneficial. Within an enterprise there are potentially multiple entities that need to be working with the same data. The collector and evaluatator, for example, with possible overlap in these functions from multiple products. This part is potentially very interactive and can therefore generate a large amount of traffic. At the same time, simply replicating the contents of the repository results in a huge amount of data transfer and storage for data that will be mostly unused if that local repository is *too* local (e.g.: on every asset). There are also odd cases like historical data. When viewing results from a test that was later revised or obsoleted it would be beneficial to view that in the context of how it was defined at that time and not how it is currently defined. With that in mind, keeping things simple for now seems to be the goal. For the root repositories, simple replication via pull may be sufficient, and we'll just assume that commercial repositories will use their own methods to control the level of data that can be replicated based on the account used. For local repositories, perhaps something functionally similar to IMAP. And as long as we're on the repository topic: a repository can potentially contain multiple content types. Not just the security automation benchmarks, but the source documentation for those benchmarks, the regulatory statutes, how-to videos, and so on. --gun On 12/13/2012 11:23 AM, David Solin wrote: > +1 > > This is a well-stated point, and hopefully gets us all on the same > page. It's communication with the latter type of repository that I > believe we're all interested in standardizing. > > On 12/13/2012 10:21 AM, Gunnar Engelbach wrote: >> >> It sounds to me like there needs to be two types of repositories. One >> that is as local to the point of usage as possible and another that is >> a root or definitive data source, such as is provided by vendors. >> >> For the latter it's very much in line to seek input from commercial >> operators like Chandra to be sure that the needs of access control are >> addressed in a way that is sufficient and practical. > > > -- > > jOVAL.org: SCAP Simplified. > Learn More | Features > | Download > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From gapinski@nasa.gov Thu Dec 13 10:24:33 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5246821F8AF3 for ; Thu, 13 Dec 2012 10:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teeWL7cSSm6v for ; Thu, 13 Dec 2012 10:24:26 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id BDEE721F8AE5 for ; Thu, 13 Dec 2012 10:24:25 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 04D43A8817; Thu, 13 Dec 2012 12:24:25 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qBDIOOA8010137; Thu, 13 Dec 2012 12:24:24 -0600 Received: from [192.168.0.5] (173.88.163.24) by smtp01.ndc.nasa.gov (198.117.1.160) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Dec 2012 12:24:24 -0600 Message-ID: <50CA1D55.5070406@nasa.gov> Date: Thu, 13 Dec 2012 13:24:21 -0500 From: Gary Gapinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adam Montville References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> In-Reply-To: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> X-Enigmail-Version: 1.4.6 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-13_08:2012-12-13, 2012-12-13, 1970-01-01 signatures=0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:24:34 -0000
This is a good start. Thanks for assembling it.

Comments and questions inline. RFC2119 assumed for MUST, etc.

On 12/11/2012 01:39 PM, Adam Montville wrote:
All:

After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far: 

  • UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties

US DoD is a good edge case. My domestic appliances are as well (though I do not normally consider the domicile an "enterprise"). Shall these be the approximate bounds?

This appears to be two distinct requirements, best stated distinctly.

  • Asset representation/identification should support those delivered by a given Service Provider (SP)

I am uncertain what this means. Does this mean "those schemes of asset representation and identification adopted by a SP", or "those assets delivered by a service provider"? I suspect the latter.

The statement implies SACM will field or adopt one (or more than one) asset representation/identification scheme. If this implication is correct, the statement appears to levy the requirement "the SACM asset representation/identification schemes SHOULD support representation/identification of any assets delivered by any service provider".

Shall asset representation/identification schemes apply to assets not delivered by a service provider?

  • Supporting data formats and/or protocols should support assessment of SP-provided assets

This seems only a restatement of the "everything SACM applies to assets provided directly or indirectly by the enterprise" requirement. And weakened to a SHOULD.

  • Must provide a method of defining a target system (asset identification; asset classification)

Might this a MAY? No problem as long as the term "a method" does not preclude "methods". I'm reasonably sure there are extant identification and classification methods already suitable in some circumstances.

  • Must provide a method of selecting acceptable state policy (test expression)

This is essential. However, I'm certain a single method will not suffice. No problem as long as the term "a method" does not preclude "methods"

  • Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation)

Only one method?

I have this same misgiving repeatedly, as well as the "provide" rather than "specify" distinction. The former implies "will create", as opposed to "will create or select", augmented by "amongst extant standards". Please apply this misgiving to other items.

Is this simply that the multiple types of inquiries must be capable of being typified?

  • Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation)

I am unsure what this means, particularly considering the following requirement appears to suffice.

  • Must provide a method of comparing actual to expected state values (test evaluation; test expression)

How does this differ from "Must provide a method of selecting acceptable state policy (test expression)"? This also verges on implementation.

  • Must provide a protocol for connecting to a content repository containing SACM content

There are some extant protocols which appear quite serviceable, such as HTTP.

  • Must provide a protocol for querying SACM content held in a content repository

There are some extant protocols which appear quite serviceable, such as HTTP.

  • Must provide a protocol of retrieving SACM content from a content repository

There are some extant protocols which appear quite serviceable, such as HTTP.

  • Must provide a protocol for curating SACM content in a content repository

This will likely be difficult to adequately describe, as a repository could be as simple as a version control repository such as one maintained using git.

Would not such a (git) repository suffice for some types of use, as well as the explicit ways in which one can perturb content therein?



Regards,

Gary

From gapinski@nasa.gov Thu Dec 13 16:33:17 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68D21F86B4 for ; Thu, 13 Dec 2012 16:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS07nihtbGNC for ; Thu, 13 Dec 2012 16:33:16 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id A956A21F8645 for ; Thu, 13 Dec 2012 16:33:16 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 1ACE02D8600; Thu, 13 Dec 2012 18:33:15 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qBE0XEex001888; Thu, 13 Dec 2012 18:33:14 -0600 Received: from [192.168.0.5] (173.88.163.24) by smtp01.ndc.nasa.gov (198.117.1.161) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Dec 2012 18:33:14 -0600 Message-ID: <50CA73C8.5040203@nasa.gov> Date: Thu, 13 Dec 2012 19:33:12 -0500 From: Gary Gapinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Gunnar Engelbach References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> <50CA0106.7000005@joval.org> <50CA0DA1.30805@ThreatGuard.com> In-Reply-To: <50CA0DA1.30805@ThreatGuard.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-13_09:2012-12-13, 2012-12-13, 1970-01-01 signatures=0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 00:33:17 -0000 These are very good observations overall, and in particular On 12/13/2012 12:17 PM, Gunnar Engelbach wrote: > And with multiple source repositories there's also the possibility of > having more than one test for the same thing, so some sort of > deconfliction becomes beneficial. identifies something that has thus far been potentially beneficial, elusive, and alluring. And probably implies a lack only of the ability to discern (as opposed to identify and stamp out) sameness. "Enumerations" have been proposed, but these have yet to achieve planetary dominance. There will of course be any number of "repositories". There may as well be any number of "repositories" which assert primacy, uniqueness, singularity, etc., all to no avail. The best one can expect is for a "repository", namely, a noted and trusted source of normative content, to be useful enough to be commonly employed, and to employ useful characteristic descriptions for concepts of interest. Deconfliction implies removal of duplicative effort (or of conflict, if there is indeed such a thing); establishing how norms are duplicative is difficult, and I'm unsure if this should be an immediate SACM goal. Certainly worth pursuing in the longer term; we as yet lack the ability to describe goals in a normative way suitable for identifying duplication, much less the goals. In any case, the first task is to devise a means to describe desired security posture; doing so in a way that allows identification of duplicate statements is important but not essential. From bchandra@secpod.com Fri Dec 14 00:10:04 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F3521F8929; Fri, 14 Dec 2012 00:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5yQ6Pf0kfMH; Fri, 14 Dec 2012 00:10:03 -0800 (PST) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id C73C221F88E7; Fri, 14 Dec 2012 00:10:02 -0800 (PST) Received: from [182.72.99.242] (port=2837 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TjQLH-0000Wl-9e; Fri, 14 Dec 2012 13:39:59 +0530 From: "Chandrashekhar B" To: "'Field, John'" , "'Luis Nunez'" References: In-Reply-To: Date: Fri, 14 Dec 2012 13:39:49 +0530 Organization: SecPod Technologies Message-ID: <010201cdd9d2$658b4d00$30a1e700$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbiXiqSOwA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Get-Message-Sender-Via: cpanel23.interactivedns.com: authenticated_id: bchandra@secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 08:10:04 -0000 Reopening an old thread... >The issues that would need to be resolved include making the authentication to the scaprepo seamless >(possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in >interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations >(including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST >for write operations. But, this is a relatively minor issue at this point. The more important point is that by >using a REST approach such an integration would become possible, and that would be of benefit to users >dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together >quite nicely. We have now addressed these concerns in SCAP Repo's web service interface. The authentication and authorization rely on an HTTP Authorization header containing an optional authorization assertion. I say optional because that is to be used by subscribers. Also, all the interfaces are now HTTP GET based. The interface document is available here: https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be downloaded from https://www.scaprepo.com Appreciate your feedback! Chandra. -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues. -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, > > Cross posting this announcement from MILE to SACM, as I think this may be of interest within the SCAP community as well. > > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. > > I hope you'll find this draft to be of interest. > > Please post any questions or comments to the MILE list. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > > > > -----Original Message----- > From: Field, John > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt > > All, > > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt > > > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. > > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 > > > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. > > > > > The IETF Secretariat > > > _______________________________________________ > sacm mailing 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 bchandra@secpod.com Fri Dec 14 06:15:20 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5B21F8689; Fri, 14 Dec 2012 06:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN+btgE2YHJy; Fri, 14 Dec 2012 06:15:19 -0800 (PST) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60F21F85BF; Fri, 14 Dec 2012 06:15:19 -0800 (PST) Received: from [182.72.99.242] (port=1692 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TjW2o-0003Bh-PI; Fri, 14 Dec 2012 19:45:19 +0530 From: "Chandrashekhar B" To: "'Michael Hammer'" References: <010201cdd9d2$658b4d00$30a1e700$@secpod.com> <00C069FD01E0324C9FFCADF539701DB33270490B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB33270490B@EX2K10MB1.corp.yaanatech.com> Date: Fri, 14 Dec 2012 19:45:09 +0530 Organization: SecPod Technologies Message-ID: <017c01cdda05$6e594c10$4b0be430$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbgClUlQ2AHLYVJ/l2kwg0A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Get-Message-Sender-Via: cpanel23.interactivedns.com: authenticated_id: bchandra@secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 14:15:20 -0000 Mike, There was a comment about SCAP Repo in this thread, which was not initiated by me. I am responding to that comment now as we addressed that. Now, is this contribution to IETF? There's a good amount of discussion happening in the SACM list around content repository. If this is useful, whoever authors the draft, am happy to share it. The intention is not to influence anybody but to share it if it make sense. Chandra. -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, December 14, 2012 7:22 PM To: bchandra@secpod.com; johnp.field@emc.com; lnunez@c3isecurity.com Cc: mile@ietf.org; sacm@ietf.org Subject: RE: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Is this intended to be a contribution to the IETF? Mike -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Chandrashekhar B Sent: Friday, December 14, 2012 3:10 AM To: 'Field, John'; 'Luis Nunez' Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Reopening an old thread... >The issues that would need to be resolved include making the >authentication to the scaprepo seamless >(possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in >interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations >(including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST >for write operations. But, this is a relatively minor issue at this point. The more important point is that by >using a REST approach such an integration would become possible, and that would be of benefit to users >dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together >quite nicely. We have now addressed these concerns in SCAP Repo's web service interface. The authentication and authorization rely on an HTTP Authorization header containing an optional authorization assertion. I say optional because that is to be used by subscribers. Also, all the interfaces are now HTTP GET based. The interface document is available here: https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be downloaded from https://www.scaprepo.com Appreciate your feedback! Chandra. -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues. -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, > > Cross posting this announcement from MILE to SACM, as I think this may > be of interest within the SCAP community as well. > > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. > > I hope you'll find this draft to be of interest. > > Please post any questions or comments to the MILE list. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > > > > -----Original Message----- > From: Field, John > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt > > All, > > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt > > > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. > > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 > > > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. > > > > > The IETF Secretariat > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From solin@farnamhallventures.com Fri Dec 14 06:55:53 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD1121F857D for ; Fri, 14 Dec 2012 06:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcAZjoHeoJPF for ; Fri, 14 Dec 2012 06:55:52 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B24221F856E for ; Fri, 14 Dec 2012 06:55:51 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so3398808obc.31 for ; Fri, 14 Dec 2012 06:55:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=og7hBn0xJ1yt5RM6PLuKlXyuh+p7Xbe83CVD2ll5xQs=; b=EG1V6OiKLqz7HcXPB1bzpk+JWKQeXFiK2OIHU5zT3y2dZdgYXPX2Fnq5Gx3b2Ooc64 LKOGPQs7WruTzWLnfEY5pIxjsxU2CNsoR8kbGTtI4iz9lPTmr2j/LVW+Vw75XH862n7a I0oxOV6165EeWp7EdKDV/7DGHFc4Pl8/u0Xy/ZYhC6ANkc757cnZFBwzi8WPCuuzYCpj dCjC972ECufX9CRJGZrl8qqfoyLpIJJ9dxANleBAV3ZsUeXXxHt8BlJZr7112LN/V3ns e9Q3RGbZRHDNM64nEQSxXqMP1Z9sTAECPj+uFM3VFqvJcXcZ0wg+5LEU6z61+xqKfOod e5fw== Received: by 10.182.2.169 with SMTP id 9mr4821230obv.66.1355496951229; Fri, 14 Dec 2012 06:55:51 -0800 (PST) Received: from [192.168.0.113] (99-57-135-11.lightspeed.austtx.sbcglobal.net. [99.57.135.11]) by mx.google.com with ESMTPS id hz6sm3302191obb.1.2012.12.14.06.55.50 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 06:55:50 -0800 (PST) Sender: David Solin Message-ID: <50CB3DF2.4090304@joval.org> Date: Fri, 14 Dec 2012 08:55:46 -0600 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> <50CA0106.7000005@joval.org> <50CA0DA1.30805@ThreatGuard.com> <50CA73C8.5040203@nasa.gov> In-Reply-To: <50CA73C8.5040203@nasa.gov> Content-Type: multipart/alternative; boundary="------------010004000205030203040000" X-Gm-Message-State: ALoCoQnWJj5iOJu60NYrIYnZW9tKyuo2aK7vVRNKs03Qzjfkm2RpALTVQVN4FqwXnr71khpm/tGs Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 14:55:53 -0000 This is a multi-part message in MIME format. --------------010004000205030203040000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I wholeheartedly agree! And Gary's remark gives rise to the following: IIRC, there was a proposal on the table to derive all OVAL IDs from repository URIs. I think it needed a bit of work, but to prevent the worst kind of "duplication" -- which would be to find some definition masquerading as another because it borrowed an ID (identity theft!) -- this is the sort of concept we need to enforce. That is to say, if we are to allow repositories to contain content, itself containing references to content whose source is another definitive repository (which we should), and if we are to admit the possibility that these repositories may also furnish third-party definitions (which we also should) then we must create a rule in the specification that states how one should determine which repository is the DEFINITIVE one for any given ID namespace. Perhaps an illustration by example would be illuminating... Let's say SecPod hosts a specification-conformant content repository, and inside it there is a definition they created that references a test that originates from MITRE's repository. So the first definition is oval:com.secpod.oval:def:X, and the second is oval:org.mitre.oval:tst:Y. It should be possible to get both from the SecPod repository -- because a repository should be capable of providing working (and therefore complete) content. But if MITRE's own specification-conformant content repository provided an oval:org.mitre.oval:tst:Y that differed from that in SecPod's, we need a way to decide which is authoritative. I would say, probably, MITRE's should be considered authoritative. A warning of some kind should be generated. This means that any repository containing content for which it is not authoritative, implements a contract whereby it promises to faithfully mirror copies of any replicated content from their authoritative source. If we don't have such a rule, and we don't have a mechanism to reach an authoritative source for a definition/test/state/object/etc. given its ID, then all identities are only context-sensitive, and real interdependencies will necessarily require duplication, which is potentially undesirable. Regards, --David Solin On 12/13/2012 6:33 PM, Gary Gapinski wrote: > These are very good observations overall, and in particular > > On 12/13/2012 12:17 PM, Gunnar Engelbach wrote: >> And with multiple source repositories there's also the possibility of >> having more than one test for the same thing, so some sort of >> deconfliction becomes beneficial. > identifies something that has thus far been potentially beneficial, > elusive, and alluring. And probably implies a lack only of the ability > to discern (as opposed to identify and stamp out) sameness. > "Enumerations" have been proposed, but these have yet to achieve > planetary dominance. > > There will of course be any number of "repositories". There may as well > be any number of "repositories" which assert primacy, uniqueness, > singularity, etc., all to no avail. The best one can expect is for a > "repository", namely, a noted and trusted source of normative content, > to be useful enough to be commonly employed, and to employ useful > characteristic descriptions for concepts of interest. > > Deconfliction implies removal of duplicative effort (or of conflict, if > there is indeed such a thing); establishing how norms are duplicative is > difficult, and I'm unsure if this should be an immediate SACM goal. > Certainly worth pursuing in the longer term; we as yet lack the ability > to describe goals in a normative way suitable for identifying > duplication, much less the goals. > > In any case, the first task is to devise a means to describe desired > security posture; doing so in a way that allows identification of > duplicate statements is important but not essential. > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm -- jOVAL.org: SCAP Simplified. Learn More | Features | Download --------------010004000205030203040000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I wholeheartedly agree!  And Gary's remark gives rise to the following:

IIRC, there was a proposal on the table to derive all OVAL IDs from repository URIs.  I think it needed a bit of work, but to prevent the worst kind of "duplication" -- which would be to find some definition masquerading as another because it borrowed an ID (identity theft!) -- this is the sort of concept we need to enforce.

That is to say, if we are to allow repositories to contain content, itself containing references to content whose source is another definitive repository (which we should), and if we are to admit the possibility that these repositories may also furnish third-party definitions (which we also should) then we must create a rule in the specification that states how one should determine which repository is the DEFINITIVE one for any given ID namespace.  Perhaps an illustration by example would be illuminating...

Let's say SecPod hosts a specification-conformant content repository, and inside it there is a definition they created that references a test that originates from MITRE's repository.  So the first definition is oval:com.secpod.oval:def:X, and the second is oval:org.mitre.oval:tst:Y.

It should be possible to get both from the SecPod repository -- because a repository should be capable of providing working (and therefore complete) content.  But if MITRE's own specification-conformant content repository provided an oval:org.mitre.oval:tst:Y that differed from that in SecPod's, we need a way to decide which is authoritative.  I would say, probably, MITRE's should be considered authoritative.  A warning of some kind should be generated.

This means that any repository containing content for which it is not authoritative, implements a contract whereby it promises to faithfully mirror copies of any replicated content from their authoritative source.

If we don't have such a rule, and we don't have a mechanism to reach an authoritative source for a definition/test/state/object/etc. given its ID, then all identities are only context-sensitive, and real interdependencies will necessarily require duplication, which is potentially undesirable.

Regards,
--David Solin

On 12/13/2012 6:33 PM, Gary Gapinski wrote:
These are very good observations overall, and in particular

On 12/13/2012 12:17 PM, Gunnar Engelbach wrote:

And with multiple source repositories there's also the possibility of 
having more than one test for the same thing, so some sort of 
deconfliction becomes beneficial.

identifies something that has thus far been potentially beneficial,
elusive, and alluring. And probably implies a lack only of the ability
to discern (as opposed to identify and stamp out) sameness.
"Enumerations" have been proposed, but these have yet to achieve
planetary dominance.

There will of course be any number of "repositories". There may as well
be any number of "repositories" which assert primacy, uniqueness,
singularity, etc., all to no avail. The best one can expect is for a
"repository", namely, a noted and trusted source of normative content,
to be useful enough to be commonly employed, and to employ useful
characteristic descriptions for concepts of interest.

Deconfliction implies removal of duplicative effort (or of conflict, if
there is indeed such a thing); establishing how norms are duplicative is
difficult, and I'm unsure if this should be an immediate SACM goal.
Certainly worth pursuing in the longer term; we as yet lack the ability
to describe goals in a normative way suitable for identifying
duplication, much less the goals.

In any case, the first task is to devise a means to describe desired
security posture; doing so in a way that allows identification of
duplicate statements is important but not essential.

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


--

jOVAL.org: SCAP Simplified.
Learn More | Features | Download

--------------010004000205030203040000-- From kathleen.moriarty@emc.com Fri Dec 14 07:02:06 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AAA21F85BF; Fri, 14 Dec 2012 07:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnKHFDbPlkpc; Fri, 14 Dec 2012 07:02:04 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E37AF21F85A6; Fri, 14 Dec 2012 07:02:03 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBEF22QH006166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 10:02:02 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 14 Dec 2012 10:01:48 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBEF1gL1019645; Fri, 14 Dec 2012 10:01:42 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 14 Dec 2012 10:01:41 -0500 From: "Moriarty, Kathleen" To: "bchandra@secpod.com" , "'Michael Hammer'" Date: Fri, 14 Dec 2012 10:01:40 -0500 Thread-Topic: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbgClUlQ2AHLYVJ/l2kwg0CAABEZoA== Message-ID: References: <010201cdd9d2$658b4d00$30a1e700$@secpod.com> <00C069FD01E0324C9FFCADF539701DB33270490B@EX2K10MB1.corp.yaanatech.com> <017c01cdda05$6e594c10$4b0be430$@secpod.com> In-Reply-To: <017c01cdda05$6e594c10$4b0be430$@secpod.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:02:06 -0000 Yes, any document posted as an internet draft has been contributed to the I= ETF. John has said he would work on a revision based on comments and we wi= ll be altering the MILE charter to have this part of the MILE WG documents = as it was viewed favorably. If you have comments, please post them to the = MILE list. The discussed changes were to show the generalized approach first, then the= specific examples to MILE so it clearly applies more broadly. Thank you! Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cha= ndrashekhar B Sent: Friday, December 14, 2012 9:15 AM To: 'Michael Hammer' Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [sacm] [mile] New draft for review and comment: draft-field-mi= le-rolie-00.txt Mike, There was a comment about SCAP Repo in this thread, which was not initiated by me. I am responding to that comment now as we addressed that. Now, is this contribution to IETF? There's a good amount of discussion happening in the SACM list around content repository. If this is useful, whoever authors the draft, am happy to share it. The intention is not to influence anybody but to share it if it make sense. Chandra. -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Friday, December 14, 2012 7:22 PM To: bchandra@secpod.com; johnp.field@emc.com; lnunez@c3isecurity.com Cc: mile@ietf.org; sacm@ietf.org Subject: RE: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Is this intended to be a contribution to the IETF? Mike -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Chandrashekhar B Sent: Friday, December 14, 2012 3:10 AM To: 'Field, John'; 'Luis Nunez' Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Reopening an old thread... >The issues that would need to be resolved include making the=20 >authentication to the scaprepo seamless >(possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in >interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations >(including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST >for write operations. But, this is a relatively minor issue at this point. The more important point is that by >using a REST approach such an integration would become possible, and that would be of benefit to users >dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together >quite nicely. We have now addressed these concerns in SCAP Repo's web service interface. The authentication and authorization rely on an HTTP Authorization header containing an optional authorization assertion. I say optional because that is to be used by subscribers.=20 Also, all the interfaces are now HTTP GET based.=20 The interface document is available here: https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be downloaded from https://www.scaprepo.com Appreciate your feedback! Chandra. -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. =20 I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues= . -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, >=20 > Cross posting this announcement from MILE to SACM, as I think this may=20 > be of interest within the SCAP community as well. =20 >=20 > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. =20 >=20 > I hope you'll find this draft to be of interest. =20 >=20 > Please post any questions or comments to the MILE list. >=20 > Regards, > John >=20 > // John P. Field > // Security Architect > // EMC Office of the CTO >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Field, John=20 > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt >=20 > All, >=20 > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt >=20 >=20 > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. >=20 > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 >=20 >=20 > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Fri Dec 14 09:06:06 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0D821F8925 for ; Fri, 14 Dec 2012 09:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV8pzkRdVCVj for ; Fri, 14 Dec 2012 09:06:05 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6722F21F8907 for ; Fri, 14 Dec 2012 09:06:05 -0800 (PST) Received: from mail36-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 17:06:04 +0000 Received: from mail36-co9 (localhost [127.0.0.1]) by mail36-co9-R.bigfish.com (Postfix) with ESMTP id D5A29700184 for ; Fri, 14 Dec 2012 17:06:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzd6eahc85dhzz1de0h1202h1e76h1d1ah1d2ahzz18c673h8275bhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail36-co9 (localhost.localdomain [127.0.0.1]) by mail36-co9 (MessageSwitch) id 1355504709605535_19271; Fri, 14 Dec 2012 17:05:09 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.233]) by mail36-co9.bigfish.com (Postfix) with ESMTP id 8AF119000B7 for ; Fri, 14 Dec 2012 17:05:09 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 17:05:08 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 26248232122F for ; Fri, 14 Dec 2012 08:53:22 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 7337323211D0; Fri, 14 Dec 2012 08:53:21 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 14 Dec 2012 09:10:27 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Fri, 14 Dec 2012 09:05:01 -0800 From: Adam Montville To: David Solin Thread-Topic: [sacm] SACM UC1 And Related Requirements Thread-Index: AQHN187Yio9opl73tE2CcJKkvc8x1JgVZULwgACICgD//3ofgIABZkSAgAB6igCAAA+tAIAABQiAgAAH3ID//3ylkIAAkOuAgAAAiQCAAA8HgIAAecYAgADxAACAACQagA== Date: Fri, 14 Dec 2012 17:05:01 +0000 Message-ID: <1FE66948-678C-413F-9C75-FE63EE9CDB88@tripwire.com> References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> <50CA0106.7000005@joval.org> <50CA0DA1.30805@ThreatGuard.com> <50CA73C8.5040203@nasa.gov> <50CB3DF2.4090304@joval.org> In-Reply-To: <50CB3DF2.4090304@joval.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_1FE66948678C413F9C75FE63EE9CDB88tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 9bfa1e9d-d655-4209-a697-f24a0dbdb6cc X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:06:06 -0000 --_000_1FE66948678C413F9C75FE63EE9CDB88tripwirecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All: This has turned into a really good discussion! I'm pleased with that. Her= e's an updated list based on the feedback heard so far. I have taken Gary= 's feedback to heart and taken the liberty of rewording some statements and= removing others. Also, I think I've addressed some of the "protocol vs. r= emote procedure" issues by stating "protocol and/or interface," with the in= tent of implying that we needn't reinvent the wheel (i.e. where a secured H= TTP connection might be good enough), but that we still need a standardized= way of expressing what we want to do (i.e. the interface). Finally, I alt= ered the content repository curation requirement to MAY from MUST, and adde= d a provenance requirement. * UC1 must provide coverage for enterprises of various sizes * UC1 must provide support for assets delivered by third-parties * Asset representation/identification should support those delivered by= a given Service Provider (SP) * Alternative (?) wording: Asset representation/identification schem= es should support representation/identification of any assets delivered by = any service provider. * Asset representation/identification must support those present in a g= iven enterprise either directly or by extension * May specify at least one method or methods of defining a target syste= m (asset identification; asset classification) amongst extant standards * Must specify at least one method of selecting acceptable state policy= (test expression) amongst extant standards * Must specify a method of retrieving data collection instructions (act= ivity class: configuration, patch, vulnerability, inventory; object represe= ntation; state representation) amongst extant standards * Must specify a method of expressing state collection values (collecti= on language: technical, interrogative; object representation) amongst extan= t standards * Must specify a protocol and/or interface for connecting to a content = repository containing SACM content amongst extant standards * Must specify a protocol and/or interface for querying SACM content he= ld in a content repository amongst extant standards * Must specify a protocol and/or interface to retrieve SACM content fro= m a content repository amongst extant standards * May specify a protocol and/or interface for curating SACM content in = a content repository amongst extant standards * Content repository methods/protocols should specify an acceptable deg= ree of provenance for externally obtained content amongst extant standards In addition to the above, I would like to suggest that we take certain requ= irements from CSIS 20 Critical Security Controls [1] under the following co= ntrols: * Critical Control 1: Inventory of Authorized and Unauthorized Devices * Critical Control 2: Inventory of Authorized and Unauthorized Software * Critical Control 3: Secure Configuration for Hardware and Software on= Mobile Devices, Laptops, Workstations, and Servers * Critical Control 4: Continuous Vulnerability Assessment and Remediati= on * Critical Control 5: Malware Defenses * Critical Control 10: Secure Configurations for Network Devices such a= s Firewalls, Routers, and Switches To address some of the concerns expressed with respect to referencing the C= ritical Security Controls, I can say the following: We'll need to determine= what's "right" as we progress. That said, here are specific responses to = questions that Dan Romascanu had: * Critical Control 4 indicates that daily or weekly vulnerability scans= are required, but does not rule out the option to scan more frequently. K= eep in mind that "continuous" is not the same as "continual," so the freque= ncy of scans will be variable from organization to organization. Therefore= , time granularity should be considered, but not dictated, by the SACM effo= rts. * Critical Control 10 is seeking the same secure configurations as per = Critical Control 3, but applied to network devices. Think of "secure confi= gurations" as a noun rather than a verb - the configuration must configure = the running state of a network device to reasonable security standards. Finally, as a reminder, I haven't yet parsed through each of these Critical= Security Controls, but I believe they represent an important perspective t= o the work we intend to accomplish in SACM. If people are feeling good about this list - it doesn't have to be perfect = - I can start putting this into a draft form. I assume that this should be= an informational document that stands on its own, or we can modify the use= case document to contain this information. I personally like the idea of = a stand-alone document. That said, I'll do what the community thinks is th= e right approach. I'm looking forward to the community's response. Regards, Adam --_000_1FE66948678C413F9C75FE63EE9CDB88tripwirecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7500F99267A25E48BDAF6E017971E348@tripwire.com> Content-Transfer-Encoding: quoted-printable
All:

This has turned into a really good discussion!  I'm pleased with = that.  Here's an updated list based on the feedback heard so far. &nbs= p; I have taken Gary's feedback to heart and taken the liberty of rewording= some statements and removing others.  Also, I think I've addressed some of the "protocol vs. remote procedure"= issues by stating "protocol and/or interface," with the intent o= f implying that we needn't reinvent the wheel (i.e. where a secured HTTP co= nnection might be good enough), but that we still need a standardized way of expressing what we want to do (i.e. the interface). =  Finally, I altered the content repository curation requirement to MAY= from MUST, and added a provenance requirement.

  • UC1 must provide coverage for enterprises of various sizes
  • UC1 = must provide support for assets delivered by third-parties
  • Asset re= presentation/identification should support those delivered by a given Servi= ce Provider (SP)
    • Alternative (?) wording: Asset representation/identification schemes sh= ould support representation/identification of any assets delivered by any s= ervice provider.
  • Asset representation/identification must support those present in = a given enterprise either directly or by extension
  • May specify at l= east one method or methods of defining a target system (asset identificatio= n; asset classification) amongst extant standards
  • Must specify at l= east one method of selecting acceptable state policy (test expression) = ;amongst extant standards
  • Must specify a method of retrieving data = collection instructions (activity class: configuration, patch, vulnerabilit= y, inventory; object representation; state representation) amongst ext= ant standards
  • Must specify a method of expressing state collection = values (collection language: technical, interrogative; object representatio= n) amongst extant standards
  • Must specify a protocol = and/or interface for connecting to a content repository containing SACM con= tent amongst extant standards
  • Must specify a protoco= l and/or interface for querying SACM content held in a content repository&n= bsp;amongst extant standards
  • Must specify a protocol and/= or interface to retrieve SACM content from a content repository amongs= t extant standards
  • May specify a protocol and/or interfac= e for curating SACM content in a content repository amongst extant sta= ndards
  • Content repository methods/protocols should specify an accep= table degree of provenance for externally obtained content amongst ext= ant standards

In addition to the above, I would like to suggest that we take certain requirements from CSIS 20 Critical Security Contro= ls [1] under the following controls:

  • Critical Control 1: Inventory of Authorized and Unauthorized Devices
  • Critical Control 2: Inventory of Authorized and Unauthorized Software=
  • Critical Control 3: Secure Configuration for Hardware and Software= on Mobile Devices, Laptops, Workstations, and Servers
  • Critical Con= trol 4: Continuous Vulnerability Assessment and Remediation
  • Critica= l Control 5: Malware Defenses
  • Critical Control 10: Secure Configura= tions for Network Devices such as Firewalls, Routers, and Switches


To address some of the concerns expressed with respect to referencing = the Critical Security Controls, I can say the following: We'll need to dete= rmine what's "right" as we progress.  That said, here are sp= ecific responses to questions that Dan Romascanu had:

  • Critical Control 4 indicates that daily or weekly vulnerability scans a= re required, but does not rule out the option to scan more frequently. &nbs= p;Keep in mind that "continuous" is not the same as "continu= al," so the frequency of scans will be variable from organization to organization.  Therefore, time granularity should be = considered, but not dictated, by the SACM efforts.
  • Critical Control= 10 is seeking the same secure configurations as per Critical Control 3, bu= t applied to network devices.  Think of "secure configurations&qu= ot; as a noun rather than a verb - the configuration must configure the run= ning state of a network device to reasonable security standards.

Finally, as a reminder, I haven't yet parsed through each of these Cri= tical Security Controls, but I believe they represent an important perspect= ive to the work we intend to accomplish in SACM.

If people are feeling good about this list - it doesn't have to be per= fect - I can start putting this into a draft form.  I assume that this= should be an informational document that stands on its own, or we can modi= fy the use case document to contain this information.  I personally like the idea of a stand-alone document. &= nbsp;That said, I'll do what the community thinks is the right approach.

I'm looking forward to the community's response.

Regards,

Adam
--_000_1FE66948678C413F9C75FE63EE9CDB88tripwirecom_-- From gapinski@nasa.gov Fri Dec 14 12:05:58 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8621F8AE1 for ; Fri, 14 Dec 2012 12:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKPhZZSEs3XG for ; Fri, 14 Dec 2012 12:05:57 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 780DA21F8AB7 for ; Fri, 14 Dec 2012 12:05:57 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id D239C2602EE; Fri, 14 Dec 2012 14:05:56 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qBEK5u8B029865; Fri, 14 Dec 2012 14:05:56 -0600 Received: from [192.168.0.5] (173.88.163.24) by smtp01.ndc.nasa.gov (198.117.1.161) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 14 Dec 2012 14:05:56 -0600 Message-ID: <50CB86A1.4050809@nasa.gov> Date: Fri, 14 Dec 2012 15:05:53 -0500 From: Gary Gapinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Solin References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> <50CA0106.7000005@joval.org> <50CA0DA1.30805@ThreatGuard.com> <50CA73C8.5040203@nasa.gov> <50CB3DF2.4090304@joval.org> In-Reply-To: <50CB3DF2.4090304@joval.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-14_05:2012-12-14, 2012-12-14, 1970-01-01 signatures=0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 20:05:58 -0000 Zounds! (Tarnation having already been achieved.) I had hoped to erode the perceived necessity of stamping out duplication as well as the all too frequent propensity to uniquely number all beasts in the security automation realm. On 12/14/2012 09:55 AM, David Solin wrote: > I wholeheartedly agree! And Gary's remark gives rise to the following: > … Instead, to my abject horror, I find I have instead agitated the townsfolk, who have taken up torches and weapons and are marching off to storm the twin towers of Castle Duplex, after which they will fire up the branding irons and start molesting cattle. So, while they are thus engaged, and things are quiet here in town, let me try again. I don't think duplication is a problem. Lack of content is a problem. Paucity of expression is a problem. Unnecessary complexity is a problem. Well-meaning but doomed enumeration schemes are a problem. Let's select a real world - singular - example and vivisect it. For quite some time there has been a doctrine that passwords should have an entropy equal to or greater than some value chosen in concert with some other considerations. The coarse nature of current configuration and evaluation methods often results in a simpler statement: passwords shall have a minimal length enforced by the operating system. This is something that can be specified in a policy, arranged in a system configuration, and the system configuration can be inspected to determine compliance with the policy. The length of a password can be specified and evaluated in different ways on different platforms. Are not such differences simply facets of the single policy? I think they are. We still have one policy, with varying expressions. The specific length of the password will vary amongst parties who impose such a policy. The nature of such variation will undoubtedly spur future debate within the group. I think it profitable to consider such variation separate from the essence of uniqueness. The policy can be stated in different natural languages: again, one policy. The expression of the policy in synthetic languages suitable for security automation can vary. I do not think this increases the number of policies. Various consumers of such a policy might wish to say varying things about it. One common thing is an identifier unique in some domain. This adds facets but does not create more policies. It also creates the task of concordance for the seekers of oneness. The policy with its increasingly large number of facets introduced for the pleasure of various consumers can undergo revision. This causes the single policy to have time-dependent variants. An added dimension. Provenance of a policy is of interest to some. I think this is just another facet. These are some of the easy considerations. Here's a few harder ones, by no means the only ones. A copy of the policy can be made, and such copying will be routine. This does not create a new policy. It does introduce a conundrum for those who abhor duplication, namely, the ability to assert that two copies of a thing are the same thing, or they are not. They are until revision occurs. The password length policy is only one of several policies that together determine appropriate password entropy. How shall these be connected? Unique identifiers for as large a number of individual security policies as will be specified are pleasant to conjecture but in my opinion not possible. IANA registry does not cut it here. Past efforts have been compromised as well by attempts to use other than abstract identifiers. Ultimately, we are talking about documents representing individual policies and compilations thereof. I suspect the definition of duplication is elusive, and may not be as important as thought. Assuming it can be detected, would it not be sufficient to simply assert that two instances are duplicates and move on? It is likely that those who fear duplication are already in despair that not all manipulators of content will abide by a planetary injunction to conform to a single identification scheme. H. L. Mencken's definition of Puritanism comes to mind. Are compilations unique? Are revisions unique? What about revisions to things that had previously been arbitrarily compiled? Arbitrary compilations of security automation content are anticipated in the requirements. Content begets collection. Any uniqueness must be preserved, and fans out with abandon. I'll pause here. While it is impossible to anticipate all manner of statements that might be made regarding security automation content, I would hope that the standards evolve in ways that allow, rather than prohibit, the as yet unanticipated statements. -- Those are my principles, and if you don't like them... well, I have others. - Julius "Groucho" Marx From solin@farnamhallventures.com Fri Dec 14 12:55:09 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DD721F8A6B for ; Fri, 14 Dec 2012 12:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0n4A3pKMiFD for ; Fri, 14 Dec 2012 12:55:05 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB7921F8A28 for ; Fri, 14 Dec 2012 12:55:05 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4004173oag.31 for ; Fri, 14 Dec 2012 12:55:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type:x-gm-message-state; bh=3hDT3zR9T3B3U1ESvmoMBVZm+QVKpt+xMhiN9t9cgK4=; b=Smk6NgNRhvbnjdQjd41Wt0w9z90yDSW+rwTZ6mIXT/FYa2E3a4IbdK/3t6XTW3geY2 lR2FRKMHhnCDNZEkXU20u/boqwzfgTIfzQo7r++p3Qv0MLL+lbeZX3OgievTwK5iRcDC 6aQ1u77NDMH/LZe0syU41Hmn6yypkUqbJIsgR+16+j64JuEqk8ye7c0VJTluygTkyZum LOQ3EyO7vFYRO+yJ+svQMQPwCYpHtdATQbLfj6hWv49hs1b4kIu2vnktjKCY9INs6/c9 VKNnwzYEoCDxik0vg9d/m9/gf75l1nxw9qSvTIsWWG+JytLoQoR74RM3yLeEgvZmbtUm UhaQ== Received: by 10.182.21.135 with SMTP id v7mr5734594obe.101.1355518504531; Fri, 14 Dec 2012 12:55:04 -0800 (PST) Received: from [192.168.0.113] (99-57-135-11.lightspeed.austtx.sbcglobal.net. [99.57.135.11]) by mx.google.com with ESMTPS id zz6sm4021629oeb.1.2012.12.14.12.55.03 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 12:55:03 -0800 (PST) Sender: David Solin Message-ID: <50CB9223.6050002@joval.org> Date: Fri, 14 Dec 2012 14:54:59 -0600 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Gary Gapinski References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> <50CA0106.7000005@joval.org> <50CA0DA1.30805@ThreatGuard.com> <50CA73C8.5040203@nasa.gov> <50CB3DF2.4090304@joval.org> <50CB86A1.4050809@nasa.gov> In-Reply-To: <50CB86A1.4050809@nasa.gov> Content-Type: multipart/alternative; boundary="------------090306090403020408050102" X-Gm-Message-State: ALoCoQnnjbiKaiVdhuYL8XdJV1n5dSTClBNsPz1j+03XQmlf0GRnALevIzTNj44GGEEJWl9Y2k7p Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 20:55:09 -0000 This is a multi-part message in MIME format. --------------090306090403020408050102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Your position, then, Gary, is that there should be no such thing as an external reference? While that eliminates the theoretical problem, it also creates practical ones. But I'll leave my pitchfork in the barn and let others comment, as there is a certain elegance to the idea. On 12/14/2012 2:05 PM, Gary Gapinski wrote: > Zounds! (Tarnation having already been achieved.) > > I had hoped to erode the perceived necessity of stamping out duplication > as well as the all too frequent propensity to uniquely number all beasts > in the security automation realm. > > On 12/14/2012 09:55 AM, David Solin wrote: >> I wholeheartedly agree! And Gary's remark gives rise to the following: >> … > Instead, to my abject horror, I find I have instead agitated the > townsfolk, who have taken up torches and weapons and are marching off to > storm the twin towers of Castle Duplex, after which they will fire up > the branding irons and start molesting cattle. > > So, while they are thus engaged, and things are quiet here in town, let > me try again. > > I don't think duplication is a problem. Lack of content is a problem. > Paucity of expression is a problem. Unnecessary complexity is a problem. > Well-meaning but doomed enumeration schemes are a problem. > > Let's select a real world - singular - example and vivisect it. > > For quite some time there has been a doctrine that passwords should have > an entropy equal to or greater than some value chosen in concert with > some other considerations. The coarse nature of current configuration > and evaluation methods often results in a simpler statement: passwords > shall have a minimal length enforced by the operating system. This is > something that can be specified in a policy, arranged in a system > configuration, and the system configuration can be inspected to > determine compliance with the policy. > > The length of a password can be specified and evaluated in different > ways on different platforms. Are not such differences simply facets of > the single policy? I think they are. We still have one policy, with > varying expressions. > > The specific length of the password will vary amongst parties who impose > such a policy. The nature of such variation will undoubtedly spur future > debate within the group. I think it profitable to consider such > variation separate from the essence of uniqueness. > > The policy can be stated in different natural languages: again, one policy. > > The expression of the policy in synthetic languages suitable for > security automation can vary. I do not think this increases the number > of policies. > > Various consumers of such a policy might wish to say varying things > about it. One common thing is an identifier unique in some domain. This > adds facets but does not create more policies. It also creates the task > of concordance for the seekers of oneness. > > The policy with its increasingly large number of facets introduced for > the pleasure of various consumers can undergo revision. This causes the > single policy to have time-dependent variants. An added dimension. > > Provenance of a policy is of interest to some. I think this is just > another facet. > > These are some of the easy considerations. Here's a few harder ones, by > no means the only ones. > > A copy of the policy can be made, and such copying will be routine. This > does not create a new policy. It does introduce a conundrum for those > who abhor duplication, namely, the ability to assert that two copies of > a thing are the same thing, or they are not. They are until revision occurs. > > The password length policy is only one of several policies that together > determine appropriate password entropy. How shall these be connected? > > Unique identifiers for as large a number of individual security policies > as will be specified are pleasant to conjecture but in my opinion not > possible. IANA registry does not cut it here. Past efforts have been > compromised as well by attempts to use other than abstract identifiers. > Ultimately, we are talking about documents representing individual > policies and compilations thereof. I suspect the definition of > duplication is elusive, and may not be as important as thought. Assuming > it can be detected, would it not be sufficient to simply assert that two > instances are duplicates and move on? > > It is likely that those who fear duplication are already in despair that > not all manipulators of content will abide by a planetary injunction to > conform to a single identification scheme. H. L. Mencken's definition of > Puritanism comes to mind. > > Are compilations unique? > > Are revisions unique? > > What about revisions to things that had previously been arbitrarily > compiled? > > Arbitrary compilations of security automation content are anticipated in > the requirements. Content begets collection. Any uniqueness must be > preserved, and fans out with abandon. > > I'll pause here. While it is impossible to anticipate all manner of > statements that might be made regarding security automation content, I > would hope that the standards evolve in ways that allow, rather than > prohibit, the as yet unanticipated statements. > > -- > Those are my principles, and if you don't like them... well, I have others. > - Julius "Groucho" Marx > -- jOVAL.org: SCAP Simplified. Learn More | Features | Download --------------090306090403020408050102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Your position, then, Gary, is that there should be no such thing as an external reference?

While that eliminates the theoretical problem, it also creates practical ones.  But I'll leave my pitchfork in the barn and let others comment, as there is a certain elegance to the idea.

On 12/14/2012 2:05 PM, Gary Gapinski wrote:
Zounds! (Tarnation having already been achieved.)

I had hoped to erode the perceived necessity of stamping out duplication
as well as the all too frequent propensity to uniquely number all beasts
in the security automation realm.

On 12/14/2012 09:55 AM, David Solin wrote:

I wholeheartedly agree! And Gary's remark gives rise to the following:
…

Instead, to my abject horror, I find I have instead agitated the
townsfolk, who have taken up torches and weapons and are marching off to
storm the twin towers of Castle Duplex, after which they will fire up
the branding irons and start molesting cattle.

So, while they are thus engaged, and things are quiet here in town, let
me try again.

I don't think duplication is a problem. Lack of content is a problem.
Paucity of expression is a problem. Unnecessary complexity is a problem.
Well-meaning but doomed enumeration schemes are a problem.

Let's select a real world - singular - example and vivisect it.

For quite some time there has been a doctrine that passwords should have
an entropy equal to or greater than some value chosen in concert with
some other considerations. The coarse nature of current configuration
and evaluation methods often results in a simpler statement: passwords
shall have a minimal length enforced by the operating system. This is
something that can be specified in a policy, arranged in a system
configuration, and the system configuration can be inspected to
determine compliance with the policy.

The length of a password can be specified and evaluated in different
ways on different platforms. Are not such differences simply facets of
the single policy? I think they are. We still have one policy, with
varying expressions.

The specific length of the password will vary amongst parties who impose
such a policy. The nature of such variation will undoubtedly spur future
debate within the group. I think it profitable to consider such
variation separate from the essence of uniqueness.

The policy can be stated in different natural languages: again, one policy.

The expression of the policy in synthetic languages suitable for
security automation can vary. I do not think this increases the number
of policies.

Various consumers of such a policy might wish to say varying things
about it. One common thing is an identifier unique in some domain. This
adds facets but does not create more policies. It also creates the task
of concordance for the seekers of oneness.

The policy with its increasingly large number of facets introduced for
the pleasure of various consumers can undergo revision. This causes the
single policy to have time-dependent variants. An added dimension.

Provenance of a policy is of interest to some. I think this is just
another facet.

These are some of the easy considerations. Here's a few harder ones, by
no means the only ones.

A copy of the policy can be made, and such copying will be routine. This
does not create a new policy. It does introduce a conundrum for those
who abhor duplication, namely, the ability to assert that two copies of
a thing are the same thing, or they are not. They are until revision occurs.

The password length policy is only one of several policies that together
determine appropriate password entropy. How shall these be connected?

Unique identifiers for as large a number of individual security policies
as will be specified are pleasant to conjecture but in my opinion not
possible. IANA registry does not cut it here. Past efforts have been
compromised as well by attempts to use other than abstract identifiers.
Ultimately, we are talking about documents representing individual
policies and compilations thereof. I suspect the definition of
duplication is elusive, and may not be as important as thought. Assuming
it can be detected, would it not be sufficient to simply assert that two
instances are duplicates and move on?

It is likely that those who fear duplication are already in despair that
not all manipulators of content will abide by a planetary injunction to
conform to a single identification scheme. H. L. Mencken's definition of
Puritanism comes to mind.

Are compilations unique?

Are revisions unique?

What about revisions to things that had previously been arbitrarily
compiled?

Arbitrary compilations of security automation content are anticipated in
the requirements. Content begets collection. Any uniqueness must be
preserved, and fans out with abandon.

I'll pause here. While it is impossible to anticipate all manner of
statements that might be made regarding security automation content, I
would hope that the standards evolve in ways that allow, rather than
prohibit, the as yet unanticipated statements.

--
Those are my principles, and if you don't like them... well, I have others.
- Julius "Groucho" Marx


--

jOVAL.org: SCAP Simplified.
Learn More | Features | Download

--------------090306090403020408050102-- From gapinski@nasa.gov Fri Dec 14 13:48:56 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBC621F8AAC for ; Fri, 14 Dec 2012 13:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.356 X-Spam-Level: X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAM4ZZJ9fGpf for ; Fri, 14 Dec 2012 13:48:55 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07021F8A9F for ; Fri, 14 Dec 2012 13:48:51 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id EEB1326001F; Fri, 14 Dec 2012 15:48:50 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qBELmoTE014526; Fri, 14 Dec 2012 15:48:50 -0600 Received: from [192.168.0.5] (173.88.163.24) by smtp01.ndc.nasa.gov (198.117.1.160) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 14 Dec 2012 15:48:50 -0600 Message-ID: <50CB9EC0.803@nasa.gov> Date: Fri, 14 Dec 2012 16:48:48 -0500 From: Gary Gapinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Solin References: <1ED26931-9A6F-4405-A9AC-09361DE7DB0A@tripwire.com> <60E2C65A-4BA9-44F0-8AE7-78F65A031ECB@tripwire.com> <012001cdd8fb$9b5df770$d219e650$@secpod.com> <002001cdd940$b61eab50$225c01f0$@secpod.com> <9AC807E5-2764-43AA-82BB-1796EBC167E8@tripwire.com> <50CA0093.5000509@ThreatGuard.com> <50CA0106.7000005@joval.org> <50CA0DA1.30805@ThreatGuard.com> <50CA73C8.5040203@nasa.gov> <50CB3DF2.4090304@joval.org> <50CB86A1.4050809@nasa.gov> <50CB9223.6050002@joval.org> In-Reply-To: <50CB9223.6050002@joval.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-14_05:2012-12-14, 2012-12-14, 1970-01-01 signatures=0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM UC1 And Related Requirements X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:48:56 -0000 On 12/14/2012 03:54 PM, David Solin wrote: > Your position, then, Gary, is that there should be no such thing as an > external reference? No (assuming I understand the nature of "external" references. I presume external references are those from from one document to another.). I think there should be as many as desired. I had hoped to express this by stating "Various consumers of such a policy might wish to say varying things about it. One common thing is an identifier unique in some domain.". I expect that creators of security automation content will declare references amongst all the things they deem worthwhile. I hope they do. However, if such references are declared within the content itself (i.e., in a document describing a policy), as opposed to separate and separately maintained statements of such association, it casts the reference in a role that is then subject to considerations at least of revision. Such considerations are manageable if revision enjoys adequate treatment within SACM. I must also caution that external references do not imply the ability to discern anything other than relation. From Erik.Cockrell@polycom.com Mon Dec 17 09:47:32 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C1A21F880D for ; Mon, 17 Dec 2012 09:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8WfWL01CFOK for ; Mon, 17 Dec 2012 09:47:31 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4621F87DD for ; Mon, 17 Dec 2012 09:47:31 -0800 (PST) Received: from CRPMBOXPRD02.polycom.com ([fe80::f86d:4701:a85a:2fb]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 17 Dec 2012 09:47:30 -0800 From: "Cockrell, Erik" To: "sacm@ietf.org" Date: Mon, 17 Dec 2012 09:47:28 -0800 Thread-Topic: Upcoming face to face meetings? Thread-Index: Ac3cfoE1i365ZNJUQriMLqwY24oXHg== Message-ID: <4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7@CRPMBOXPRD02.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [sacm] Upcoming face to face meetings? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 17:47:32 -0000 --_004_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_ Content-Type: multipart/alternative; boundary="_000_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_" --_000_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - are there any upcoming face to face meetings/events/conferences at wh= ich SACM will meet? Erik Cockrell, Product Security Engineer, Product Security Office The holy grail of security is airtight input validation. 7700 Parmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 512.372.7155 | = M: 512.739.4250 [cid:image001.jpg@01CDDC4C.4A3A6AA0] --_000_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All – are = there any upcoming face to face meetings/events/conferences at which SACM w= ill meet?

 

Erik Cockrell, Product Security Engineer, Product Security O= ffice

The holy grail of secur= ity is airtight input validation.

7700 Parmer Lane, Bldg C, Suite 100, A= ustin, TX, 78729 | T: 512.372.7155 | M: 512.739.4250

3D"Descripti=

 

= --_000_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_-- --_004_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=30036; creation-date="Mon, 17 Dec 2012 17:47:28 GMT"; modification-date="Mon, 17 Dec 2012 17:47:28 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/4QNxaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MSA2NC4xNDA5NDksIDIwMTAvMTIvMDctMTA6 NTc6MDEgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6QzVCNEVENTk2ODIxNjgxMThGNjJFM0NDOTI3OEI0OTkiIHhtcE1NOkRvY3VtZW50 SUQ9InhtcC5kaWQ6MUQ5MTg3OTU5OTQ3MTFFMThFMEZBQkY2MTNBN0I1MzgiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6MUQ5MTg3OTQ5OTQ3MTFFMThFMEZBQkY2MTNBN0I1MzgiIHhtcDpDcmVh dG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNS4xIE1hY2ludG9zaCI+IDx4bXBNTTpEZXJpdmVk RnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOkRFMzQ0M0UyMUUyMTY4MTE4OEM2RkQzRENF RTdCMTdCIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOkM1QjRFRDU5NjgyMTY4MTE4RjYyRTND QzkyNzhCNDk5Ii8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8 P3hwYWNrZXQgZW5kPSJyIj8+/+4AJkFkb2JlAGTAAAAAAQMAFQQDBgoNAAAU3gAAPywAAFSDAAB1 Uv/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgIC AgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMD/8IAEQgATwJYAwERAAIRAQMRAf/EARkAAAEEAwEBAAAAAAAA AAAAAAIAAQUGAwQHCAkBAQEBAQADAQEAAAAAAAAAAAABAgMEBQYHCBAAAAUEAQEGBgMAAwEAAAAA AQIEBQYAERIDByEgMEATFggQMSIyFBVQYDdBMxc1EQACAgECBQIDBAYECgYLAAACAwEEBRESACET FAYxIkEVB1FhMiMQIDBCUiRAcTMWUIGRodFiQyW1drFyU7N0dfDh8YKSgzS0NTYIEgABAwEFBQQF CQYHAAAAAAABABECAyExQRIEEFFhgRNAcSIykaFCIwUgMGCxwWJyMxRQ0VLCJBVw8OHxskMGEwEA AgIBAwIGAgMBAQAAAAABABEhMUEQUWFxgSDwkaGxwTDRQOHxUGD/2gAMAwEAAhEDEQAAAftwIWoe a+oUjyuqogoWoea49OPYUrhQh7MJowWpkhxggqOFEk1k1ClKEIgtZwwUIGoCwKVOGjq4UEFCHV5G pKl2CyZbOjSqEBTQFKGoYGlDUBDwhahyvYg8nVUQUKiChVkgKyCQ5UKjiOrEhh2KHo4w2VSwV6Zj b0UOIrdzXdSxyvDxoVE2OKshXbKPqdh56cr1WTNSNqpVDpV9ZtcsvLL504wFNAU40BY0qoTHESIV kJevzj+L/qWXuLJ5Pz3sn6D8VvfkekfULNcew5UENqHKg5HVD0iLhWHKViQypanxs8/w6lqfUzwv KjLOW9M8j3j6h+F5XzG8zxa1qejeXSbjp2NeeumLRNc83mz5vU8a5ZvPmvty9Fculzxryj35e2OH eh6yCbUcc6Y3lv8AnXuXxO6jYtmpdmxpQpoVCCKGoDWjQEc78vw/m78Z/VHpn6H8X9C+1/Prl4/k eQ/m/wBn9Z+//Hfmsego9pC1PP8Am+hBUcNRIoKilVhrhSOlKiHGK/Z85fL8WxTV2xbEvnfrz7Xz 37T8ft4V8nhYZrhnTn2jnu/51Xbnl/TPRM64h0x0LGrtm+iefTzR15wSCvLt46HmgbcYaja75w6e huXR7SFptZkjLnlemjHShUBgjEaQjivsfW/JL8y/uP7Vfe/xrs9/Bx2eC/l/3b197/8AEfHx5ms9 MRBLCV6AjdOXEjWsVaLqcfJQ96Wd8XVTRUghxgghzNEkGIrm4COrw8OjxoVF6hhhmSCXnmpPFpgh qLFeFaVENqPIoeXZrcjOqlRjrHGEE0h0477D1/z2+U/oqI+X/ZvoZ99/IVf9f9N5He893+2/G/jb H1BryRJfDjFtyhwK+tUfJSupnmyO7V6piiHtiiTUl06IIq+8cq7ceh8utQ6c92WRlvHPXLe3LPND UdZb8bjbNFmD1mZzcagOEZ1lJQWD3iNubzz6aMjnRuXZ6enR0eUoexlSlm57MwcYqEUR9FJr15p9 t6357fA/1rwD5H+gOzfffy99g/oP55lfH7ctj0GeErIQ7jL5Jr0BGoU+rXFSruBIx06yGl7IJDrV jSV7IHWa5vMRc5FSa9WHOtLWY4k86gt5yRiqMuTTdls+N0Ppi543ynry3To/LrR94m86i9YsGdQN ya9t4d3tYe5PIlca18nlexh5WsJDCNG0pEurceevbeqpfk+P2L1/sOz+v9gqPNaiFY8vAI9B2HKh 6cQQoeihxURhjQOf9uXBvI8e7Y3JZ1TOnOazrelmJazvOnXROXTkXbjfufRki9Z3pafvHUePWjbz DazmjsHHtbufRB2EFDq4rSZ496r9D4t6n9Hl+vg2/wAr5+6+T89yX1n3lj8j1Ft8j0VU8b3kLz9j K9fA617H4S7+Z82NYIeHp4QVhSuroVKVDoSuEhSvRQ4qUPqPmuOPRQ4FkIUvpjcibmtKzCaFgmjZ trKSx+pISqNG51rDM5tyx8RGpLy2LGiUqJDyKUrXDStcPcavPya7x9vn1zuXk/PwXD2gZ6T/AH9T HY8ytcPcS/XwbB29TYO3q1GnqOHCpDhI6vKYrEIPNelYea9OHCFSh6KHFRDw41aRghxCohwIh9Rz MZaQ49jojelkpajZrWZIPNLVJkwpXtOCkIcWqoLNyCsSDqqClYaCP//aAAgBAQABBQLw2wO6KNw7 O3/s+IhcDBiPfkObWOrcXZ/DHLiNX7Ozbr0a2aRsMi1uMqjrEr7O0xSU1uza9I/juLcOw6O7WyJU k/g67f8ABqd2t8Sdpa+M7cs+Va1NfPvB6dhU5oEGp75lfZK5poDzKsKVy5egRY7I2mVNXfiGQCFu 1IP/AIPCC1RDXuaq1Mwlk3n7m1vkW5FciP6fkyfPyDlGUvswbUZpKMc4n2TQX7jp15Mb+LVXLivf HI9PX9JKuT5Y4wqHP895Pi4SicPRpXv5Sk2hhm/LJ49W2XuG/kf3B/5zLpBwo6xEZZL2Fpj0ylrf LIDLXaFcUS6ZuLc/LpjOZJJXaezZpQtcymrDKUPJHKz7Fnbk/kVNF+Qyiqn/AMCbDEom4pu7Eb/F 1cTBs5ueFBCwOLtUOYtDst1ikXp1lLU+rj3kN5dU7Ez6/d1x1uLAOeoByI5/B15JYmefd0ct+076 NqppJxVIFvCck4veNEH5JgS9fKIbE9S9Q1QB8iiWewd72w5jWuTg0xVlmUbmMEicgZuItnFUh9IQ yPjtfeX4+8SmCcqxd9kkNmPH69NNojFNW1Bx7xi/62/h6HyZhrmKOPUqhSBDoTJ5zG5LqlDMyzGW zjj6AuCfi3ghscnZSZqnHH8oe4/yK60laJtO5fD4bJGri16hEnV8Hveh+K7dgm0xaDaU3cCPYTlD c+c3K9mnk5kKj2Ny/wCjc5ovNJzW+6ljbyN/n3tYUaNfD3uC3Ma7lSRcuzSRTDXy5yNx4/zkb+6n ijlJ5mEh5p5SceOUci5emznK2OXc7MEok/L0wfJn/wCt8l8bPPKnMsmg86f+WeauLl8m5F9wrWyx WTOUybqOTuSjagG/xP8Af2txL9uTxhslzYysrZHmzvAOYtBtAavfsCPZX6ztjrzjH/z3TjLlz0xo RzSKPqiRctQ1iJG40tl3JvI3+e8GcAQTkDj2DcJQDjrf7T9mlM3+7JW3a+KXDSrTe4PlLWPGnNTG T/1P3G+2XZpSSHZu1EH2r7NSTd7rFbbp4ictC1JzR7sv865Y/wAl9un+L/A5Ow+Ldray7ZM+7l3q DQZ2f5UrZ3JbMUzaOiZN2LW9aXPZomSv9lvmKItPEhVNrwzTHSsStr/ocFCuWtiE55mhBQ8znQmR yCWA16n56Utbb6pRfmPD6oa3T1UhPpWShGjTEfk+13Vv+lEuJMEZlC6XYbnN80NqkZMiKqLJkZlf dB0oNo15gVftbdWvcSTsn4YvXEgqzqIRLE5onAlCVRGGv9Q0P7SV/YeMYDo40iVTTg9K9yVg4JOa SPnGqZ75I9wc+4zeeOeAYIeBccTvhNDJ5Cx8GOmyTTjhBHIpIycC7VEjkPGCaQcj8pccJ+T4/KI7 rk8W4/iGqBQ/4nJ8XZD+0akzHsSu6+MGXvcgje153K4uCqnCHpnIY8xEY6PFhMfXFTaXJ3ZNjku9 JaNiZgi2pk3OcQTOjsnh6tv1mhCYqB2i6xbsdGQXBrPE94blDb57v6D0F0O8I1uQN7OCBeuh35jx 6ZD8U0TVZySPGkOrVCkmh0SwtGkdO+uNZVkHY3adSjU4wxSBgiT+YzJEdKDZ29fFPHGp/wC9MTKv lUr2q9EZ2vslbTuMuctLlO1B9CZqcpDo3Nr26Or0jme5XpO9P7ayvMmkLMOuSSPXtkL8ZgOM7ddS dvUuz6LfJHBasY5a5OypwUP/AKrJPXBcQrm7uDwufnhPp1yKRqF4S5wMgZF6hybu5lT1ujqhlmT9 urfyC8KSukpeTtDC+rl6zfKJWDjv5B1J0ZJho2x9ZNvKIsmzs1OCXkEiwrG7ndtXjxDKlSXUpTlj LIVMpYGpWsVIUq0zk0t7vrTsraiMysepqTpowxpdPpRi06RZ20acG5A7pjMTQc6BtSNhNLW3p3BK xNSJU4xtmdlW6Os2/arYWlcsPGGBapMwNyTcZgaDpkzaiSHv3Lu0Nz8g2R9m2rPRcdHXuiEe3n1N yLSs9NMouO6LMm/Xsa0G1s9Pswp9UIjOmvS7MKJtbETSm/gRKHbN9vwuPb0COR8MduspB8R//9oA CAECAAEFAv7UICFWEe38u5tesTfEbh27D4MegbV+/acqRxNWS9NWraTcTwwfPZ9QF+kCluAl6YFC iABa6XPjY2GeHUShYhcjAUg0BQtgFykvVvp1fcAbL2AaEoWMUDHKXpYoBiUaxKIYkAcC3L9vgSFp 2V2pEm8jUJC0JRChD8ZT4b/nMPMA4ZEN0MNZANFMGQ0OIlMICfMLmHoQbGIIAYpvpEaMcKOIDRBA DUUQsIlApjfXsr6TAAlq5SgIgJ8g8wLeCHprWlsr8zzAL8iGpz+kf4wBtQjfxBfrI6pxMlROHkgV RoEmxboJSjSba4eGALmxLbHoUtwAl6wGhC1YdMBopbgJKEtqwEa8saDX1KS9FLccBsBbhgNAQax6 Y3DCgJQBesRrEfCB0rWYNpVjOcg/hLLtrSbUbYICbwwDYcrgB7FKa1ZUB7UY2VZVl0A1gzox8qA9 gzvWfUDWoBsOdX6eZQbLUJrgB7BnWdFNjXmDbMbeEAbURQFefqrZvE3iCWyxKNAQLa6EC0IAADrq xRMUpTViWilyrywobFoSgFGIAUGOHlgFWAAAoViW2AXMFh7lTtHSOpVuGhW7DVsUbfL1bjHMO9Rm K0Cl/KAdJlVqMq2azlW5Vq2eYH8B8qzNWQ0A0AiFXEaE16zNWZqyGgG1ZDQjerjbIRoDCFZDWQhW RquNZDVx7rZrJuIOnUJvxdNCl0jWBAN5GrMU+oa8sgk8nVYEmgK/H1Yk1k1B/Tf/2gAIAQMAAQUC /tV71cA8DkHjdZDbdjZDWhvS7pHBtInTw5/FxblTWq8OToI9REaA3XIRow3rrYt7lyxy6X6mGwXM FCPXIbCa1X+rZ9oiS1xCgEbgNiiNXERyGriA5GEMjWN93gTmrjpgJuLJnozu4gc1AYDVq2GfmHw+ I4CXoYvUArG1GDpQXAQAcMRsAdThcDAIgIdQCilGiAIUcLhQgN+oiUv0krqA2NXURABxsOHXwQdd kT3+ZGtyY6Tcb5nLUH1Cf+NEL18vEG+g/HjqTS7y2F/tT72N40bEUVeFVJHLS2xPwwjYMjXy6mNY RPaswoBvWfXOhNYQPQGvWYBWYUJ6Ma1CawZBQmsOQVlWXXLrnQnoRtWVZeEEL0PmJ9jByFo3h6nj vly+daFukmWPhh6hbqJbiYt6EtCS9FLasax6iFxwopbUJLjhasOgloQuGNW6+XQkvQBYcLjjWNGL lWHXDr4QQvRk415G2tegC+IP9uRgoTjfZQCagERED1cwAJjBWRqMbGvMGguasqAwjQ5ZZiNXERyG sjXzGwDcO5Y23W7anGPNeutUUb9IomRvKvc2xMmT6mVj/E1RQ+5QZg2kdU8czMnjiBcl3xQycXJv KhP/AAOIViFWoQAasAUBbViWsC1iFCADWIUAWqwXxAKEoDWIViFYlrEKxCrB3SBwWNaorq4kT+on bIkgddRTrFGxP+4cfxNb25azlXKiLf2rj5p5I87K/dOH5CxapX7f6b//2gAIAQICBj8C+lVqs+Xb 8zYrttvasxuXS0keaeVVj3lPV95T9azwu7RxCy4ssxuTxTF3RBvXBBW3ovcE4TJg7rMUNxRdZtlt yMvZWaKbFkSU8k/sp4prVlxUuxOUNPDmhm85vVh2CUfyql/f2h8ESVluV7p8zIurEN4T4I7ir3Tl WpnZXuvCmFyt2ZSsoWYLKFbYQsvsphaSgcE+CPYuSNWV1iEx5TsY+VQp+1m/ZrhOe0ZcV1RfG/ud dKr+X9SsnF+9ZYnNPcFGcvLGA+s9nZOTinXNc9nBDeuCdWb9nLZbvQdNsdWpsU+zkrdyfs5pztWb SDw+tN05v3Lr6nz4BWXdndNxTLmubrns4MmwTI96xTcVaLE/FB8E64ptrJlyZXWtsZNb2VwvHsaN 3aA6A4lWo9yc+pcwm4pgsWWNy4rhsfBcVbvVqtQHtFY3I7vm4VCfdOx9Fnr+tRhU/MDyl+FnH/Ie hNCIE80N90i2Mfs4h1UnTj4YiVr4xfBrn/2XTqBpZQb3vf8AcmAH52W/7j7ufq7w4iKhMhbJh4bD b/oo1wPATbwtbnb6rUKn/XmlzEYkv6lmqhodN7+MQLWDX9yyxETVcCyTi1ze3A4IuGlEsf2G2yxW /JsXdsbDZZsZN8706geCM28Ugx7kQxtbE4WjFFxfxONnp43rOPMzcguo3id8b2a665M2JN5F99t6 6R8jMoxbwxu9DfUrsGvJs5lZLW7y/pd1lhd9Dv/aAAgBAwIGPwL/AAZFKkM1WRYAL+4/+mrR/A7R HAm+R4R9a6Wn+HCpAY9OH83i9KyaCUtDrzcJeQn0kegjuKlpNXHLVHoI3jeO0cCs2DphemKcMyBF y4oqxcUxTp8EwXHY2yy9Ae0mlsACaK+8mknWbBDsTBVPjOquicsP5j9npU5QJ/RwkRTGDb++V/qT EbKlCv4viGhGaEsTS9qJ/D+7tDYoAJ1cyZnVmzgmxQ3q5WbHvVytVt6s2OE5TFOrLk+Kcpk2KHYu ao6Gh5zKoJd5mfsZT01UNVhIxPeNjjzLV6uX5A0xie82/wAv0GzYL+3Vj4KtsPxNdzCPxL4bljrv aibBPi+EvUeCy1dNXDfdJHIhwV1K1M0NLEOZ1PCwHC8/5tVXSUT/AFFfUSiN+XLDMfs59ndMNyZc ly2cdrK3ds57LFYn22J8E2zmrN/aI16BMZxLgjAi5Ch/6EyFT+OPlP4h+5+4LONZp8jfxj6r0fhv whzQPnndm4Rxbecbl4r+zsn4J1yXJly2cXT4p0O7Y/BWG1NwRbFMuCfa6dc1wfY6fsrFeDY8rT2g sieCsQ7031rkVyTlcVheuC47GxXBWblYrE+AWF6G/wCb1WihB/ifTjOiXPszAnFri8JZrQWyWYqt qtDEy0VXpUdP5j76VWVOZveR9zUllt/MjZcjV1Vec9L0dT5Y0yRUoUs/sV5RIALgZxIyGSYg7jRa bW1jLUV6mnkaWQ5TTrShZ1RNxI05OWiwuzuo63RVZVdPKtUpl4ZDGUBA2eKWaLTDSsO+IQq1J1nP wrryOTyy/VRp5ogVfFZmhkLRZpu5aFXpTrVNFTpUZvTompUkK8c8PdCVlj5nmwa8uFW+EVJtqqdI zh4T7xodQRYsYSlDAuRPwNa6q6EGMviHQ0xtBHTqV61KGSyTWRqDMZRLF45XGZGj8Nqyraz9bCnm NMxaIpV6k8sBOed+m8bBMszB0K1adal8P6M6kjUoGnVHTlCBHRM7XNSGU9Ri5cjKVTNKfU01akKk JNlOUmUfFF5MRKMh5jvf9hvstVnybV37Hx2W7HT/ADsdboJ9PUxdjYbwxvcXFUtLCrIUKFXqwFnh qfxA34b7FGUZwjkMyAKVGMXqRyzzREBGWaIY5gVTjCpH3UomJ6dPMMks8Rmy5sgkHEHyfdQ0s5e4 FSVRrPPMREjvtEY8N2K/Q5/6bpmn5YPkMxUy5suds4cB7MLys+cF6UKZEoQnExpgRgDCUTA5QLCQ +LuSh8QhLLq4zEwQAGkLRYBl5M3BVq/VPW1BeobHJExUB+744g+FrmuQ96ItUFTw06cPGBKOY5ID MSJSEsz5n8ToaqMqcagiY+GlSjAg3iVOMBCQOOaJddfVSzTYC4RAAuEYxAjEcAAPod//2gAIAQEB Bj8C/o2v2f0Av1NPt4mPs/oGo/5PhPH2F/D/AKPt/wADfd+uxzjFalAbWsOdBBYDJGZTPoIjHDm4 LL4/LrrGK7B0LSrMJM43ALOmU7JIY5a+vFWll83jcbbv6dpWuW0ofY3M6QypZlBHEtnb/X+swzmB Ed5EU8ogR1mZn7ojheQxF6tkaLZMV26bRegyUcrZAsCZGZAxmJ+/9Td9nr/V/wCr9Wb+Xv1cbSEw XNm44EJhjOQBLDmB3F8OAq1PLfHnWGzAqSOVpwbSmYGAVBNHqMKZ5DHOf0xfw9+rkqcma4s03A9M sXyMOoEyO4J9f16GPv5KnTu5U5Vjath4LfeZBAEhWWU7mlBNGOX28cuNGf8Axf6eOX9AdYuW010V 1k17WHoClhG4zYXoMDHE4H6b0DYRyQBkCR1bj4HXc9KHaV6VaP43a8vXbx3F3ztuOcfumvGWyJ7Z 05RI01xVGNf4dY46+crVvN8CnnafQLXKVkxpuaP5KXnARznetkfaQ+vCMxhrMWKjtYmJ9rq7h06l eyrWZU9evOP8caxMT/QNONP1s3/5Rkv/ALN3HjFuy2YwX1Iq5DFSRclpzuHydhNIeXxmDAB19ZtF 9nH9/epM4ZXneG8O8e+K30sf1rL7C5nnsY3a2PvsFHw4xXhnjI4UfIcnTZk35LyOyVfC4jFgbUw5 3RYD7FpzlFABH2RrExPK94n5qzx1l6vhneQUc74xZbYxF/HViOLanKabXVL1UVkcxM6SIzyj2ydj yzx+PAqWAWVpmP8AH87kXh5NladNjVmxhJsjVpWbHSnpBPLX13DpJfSzyPAV8QGCyWewz8cu8Vuc inzFNzI1nUbpKNaDwqJRAyQCLSKJmOWnAnfXhx8q+XOklVZtfJPmvTZ24xLGTb7KW7d3u36a8fUz u0+PRjz8k8iLyokTe7pWc25CdmE3tlc43u/+13M2fHXhN/xWj4svD4SM3ee3NvuuyGWivZt27I0K 1TpV66lDqH5zAMzHlMRx4Q3D0McPlHnKrE1VZW0SMJiox0kvJXr74IHzVBgT0wiYIo156xoWO8S8 wd4vkSzyLTMHmvFLLTrzZpLh1jH5Gq82GlsrnUDjQZ5RzmZ25DyHFJpPu1X0FrVkFvbVmLVxNdm8 K9iq2ZgGctDjnxhPI85iPE1+LZXI4+g7F1LF+xnaS78EwTsWS6dKbPTCf7Lqhry0/e4ueHeJM8cp WcTVr281mfKLDF0kFbBbqtCihDAY+ySWRJFOsRGvpMa8eXL7Lx53lvhfy+5cioy1fwOXwts1wy/j iTaS9R11M3GJsnZ9muoj4hYw9StfpZmnW8gzROFzG0fGHvx6BsohLk7HuO7MCRCYxIcx4x3h+KXQ fjF+PtzueuGD2WEgwiTj00mrsLrjLGmoi3Azcs+WnFn/AM2xf/enxZxnj2LxtryexUQjFrwnitrH 5H5oUAKz7r5XShoQ38Y7yk49InjwHwbHY+vkfP8ALYKu60eYYyKWIqVkyDLOTJJw5zghRDOhczXP 4imBKr4T9QKOHG9l6b7mBzPj5Wfl13tQY6zUau5o0XqWsuegeke2d0Fx4/nKlanaw4eYWKnkvXTY ZarYy3ZUvvKRpspUtiz9nvFkSbA5evHhXjfja8fcyXlF0m2DuA+wipgKy+rcvANa1VLqyvUlTMyM 9Mo09OM54/8ATylgFVfGGjUy+c8lK7KG5Itd1KiqhvPVMgUFMgf4ee327vHcG7xvFT9RPJbt+pSo pusfhVVMfOrczZmDh60Gqd4p6sl04kpOJjp8Yfxb6h0sEY+SQ8cJnPHCt9n3lcd50Lar21u8twxE wI8zH8XORznlGKxXhteh43YypXXWpyfWv1sWmLLk0qI2m7Tr1+bCY4OproERMTrjfqFXwfjFfxRn YxYx1i3es5ux3JjXbZBiujUr1Stain8bRiYIxmNYj6KWFLk1Tlc6fpEyO+th7ATI859oJktfSNP0 8v8AJ8OP4Z/9Pj+2mqktNP7Yo9Zmf9nH+L14x/iynGvuVjkMmlX4jCT0oVmT9kmBGQ/cPFWtVSb8 zcUp+VtctTsGO/tQLZLOhU3bRiOWus+s8dJ2OfOnp7p36f8AV6Ws8uJhZSLB/GlkbWD/AO78Y4xd +jpV8c8/czGZWkPtq1PIVj1KN5K49iyuyUjMR8ZOfs0y2buC46mHxt7K2griJ2Dr4+q224UAw1AT iWmdsSQxM/GON6vHfqC0P414TEGPL19w+QzHLgsHi3ZLFZvaZpxPkFRVC3bFcbj7SU2rlZxgHu2d Tqbee3SJ/T499ObVbKnnPJce3JULCK9UsWtCYyMkNp53V2Vt/wB2M5Ck45jz+z9l9/62UrIHe+xj rqEhqI72trMWsdxyIjuMvWZ04qeMW8f2vl2HyNvL4ut3lAi7j5hYOExdTaKoHd0bBafmxEHtkvw8 fTjxrx+gF6x4/wCQY7KZsgs060b5B7snc33LCOsPdvmBEZI9mkRGkcYjzbF+O4rzCKmPnEZjxbKH WR3lSGuei5RsXNawXEE+Y589IiIgtZjjLOyP0r8f8FpuxjsfSbWtULeeZN9Nipkd00EQhFVtR22I mROJj96C9jPHbf0d8a87ch1gcV5b32HohbrNYbFFmEXQO2DasHpPpuGNsTOm8vCh8X8cxK8n4x5F ivIrnjWJeupRNyway+rHveKAke9Zr7ogpCZnnMaTSuZjEzgslYXJ2sSVxOQmkXUOBXNyvApfquIL WIj100148/x7PG4t4Dy3O5rOJ8kVlKa11AtLvPrVyoMnuHtY94JL8GydS9wc+Lfi+SodtnGY7ydA Ue6pO1bkJvdmPcosNpx1esP+00HXnpx9O7c4PGZLyHw5eSRk/FMs+kypl6GQu2GzWi5DXY8LKRPc uZLZEnu13BAym/Y+kPj3hdKihjUXzt463mZyW9cJKmGPRtSkF74LftmdYmJ5bZyeGwVTvslYsY00 1+vVrbxr30ObPWuOroHasJnmXPjDYrC0e8v1c1hLb0dzTr7K9RFgLDOrbsISXTI45QUzPw4yHl9L w3FefYvPVay8jhbjaVW/jL9RKq4XaDb8Ek1PWqN4x7pmZ1iNInjPRlvAcF4Z83rvxQVMa6ravtxF qvAWF5J1VMVtxN9wwM+nKRiR1Lymp5soRbawMeGYQ+vUsbMGJW3y9c1mvlYzaaswg9pjK+ccZzMe ZIhWcvxiMTX1sVLTIxGDx6qlY+rSc9UQ+IGCiZ3zKdxRz5uxOBp99kCyFB41+4q1dVJYUsLq3H10 +2J/i14q6VUKeuuoCkFKghKFQJxvCOMD9QPEatbLZPEUnYnI4Oy8Kk5PFONzdKttswpVhJ2Tnn8d PxabCxPmnluFR4tj/GadxGFwnfpyl2xbvrNFi3ZsV4ABUIlrGsBOojoPqU3/AAzyulFCxkCy4MVL 6lvoja0mraFlN9hG9LIhg+7lI8+L/l+ccFssPj6nguAaM71RRxIjNtqDmNWAUyECz96SZx5RlPGP G0eY4Dy2783dSDKVsRkMXlTIysTLLINh6Hm4p9oF8PwaTv8AE/PAxWGrebeMW8pu8dVe6la/hcjB JipN5hdsrJKrGYToyVFv3wUTovjxvyDyrx5HiGD8QZYuUsYWSr5bIZLKOEIFpPrCoFV0kkC9wD+H T3btR838cv43oZnL/wB7/l1PvKDe4+aYqK1H+YTaZVV13cveY7f3tI4x/iFfGdTyJFfFA3Hd5jx2 lWyQWHR3Z2xozsVGvJnP4ceA/L/GMVl69SwYZbKXmri348k6qEtfjfzR0a1W/WRhm/ZAaRu3fq/b H2Tx9n9f7RgHziLdktPt6RnIx/mji6OhFADhGDE/vgNGoW0f9TfBa/fxTu05Fy7tZFkLHKZYD1iw ZifgOhenFVkfik9v+SYmP+njuq35d6vHUUwfU9vOVH/FBRx4JSrz/vK55PVvgoJ/MV2UFVPSPWN1 i5G37dOPO/8Ak3yf/gl3jDix6QL5rnfabQGf/wAi34TOvH0qT4eVZ31BDO1O/diyA3LqjfoljgyZ 15/tFELi0P3Cjdu9unGU8C+jeBxmWuYCZV5H5RnWMHCYyzBEE1lCli5YYNWQa6nJmJQK5gZPjD4f 604LCLwnkFmKdDzLxhlj5fVtmURCsgl8nMAETqXJRwGpRviJ0+ksjMc/Er22fWOYeXaT98ceceHe WY7GYnybw7IdLo4zuYRex/VZXm4A2n2GaC0QnXXTY4OPG6njuNp5nynyrNLxmLxl3rdI1RAi9u2s 5LpPubCFjziPzPu4Z9N/pfgMVnPKsTUUXlufyDHq8awdzph3KEj1AazpWC2+4yLd7IA5gpjC4Tz3 w3EeQYjP2e1DP+FE3biGbZYbciFtoiNZKhki3wrWInYRlGych9Pfo7gcdmcpg4mPJPJc21gYPDug tk1hhRqlrVtiQmdSmTghFZbZKMRR+tOBwX93c7bilV8x8WZY7OhbZzgMgh5EXTAPcXtUeyCIeptm OPE/E/G/GKnlUeTYo7SawNevI2LrHXK9RVWwLe0VV3qA2GYFovdOscYXL/U7x/xW14fm7/YujxYr LL+JawScKIY+xo60CQKRGYJbemUb4nSeLH1CX4f4rjfD6gDePxu++zY8oXhyONtrIEpykpb0Tg2C HvVHqHKePFPKcQGLV4vnMP3uQr2ptzm6t0wKARUar+RcpFkZW3eIz7ZmJ+H6NY/Y6/qF/wBaf+n9 fdHrHr+v8oy3d9nL1WCinabUYRqg4ESYrmSp38x9OKmHw9UKWOpL6deuEmW2JKTMiNhGxjGGUkRF MkUzz/a/6eOfL9kF+ImUNZvnT7TjRwT986zMcK8npRDYqrWi5Ic9a5VVSl3/AMo5mJ+zXgMF5DDn 4UJns7ao6j8ZumSNRL/E+nJTrpHuD4axyhb6fkOJOpWHfq26mscnP2psklwafeMcbE5JOcyJzC6+ Ow7QtkxxTtAWWlyVWuO711LdH8M8Uc3eVPyrx7HovM1ie3i9Nm72NJOvLdDfzS+4OfrHHnf/ACb5 P/wS9xj/ACXOsz45GxeyldkUMmFatsqXDSraqajZidg8+fOeHZHxzFsLNGlqgzGVsnkLyRYMwQ15 OARV366FKwEijlMzHH1Fwt2RHyal5pZZmFM9tolkoaymEM++Vxcr2I+4v6+GUrUgWQyGexC8Mj1e dtLia80BzKdlGGDMx/Hp8Y4+gVe/u75H02rpubtd3dKxvkwWN0zz3dWJ148E+qiI6WF8pMPD/Ljj ksTYAor23/f2kAyP/A8ZnyEv5jxn6S1Bw+MnXdXb5CZPWTR09hku3Ng90f8AYK+HH1lw2R0X5Svz J1u+DeVl9LuL6lsHWIJilWyZMz6R1h/ijhSzapbbBEuuJmIk5grJsioJmJaQrCSmI/diePqthr8w HlNbzV78qpsbLbK/51dTJgp6hgF5djX+GWf63GRrXenNu/lcOjEKmY6x3l3BeZIH8Uyuktu7T92f v4//AJrrZHfGQr+BUkXYZr1ItLxuTB8HrpO+GROvGG/52wf/AHGQ485/5Oyv/Dz48E/8DkP+N5P9 OsfqZfIohZPx+Lv3Ui2ClRNq1GvWLIAgOQkw56TE6fHixjMZhxbajx7FZao58pGmyxdcwXdWfmK3 DS2jsHl1IYs9Ykdu5+ITTyFhlRlZV20haCq0220jYQL4myNyRJLBmTBRLHXmUcPprxjLKEeL5jPT Y1Ts6uO6cgJ621nFaPws0CT3sDby3THTdjsnbYrCVs9dZjk12VqtBxWAY4ysW6zNElVKZiBktvpE 89L52K+RodjVp3dlyuAsvVMg5lai6kpL3sPurK+mIHAM3zESMcWq01LuOu04Qb6OQBAvFFrqdtYE qti3Wal0pOIkWTMEExOk8ZkLOMsDSpZWMDjadesl2TyeU7ZVsoU/5t2+2K29kialgCtpS3XcApiM dmDu2MhYxk4oKqJyNe7XpzfNVgJtxXgSraFBiwl7SiddusxjcarGtem7jMtdOz+RtWyhFeRHnbA9 iYZ+d7J/GGzd79MeeUqWsY61gfnU2npBWNsrrV6zckdKYtWLMKrTYgo6gjMr0mNfXgas08hQc6rN 6mOQSlffUoJYHYr9GxY06ZODcDOm0d8ajw5dkbS2IzVPBmHTVM9a9WVcVbHR/OhFVkmRfiiAL28u LVWtjsxkbFJ1xdhdGtXZIJonCX3fzLiomt3UGkY/tTYo9AnTXjIniKtm86rhUZldya8TiQTdRZdS K0zuUWI6vb6bIjfMlH2HI5ldGhev28TjXWrD1VwZjqFiah2Ka8gU2q9ghOIEjhMHIrnWZGOfGJyF egdw8jfxFViU9L8uMg1QshfWs1/zDgtqtZ29SY3aDx201ch0IvBi2ZToK+WqyRlCopG2LEv6kWCh UlC5VDJ27uMTTVQfkF5CrlnMTTWB3d9Ccd0uj1rNavC9to9+6efLTnymm2lVyOTm5jwyvRopSTq9 A52w+wL7FcYmTghgAk2EQztGdOE3gp5O9j2UQyTMhSrAdWtQZG6LDic5BlouJKQWLGCMayPpxOHR VvWGhXrWnXEqVOPQi4Fk0E2xLxL8zttIiBmZko01jdIppvo5KFOtVaUZKK4fLht3dsVkSwnDYPqG YjuBZLE50konXjo/L8sKPnLMBOQKvW7EciFw6IL3RcmwS3WB0EhXMRrG7bxXVj8fbco/Icfg25Ry A+WSbskqleWgxtBaJydTETlfR6g+s+k1KXa3btq4uw8EUVpMxr1ZTD3lDn198BLx9i97S15DPEo7 e9NUcgOKPKwpXy1eSJgoimR9fut3clCt/S6UM9u7XiEdtf7YsgWKDLSpXy08kBkkqgl3Hd69wEq3 9LpSz27tf2nPnx9nHL9YltCDAvUS9P8A28Q9PvpWI6LlOGHLgpiY6bBKNpKavlz9eG3PH8kidSI5 wV5vakGus7aNs/ybK9fQWSBxHxLiVs8eyYQM7d/bHKf8Tx1TI/frpwGSy+wHBzrVBmGks5/2jJHU CZH7sRrEevCK8hsayZsPH4wxkRpBfaQrGInjN4I3FWDNYjJYk7ABDDQORpupk4QKYEyVDtYiZ56c VPFK2SblVVbN2zFx9cKpnN15PkeiDGjEBJaev6J848P8nyv0/wDMWhsu5LEALqeUjQY1yFCW14Yw 4AYOd+w9NSAi58Y/y76keZ5X6jZnETDMRWv110cLjXiUMF68ctrlsYto7x06YbtJISmI48S+ox5V 9ex4pQuUF4saqzTdi2F8JYyzLRYqQ76eUDP4ePK/HS8hx+TzyLi6WPxePdD8knyOlaDp6KiNRUid wtZ+HbuGJ3cuMTTuplObzMlns5DI/PC5fAJVVdr7upTpAtZR8GQXCvNvGfIcp4H5stcKbnMNEMXk VCEKEclS6teHl0hgN2+NwREHB6RpiPLPqJ9Rc95xkcA4bOFpwv5LjaNoCEof0alk9+sj7hDpQz0P ePLgfOPFPJMr4B5p04Vay+GGGoya4EQ/3jR6teHMlYQMlv0MYjeJ6Rxj/K/qb5vlfqNksPMMxNC7 VVQwdF8FBw75etr1ukWDBaRCgkojfB6Rx4h9RTy761jxKo6qrFhVWxN2Hd772WSaJp0734DP4eKm Bs5V+ICrmaWYiyisu0ZlTB4QiVsaqIE+v668tOM14uy0dRWZxNnEnbWsWsQNlEolwqIhEyGJ1014 wniKLzMkrCpekLrkjXY/r3LNyZJIGwQ2zY09Z9P1NY/Tk8Z1eh8xx9yj1tnU6Pd12V+r09y+p0+p rpujX7eK2TVdHprwlTC2ax1dSeFJllyHqfFiO3nqWp3RsPWIjnHFXLFcrLipaqWVyvFrHKiNXnNI cuuws5x9oteotimTMFMRMcE6vkRok7B5fAWepS7yGVMrCZkl/wA3V6TUNRE6+7dHLl68ZT+dlfzH xNfi0fy+/owHzH+dn84erM9//Z+38H4ufK3FizMqtYLFYaF9uBbDxN+xkUWy6hGt8E9gaqkdswHO Z3crJwGHh1jpCU4jBVsIrpqgtIYCnWWuIiLXUmaR+7EcW7dXJdtkT8iZ5FQszUFw02uxNfEWKj0S 8O8rPrrPdoSp98fEdZpZW1ke6yS8nayt58VBQu4djDMwiq6VQ85poqV9m3Umz7Z1/FrGOuquRVKi jJ1GAVbuIfVyg1ReIz3COg4e0jaXvjnPt4wdSzaJqMT45f8AHXCKelN1WQp46k18F1T7aYXRn2+/ 8fry59bTDGQVu1U2h49TxVqQ3DJMt21Ncyw04CNdvSXPrt14t5JtkhXcwjsUypC9R7lgPQvKQzqR pYRUtGuI2/HXXimWKzk1L4Y48dkbrseFvv4ZbsZA7Qpm0qatvvrjTgt7I9+hQWnGZxtW4SK+UwWK wityIadWMUF0BslMNXFkn93qUeznE8+fLOdhmYx9fyKp2+UQ3HBemWRR+Xi+q3uq0o3VRETGYPXT lIzz4qUFWu2dRsYu3VtGjuAh+Kel6pbWhyOqtkp0mN4+vrwSjyu7DPygZqzjuxGGOyEWAvsGLs2C 2Um5FcN6fTIv3d+nGMynW2/La2TrwjZr1fmM0ff1N8bOj2fppO7d8NOeKEXY2zYx2KXiGNy2DRlK 70KYxy2pqtsrmnYBjj0mGHEwWhQWnG1Vmilc4YcOI2MOu12MCLo7rDim3RVjGt635kCJQUDEctOL t6LEs7yhh6PSle3p/KRuj1d++d3Xi36aRt2+s68vmveVueUxOT1fje4yKvlbKp9hVyXeq6GOsdtr K+kWjCkufpx23ez/APtX959/Q+Pzn5t2W3remn5fU1/1tv7vCUJzIqw9fPIz6seWNFjgcGSjKNqj e7tf8qyxJ7fytwbvUojSVI7qtXWEMgpdjQuPURyvbax1nuKzsfeTs9p6mPPmE6cHeCMU1LchOTZ3 mBp3Mr3Jn1mwrMNZuBR2Pf8A2RGGvtKOXHeqDDlX+YtyYw7x+m7LLe1pWOmrMkzcCFWS3L/J6oRE RB6R+39f1jQ8BYpkbTAvSY4I8a4GrmeSLBbGD90M0kDiPv040mqoI/iKyjb/AF+wiL/NwFq6wbdo OawGP5dJfxRu5tOPhM6afZ+w/vOvw3BhnOv3cXhqR7be7f3Y19e0G1v93UgN+7nrr+21j1/Rnn0X xWtV8Tfep8iZSvo12MOVdNqSB/TGemevsPQtC02znb8WqFsMV474zkLleyq70Wy6MoTRx6Rubabr Ij+Y0pZzAfbMfhyaaFBtlGHs16zaisFn79vImaK1qx2+QoJLHY+VpsxsFsHLJjWdozE8YCIflkqs eR1q9qMIy6vIPrljcqyUKjHzFpmrFjO2PiPA4mnFoQymQyL8LZ8vXdddRisbUx83O5RLq190tyFq Yr9VglC9ZnltjiuAEuvZDx3ydDK297MSWZxeex+NG3C4NZPr7wnbOu+FnI7tdeHXBrL7bD+N2Mrn 1xBS9OWUTg+UVylsCslFj7EnuE506fprw7MZEMRY6qcdNBFGLlfpWsnaRUUm2x7bMPrqO0Ek0IXM xE+zhtS4OFtXyq0LdKxWr3q9TpuzuMw9pFuuy5YdvH5lBLMWaTpzHlpM9yOFNFTyuj4zc6Fe8ttm b5Udtqt1LrQqRXDID7S63UkZ/Bxj7TxV8qb8wVeaUH1lPTj3XqPTOD2CDppsXOolqZhpp8Ui6hWj JVq5KzVcEXWjWydnNIw+LBS65vsdu2Oq+R2sYwBER0IuCr2GW6E4vJYy9GQRiMzg05ar+abaEU8s QviOorY73OCQKPSZ5Y3FSqp8yC7mFeQQAO6VWrifyxdWCXyS5yDLdUl7yPQDn104xzOwaWNysv2w vCZ1BYtYra2s+1l7KflN9bulAF0tmwzjSTjWeLlfEWqQLV4xj7hV8nFttSW/MswGqlos1xrueIRB O92gjHtL4FYxmNaYVaeMstoRhs7krF916inIMrVshjUFRx0rU+BAnCfULnMCPPi/TxwY1VPEsxyr o5FVsrVor1ZN1nQJDVhT6FV46SQN1ZExpEc+MxmUqx3yXC5K7QbVaFmclaHG2e1uOXaF41kMk4mV BKj3RpqUa8lVkxhBVdzvkGDqy2veliPk03GBbsSN2BfvRUmJWML1PnuGOXGEjopXkco3OLa5OLy2 WrJHBXSotNeNxxHfPuj2TGrIFcTOpTpGqbVuo2lZknLalqLNbWUOYmHrTcUm0CLIhDAgxgoEtJ/Z YHJtsyrBzdt0c0rpJLWLNB7cdZ6hh1V9C7VhftIYLr89eWmLx+VsKr5PHlms55P7aa9uBr4mtlMf XZJoFNZJHnqyZdEDP8sXu/FqCKGIqVr8ZPxSJi3byaq78bn8uWPHbN3x2naW1jE7CKEGsVs6qybp tnym9jMapFPEU/Jq6svOQWdtWVwdS6JvjEuoSltJeSqysZJskXrKts8WMXlMcqhdRjMZlVlXv98u zTyLLqAJk9nT7ayDaBblx1BjWNDnhtdVXGlCvqBHj9dAXpHu6U+JWMr21tzcQc1Qh3SfLl72bty4 GRGJZQl9bG0cpcv53HnXy2eTjMTXb45dmjkZnMupFLYJ0h0YGvvZv5wMQUxi/JE1d+PuX69K+fdL mMcDL54p9wWqFqb1arkRiJIZESTMtidI0nHZWVORh5y3lCJJLK7/AJnjPH8Fmbp39jKnUAW28UfR BbB3DAnJyJbOFWc5Qr43Gf3Yu5MKaMnXuRYttzPjmOx02r1ijQigSiycgz3EgYZu3Ft5HVq1Mbfz HzKhja6cVn05HDPPJVb91LCzaqQkkVV8VY6ozWlgyEaCW8Z4vDYqRRvYvItxeQrBY7tIWV161uCr WujXmwhtW4somVrLnpIxMf4BfUsrh1a0ltd6y12tS4JW1ZaaToYFMcXKnaGaMhSRj7kNuXnG+pWm zKFE9tk3xK+7PQoKD5+vKNO/dXZ3M9Hqym5drKs9vOqO9rVrCq17o6e3rAekcUzsq6pULY3qk72D 0rQJcgW6AYweirBxoWo8/TXThS76JZ0GdVDFPs1LCGbZCSTaptRZVuCdC2lG6PXiuyjWXWdToPxt M46pAmtYamwwCV1YF2+xXEyIvfM6+7nPF4Wkq5ayt21fyb4qhWVZfa5EI1t7tiBVEDAkZz6zMzMz xarKo7q9xEVXpsWbdtXbDukayQtvcNZASXIF7BifThyxpmyHnTJp2bt+28ooWQt1F9zatOsChNlc FC4KF/bHDd1WJ6+Vr5pv5r/dk6na9C1yZ7ZDsl+2PZO3nHOde0yFcLVfqpf0jkx/NrsFyi1WQF7T H+qY5TynjKmdFRFm+3+aSUsnuu0X0q0zG/RRJH0kNs7vd+LnwwKov/NODadm5cvvMhGAHdYvWLL5 gQjSI3aRxcyqawhkMguuq5Z3MknLqjsQO2SlYbR5e2I3aRrrpHE3KyDU3c4xDu7pVVHY1l516B2C o1jbrO6VrGZ147y9WYyzNUKRMVeyFXfUWxzYrMGpaQDEyywUkJRMF8ddI4W4qkrJSUV9tazcppZX q/8A06LNao9Ne2pH7otE4iOXA37FWStD0Yk12bdcXRXPqV4tprvUi7CTnUeqJ6cFffR3PNy3uGLV 0Kj7KdvTs2MeuwOPsWB2x7zURco4Q0K0bq9+/k67Oo+ZG7kxsDdbOrNJlw2j9s6hGvtiNI0TT7Yg TXs2bdeUWrlexXsW3OfZYi4h67aesywesCcRpOnppHCTrrICr1jqK/PsHEIY0XsghY0hYw2hrLC1 Z9/Of2TsXlqo3KNiVE1BG1e6UOB6p3pNbR2tXE8p5+k8uL99tBLLWUx0YnIMOWENrHRvjtWJk+js mGTE6DElHKfSOLCzq23dyqgljbGZzVm0K8XaO5j4r3H5BlupNSyySCVGExxbNlJs9+m0m2mMjkwq u72odG24qYXRqRdfVYQlYgIfOuu/Xg8gtO22yjVxpN3tn+SpNsurJ2ScrjpsuMnWI3Tu5zOkaTlu 0LvpvKyUnFu7CO/TQbjAudlFjsuv2LiWRdP3xpu1kRmBXNVqtl+/k1vqX8jSuKu5Swy1kGpv07aL qRtubMkAshfpGmkRHDMM1HWxzqjKTUOa9ssrNCVsBj2MKyZGJfjk9+vPXXjF05oKmrhVkrG1ylhK QpmOfimLIJOYsgePtGuYbv13a/i58M0x7W9SizGaW8llbwhQY6tY7ZA3brxrLW+msl9Pb0pH2beD oMVbeg3Ks77eWy9y6qwiNEOrZK1ebkajEx+CVNCR+Hrx2tBPRVLWOOTa+y9z2zqx9m1ZY6zZez4m wyKft/wFymP6tf15/T6fr+k6T/m+zid+m347vTj2GJjP2FEzH9en9J//2gAIAQEDAT8h6nxHU6EY PQ6ktK729P8AUuD8B0JqV7zp9eh8Cv1A+gEHqDLQpiq7X/H3Op1OldalfBfau60dkgOPIvz2Phej Avo9X4TqdTqfATiHwbnqDJ/Xt0IvodCIPArpMNVeAjb6BHcjSODBrTMU6KiFXEhCnAyfE5emHLDO AFsyZc82L4ssCoPXGTP/AGRfwIyi8QiIUw5iuEA9zcByeIxA6JJ+8SCVIwvHw10BXUTNdLQXbPeX YUiZEdeiTV6QD8f2QQChHSZH4F+B6sVL+AqELl/IBttwIqSq4DbZk7cMyuikM7TnEYeZtFaoRMp2 4EGhhWIFgJyQUWYREUfAdT4L6kNF7PZiJWzqPeWQenOowL6QOGX6dNVw1igOG8qjjc5WA1S90ckV tCkKGjQkMAajFgEFrh16Qk2VDW0Erm7T1YDaEwwXwy8UYWMemTdQC0wghWVJj7klSs/VVyJSoGrV vOZSKG5lPknJolpyP+S2LjMswVgNSc5qCl2YiN/D6YwmiMDym1socHhrGIKsMPDVAzUThBmIypc9 pHMj1rS6YrH4njuNzDF9PuGjZFEvKdUi0lhI/ZY7OoUZMplmvLHeTSqQaEemorCK9IgBkSffoaxc yXssoULjkiqhzPRWLMQW7x9C3AEvKCAnfo4rXUNkAM9CkbcGSNSpmatU1bjKxXAtANFnyWalhoWo XlqYldE88crK9uJj30XT6cur1er0ueOqJCS3gbEMgLTLdd5oH5yvRF8otspB3RndgKkWG1l47tGw XVgexPuxGHVcnJcCfNCwEhSjBQgFFckQxZG1BDMIvCgpqoCRW4QnWDy+TlEVuYHRbhBFhYhVwgW9 SQep1GU7NPuduh8Hae1tOSgUByhBpnsGzTQS1/hpRrcDPWloiagpaIoavPKl0SZ+qjDeFEssnOQy AV8hWhQ3IN9FXdR6xASrRuihlucxjwZgElHfzOqkmlrH4O5CzSvdYiNjRpglD5mvnZ+4wNfPIOUK lbd5mj4y47U4rAtKLcTtouO2QJZSwZle9pNehoacIws+YVZqWR5ERxdJM+Za61sW1ACbktdliInW AxxLbBF6aGGzgYSBvxpmTkRRphE7+5IBW77MLIGnwdJubwcqwZszB/J/cDmYqQvWjgHIDJ1fKTsV HzDcW6OapKJITbEH0BZJcAMIRBAJ6EFhH+WoyAQ3l7E72xcu0i7qaWcS9yM7h1ogA6BHpXSnPmOH ZMXdu2H0dPxsuwe8rrmcPWcivA+0Tgho5fvxbtmUKCFaWt3xY1zmcA+4H5Y+sVckD1ToTXUXz4uB JyDrraUlOi3TUWnXWEEWMcDd+8BngxiK78ICHKcRnzVi+uEUxnsDGamrpqTnyYAkc/Ck2XhyQRQt opr6NXYYrb6VsbReRQKl4NQ6QJKgvOgXkZplxyDIMz3zUkfiFSmgVryTm+UNiltIyFTE5xuJPBUP IjFgIboFMQpfWEC6AJ6NUSxNM9pm64/eyyDEjtYJd3uTv59eh8A9BiunudyGbP8AnXD5XKXL6HWl xGHc7+p1NQh0crYrqhgQ7MmnYRiohKluPxRKV6XN/ATXwBc1jZ2yP7Jrl/qSmQieG/g4D3i9Doit 68ELaqs9+zNvbUFv5TnLbqXQN1uvyEM5daMQuNUZlxTpB4nki/WChaNRGwaTERVA0s/ENizws2UG s5PL01Pde+yHD06SxEOx9olTF3qRG83gzrfE80B06UpSit7J5wTdjRBHKZuPZFSq1Ch8oHc3BYBq W5rcE09ak4GnnmIlobDGSxigapZo4orQssLL6F7xzwAtxtnMpOM1z6DYPcJSOiR/FBr5ubnJQ8nZ 7RX8Fi/9+fs6D0F6jZVG3QraBzMEzsgdAFWri2wUoqxx6cBX7l0D+JiLCXObnomYddI11DqOjVaG cMMOPVmoQakZjYXY4ti0CcqihUvajitt8fLgor/Nt1IX+VMeygIqNbIQ5iX0Ca6WN5DyQGRRyHhl BTjU4PpRGM/WCJDJoj7/AKN84L2tqqqaka4a7znqYOu6JiDpmuTRaEZE+GVRqAAAV3ErOxlNDvA5 tHDHaXmbWypyV/LKoXDVMHeeHYMVuyjBGdWMb/HlC7DeHhhsxtodAJM/SGsyUVGxrADuunKKgz7L qsHqq0CnGHUUY5K6sSXzOvOxGauLA/bFHOhbbGxAmBsd5lYYZLR/CvpXXcTkKPhgf+D9oLu/V/ZG +x6xlSodAbfRLX7BwmSDeW7VQRqsC4I3cfU71K74GGNJ2OBAA8Sg8IkKtCDmoTvVLQ5LQHgCsxKv fluJVfsJPHLVBUWL03oVenUN76K6ReH0INHBiiRSxjI1sQMGiRYxKV3RiwGoyWxcw/vezFTt6jIr pwSTVwKS+oMUjHsnCHZAgEcZkumtHBBoUCJqVg7bRzQ4XJVUeM99+incVhD+9c0JQq7FundhBDBp oLrcyhhlRLMoeaSmBeYWask3qHZC4t1GW93k7+nnpc+QA+5hxqqbiwVEWql3l6YMqnulQuW/jES+ wdm6lHjo1qltcBgmZgezrDsw6N+XZ58it4AKQrsNDyZeUhuW2p5Vc1ou2xxICYbtkZXSitmLBSvy /W2mSoBYsJuFek6rNByT2dJKR4FWFaMsSUAsdiu6p8GhTVIdDpp1/PZ4yMwsLRmRs9Gro1bJuJqe FEfdupV9OH70wNqwwlOi9eMhPFh0mDb5qdlsSPrTBe4WHGNh+AQCICbNuC5O26rBsmgLoNOPecgN G/2JKDg1YHNHB18pMuCu4NjsypcMoXIr5K5Nhpmq7OlSuRPZ2+nhbVDlEViFpnyeuCOFdL6h8Pr1 9GBcvfMHyfP3nrHW46lYFq+4jkTI5I7Dihb+/Et9dzKoN8PRT/VHzAMQeg8IA4Wz138BARqxtRc2 XC+oPgGJL+O4XA/L1iKpKZbuahe6p/dHYlAIigKVz38m5UIQYrhWBbjNxP7ulyatXfogpiGOQN54 iUBjEtYBPLUJW0qpBNQWLdW0BiMeade2ISAwKgKcMK+9o06cQvYpg7jXl1zAXlKKl+C4iIwAjVcM iCDYn3MGoSmGLrZrgkaUbGuApI7uY6twsIMO7FSwXh6tpIrRC9ykSWokfYGgEcC8JPKUB/EbKN5I YzSE3cCh66qDX1N9w2ENgNtPCkmogMpYhG4nfJA2AwJqpB8lOiwScg9Bgy+hL6nOA2SazCTSmkk8 URmyR2FXa28GV4rCq8EIKnRobza1hmAVlyZhpzY286VgqrDpEY7CksCvRS8eaQIw08lLRIq0TE/u +FLoSuGpEW4e8AWQJfjKDRUC+Vp0mHwVe5b8rEOIgoAgK05afhbBNdLg9Lly4MuD0uXB6XBly+l9 Ll9bg9LhjPs8k36oKXwBIpGmWnie/NccaAGk2QAtQTdXIaGAwVLKR57nvV5XAg0XbUli30hJViZB /wAIdhHQT4L1Q8H7tteCWTJy8Ck0kvlLkgIQFkHvC3fdxMoo4eODGkqdhq3mLUEeQ0zK7LygWHGk eOhSslZS2Q1AkpJHPV09BCOeRGkYY0rHBDk6cR6cFzBF7Y0bJxvW45AQqAPWF1zKbYxLCsQb1thu qg5JxlYPnmAW0ctCXYQU6iMZdRXTCAzM6czcebQrqD7c5ONItEs3rZFwZfwEGHyrYcZnhmg2JEVp 8E7JX40KiAZQ6EkddbZNXQEE9izdgsGQHIuGjMO4BzOsXCAEXOKscbgiuFrEAJVkBcBzI6NHlJKO m8UVaLO6jUzjGhtrKDbYAwrFlq+s3+Z1ZXhN2UgXd6EKlLW+dbMiubgqEA0D+A6n8Rf8OerVN1XN 6hMu9D7fDmX4gEXFjlweN+ehfF34hyL1r4DqBFmJQUXJ7QIM/FgeGWqb1LHpL0KK+/wjnUt7TPmZ 89CEz8HEz0Znpnr/AP/aAAgBAgMBPyH+Aj8R1f4GHxv8d/DfwX/mkehH+Nh8VXNKqBrGPjRVYPwH wiVbRLKuoSsHpUr4BCzR/h5OAm5dF7LfXsHl+0Cvdr+jEMUD2mn4fswE9v7eH/H1esNgf6YPdjBS 2naHtVdUyx75xFLmH2jxXOpu6K9IVW9q1CJKz8d4FjUtUp+k3LntO6fenlBj3lc27on4YS6+uXk1 Y3No2MYrwQHQH5gXbntBDbGKN+OGJLbMNuzj7UvrX82OTPl5/Q/f0mDAC1zfb0IrITe6h4wlDg4v v/cf59fAdTAeJVTvO4YgjS+Upqmr9otqvCZxaSrgBpWRqXg1KT7Jgre5NAahloih0qC22EzlKkuD 3XK6K5aRZY4R5iJbWHCwO5lljHAG7NuZYrAYdKgOWFSyn7+LX8jpTsnDwI9g/czxgs95miUPOjqe FPQ/71f8I/kr4T43fJEXJ11L/j11fiZ2YgU+L5HD+Zut4PP9j8S+MXhj1GIAHaMmfXRNyFPrhP3/ AAn81QtKQLTWPnEvvMwblzU+sXMQ0zHFVN/qPlYrtE4HIt7B9PntDvGF3xAW2RIwuxh58RBdiXDU 8pgtQGOi9GHmbYAvv7QGTVD9psWXV1zUJ01SfuZEoU1EOQWqXzpDME9OZersvKvEwZF5VzqKHACY rxdXXNTFeLq65r+K/wCJKs3AhLGu47iYz2uno/39YNmvU/OocqB5a8vF9jjcdurEf8ar7GIw+6aC 5O+Pp3gmkvB+kK1jX6otaOT9cTyK8tziJwfe45ia197l1TdfaWtBlt9LiCvyuKY4t/qJtmtZnUvR GRP1h4Fqxn3mtYb+8pV1rV+P+Qq++vtL27pbw1O0d3v895Qdi/eaXwm8Z8d5tdf8qlNvCu/FTe/f 57xTZdVvH0i12VVvH0+G/gv4a+NHyTTFPclHL9GG6vv+E/w7C0ucoL/RuICsvkK9tsFunq1s7yp2 gvyb9tbnh/uUiwB7mh6d/wATcXP2mQKW/S/qXmMs5lB2zLh8PSrYMxmx5GvpBHPAr3/rMBc4eTPt uChvtr0JoPl5D7O5Wt7b1Fq3R7ZldnID9Z6ArkN+XECgbOtSvhuU8LtPKt7CtxYAOG6EtUGC/LO4 V3gGj2IeKuxTZpFEAk3BZXpgrefCNQng5CjsU3kZ9Zf1JUci1V14sW7pRGI4IQq2TOarZvjMMKBM vJeQEFapKuKewTu6B7N5qDB3qAbcwsDB8rtqBqFAloHaxdtjTZHLi0uy6HDRZScHp/4Iqs3Mg3kb gZTUQ1ydFPjFuMysAYija5Jc7nk4r2iq9ppz4RNosOKIqYHWntAcQFTUqKOPnncuK8V9JlvmKb+B 6X8Dy0VZ6N8RDF9Tdlal4iUFrueBbFOqSJpMUTA0s1dWOz1QqzT9Qh92fk2pRWyytWs86IHkNwQK ugQW8XUWRt4G3Hrv3u5qmmhwZe/JM39ZZZt7toNFlZBK1WKmyFe8vY0iQriklBKte1VeVbV8rL/9 J6X1z/hZ+D//2gAIAQMDAT8h/wDpK+IGk0F+MRya/hUMupbydRHJrrXwKGHf+GmwAC1XQBA4QFo8 YD6dzg5zWhmJfurfQ+k4Yt/jGhf6eifUzHgLyd/ZpE/x3TMaH0wjjihNO64lKAx5D7w5I7ZV5iF6 UTVW0Ho57RKkaiqF0veZmqTGrT+JbDqugyn2JSHhBYVxzeLzEHYYuUY7xECsoYwzBQVRHUH+GOeW GJmvGLvdYS3ZMVltLpa+ks+mgQWTNduW0AMy7CNvIvw73/jOputYvaGIgl+JfsQLR8otaZHUFS3D C0rJhrO6cVhxNyoRKdpUTdxddGYmwSg+NS0ZJTtAlRvgVegiTFc/SU5FqKVjWUcKCAXLMZJyof4W aPdLoaw3gR9y9KmVg57qP3JiGWGsSt29tW4ewr9T/wA0DTqACjX8N/Df8Re/sx13Wa+cHkrmG4WZ mHg4KsW8Nqy1XnIcfD9gsNW8MQK1HWLVFeE+6asd8U184af8e5Gwl1DNGUxjiLVWLP0gbDyxNl2V BwyCCtZgaO6/WU7N3VcxhphGEho5ePMBVSMdjwjYgKkMHdq/EyqKhGAF2kzVmrq+LjAVd3+piGzZ cSGC0uUx3EFEa78Sl1TWHvMmGML43BVZWVus1dXxcrdZq6vi/gf5b6gKdRjGKFKrQ8I6YPiYoPWG ke7RBw34KX78vFXE3wqjR2nbyAjApVwF559L/wAcX9xCtT2Slv8AbP1iuxrI+stvO/3QNuw+k8G/ BU7x5PtUMTdr+1Sstq/vKUHRT8S3ePpUBVzT/cEO0pxuVsHCD6R3JQMyk5FfaX773XmNj2395SjV hWS542q1+O0tO4PtHZ8jrOPPaa1ff97l9Dza83ND9Spoq71n6wBoq71n6/4oDYS/as7Mu4PqR3+p /wAiw21ThDQ/csAYPDn9RUbV2ejCNeVrwJ5X7FjUsL4LPr2/M1Nx95jWv+g/czZwKzAWcOTy9boi xOKThL+sEp3m/b5I6Yy8OPfUVpX1erNwcHC/iWpSiIiau98Syhgo+k9QXwuvBGsSmH8NXKpBw0cl yHAu1HuZtxHplCtHY1EIzKZh2WwZkG0j+SgmodGghsRXD9nVwybZYLqYFmVo21lFsDbIvAIBHr02 4ZfD1BrWJMiB6IKgACtRTSqNWNa05fAQGLTVGt7SwcgE79McJrCkDpwEyRLlPtfSmQyAOAIf/BQS nUxpWEirbcQ1fD0UeYCpVbyrmBFVhngn5L94DWk248oGkqXNBFkTvaK5irbcubGZQ35v6zDXEA1/ ExQYEouxFLQyNbKQZWmSqODQzEJaFaArdd9nMCxu4J3teYVRkZpRt1RLFBhiWZClOQWtCpaVgLYI 10qbuO2XcrKAKIHQeuX0wrvkDmXKJCwIATTDjDEqOJw0E4haC3Dg2IQHaymyKdDBRolNSYeZPBoA qu6JgIS1pchPBjOM/wDpn+G/wf/aAAwDAQACEQMRAAAQCus4gFQUoiDOgSwXVgAGSDtlZ5fjbo5w CWGwQgVFrAAwGGDA2BggDsQwAwiX9JT4jDmbaGygTAGA40IRi4WKzSwjSqXS8W4FqkWXMAdfkWia GkCmADjBImFQyX8HB0Ak+8mYD84IDKMRLUVNHeSgG2Ax4LyN0mQmSHBkAg2EAtN0WNte4ruWqt4h YEmyKqrEgzGk0CGSmAksIDfreQtL8jjTOw0EeGnKm32y/iXeCAU2eXf1au41/Pi72Ooedew1MgeF GwFt/wAPVJdmFIslhEkXVfnMcbYHK6++4t5RVy+Ibz79Wudvs0EkjtokUGFJJfLtsR0WFXllUMKs OGAS7ZrlbdKhgolhBAJAsBv/AHuf4otBuXuJvAO1BT//2gAIAQEDAT8Q6qwYblnchz6/o68/b99V Z6Y6bHr/AKnH3/UsPQLiZvvn6lzn7fvrsfO4/Cleff6/hDgyha9M9AsXt0V47fjpr6S3IaTI6yZx 5g4ngnA39d9Hiu37v4L72+RmMSzdX1Ke2B4eTyOTzOCEX3Nh4S+vqgvd+suekfPJMuCDvOvWAGug /SUK5/HvFuV03xqLib3e8OE4YNEGWwXG0x+U5Itt/Bs/Pjpsz2B0Ve99dfX4Xiu37vrkdXs79Xmu N/jodFUWwcn+4qfHPUcnhgg7jhH8MfCbV7d/X+EFl1DussB33s7kavGoqfbot04vo0qnQQsd+PLH tNEqjMwBXpGAefIotsoEGn8wR/rnq5mxzBxyujgC4HT9MdAhES1ZJstfzBH/AH0rXJUDbdcO6fov aUeTobPU6O7T47MI4raMQ0RWCloabGVEgHl7zcMK716UgQLJz0WP2noS2IAQPx8UcDWkB3SCVSwB RpoIkxAXVk+jv5DmHEa0AO4mHoobjKMc1Ftl0UWPP66K3611Y47MFF7Hd4PgP37D1DblGUEcb9lr DXkkFTSmpkKTWe5aJqgd5QkuyW3si6JkcIdrLHMJPR+AGm4ZD06Knqlu4lP4g2Hp0LB9+qpDiYiL z2DTAZpKe3qeGDWSDgfSB/Yu/wBzJuC4UvjzF8nUkUAJlB0WrAVI1M/kQQeRqHbSqkVYNY6sPErg Do95eizYLGspMILtwxMG4BW6PhMFAdRA0Q3OJJgqFdcWuyvYNOeueyxSNx3ki67ifjDWCTqw4QWm 2oDwYcmaR2/6MvMppPTtXsp5/DhFAlbZqT8utPbJtCN2kfEenlekwW94gzl3ZpaIpyHEAqbMYw+S gc3nHK0dI1qSL+L/AIkxZnbqoRGqtHRpxyRwwmMj0qJKbnSXZBVRohIW27JbBVdQFCZalpwAdxXM QIrl12YsBC+FUJLvOxxA7O/hQFZ0rcL9GHhAOTYmKKbHogaEdFjbcHKPBJ5bSJ2RHoF5I07dLhlt 2/IbFvJTARdBfkcBUCXQ0xV3FrcVv4hWb9vMW40x4/vqqPxF2vqs0mmj9+/UGC9GVZqUbrOwG/8A Aq/mbhIZZkVKa3OjAyUSCaMCoMWZzjqsWtNCPjeYeMSCBpwvBzS1LjFCENnTOAWTDLZBy/nhlIxN IL3MwlhQGx3M7KaZXMxTAl1nf0v4Qmtidu6GHmWTQev99BqK2utlzHvb/I89oiKJSYRwibHzHx9P v0c1jOsdjxBpPE9bs9ZqiGrYCjBsajpaXLHDSAzBk4DGQwLIJBuGnj2vUJKoCNi+cY2yLIMKwZxT nE8ACJO8TtU3GPMVBBJloxxV92zXxq69RQh9QwocAiHZtGC+OM8ET7FHdVTSohAYN/hgUVT4EPJn tifWKan1Covd+1yrBlRjiiIHEo0e/PXq0spBX5tnMBHBCxKOUkycQNggxWVUOL3TKEF3Tf1sb/Kt uZL5uj61tZox5RlDcazG9I2UGRUFU/G26cODjglAXo8BH4qrmmrgW74MBLqBsVfeznZiITEhAisX 21dJNw5ExV8yvEvslBtuj9OhAuPBg6elHNOIzYMupi1lnjnBLLWuGhKIALc+uONSlzgxxiAK08io ds+D1PErBb8xa+7Y58Sr9O/BHGLuufv++i231VvpdRuz5Xvwc1L5vFff7461CDsoBg2NkHDRMkIR DQaPUgX5nF9mgYQMIDuWYjZFpdnRrLSXopjWri4AAPivSrYI3IuTmZdZ/KvIj5Px/fKcA/H2Z0sF 5cxHf9E4ZD7UVkwMrYtfbF5migolges09QRsxUd3iwxrPTA4Eu4W8m71D8NO2ukAey2YXIFlyaSD ylFE/rzThCVQd1178nJxoBFZkW1hM5ObUKxPc0IN6a0zE0Lpane4g6/SGhZd54Zcqb8GWTb7Wzsg dvci/dI1gVSg6ALeePeXDsPk9HeM3v8AHTfqXnvzn0OnA229KN2kH+6aTYwO9js5XInCdRQzg+3/ AGnvlfPz79AN9bYeBGvhRkft6Q2ep+emj0/7948J5+fxOb6fvoEe8F130N0dVoRBAITHEqpqHoiq LID6PWAGj356BBbUsFZ5qUu1r1lYwXVfPEx+c/6lhzQZe/bBKwqSs2Dtn6DMM3c2+4We5AVoaQH1 Omsy3u/VlWTPL9Eos5lry/WKz+ug1cPU1iDGgWxciFA+AZRg+1Sml6J2ila4I8ROzDt7C7qBaIuA N7l3nt+6hqTauqdaR3FdNW3gNum1ZMttilS7hsmYoXQvRKUYVCodWijGdRiINCuX2xhIEO1kW+HB wic/WB0ErKlAV1LgCFNIS1EpWyUWi1DiSx16Z2/kClQEg3ckbFcQT7gvBXOxShAgL45WYZTSz7Ys WxfRwFBCpVoUhD2ID300mFLeYRqCmgKJqqtJ2ljttsXat697vpjFNQZZZZ2fPcO/c6cDquiT219m 0TOKUQBKVUPwGOpxjxWMfu2wJmkQYQWLfchgY4QWNn8dVioMt6YIAcu72NihVbaBvgf0dD+2KBvs Orfm5ZgHGrQ22XwTxndYK8FH2PqeZK2kHgKkGk6zjnkFPkQTqKqHdTpbLjxYZjJ2sGNYQZbTpigD coqBxgsMUIBqrJgzSqzw+Hz3TBuInpfCOurqg1K5/wAtEQlUwbUH7s1Ub3KXxOAtreDmu+biYUuF H3Zg4bXB4Va4o0Ofn4xJgSzsT652w3SoQINnZEOZUJKPco2NlLmdIV0QTl7L+5r0NJM8UWadShMh 6+dAPjmYiaC/I64ISy4Y9fnzDGXmAvVxV/1AGvrzGguj1Av6yzevE2xgrtEfKCF+tOSJgA+n0XD7 Tnd4Kfcr3qAaZ3CP0q4HQ+rmW7ynmcobmOpzt2JpXKBMiMChnT8Eshm2cElbkbJwwXDuhIkUCObd FuEN3QZXcSQ1HAvA2JkgwDfeAAvUsaPOFFA+tOw/9ikPAFYynstPrnCcltahLE1T5VDYAA8Blyed +qHB5quAgdQVILhoQSyOsjXMj0if30cfK9clwauzLMKOHcRmTrMiD0tWLNIdQdmRrgZHMXe/nBhl VKXBeFpmIEEG2isqvNDW7BBdyqlrAiDgFKSk/O64yXB5SDMWgFFrPiqiabU6CkBxzM862E+rs/Ka 3BG8wmPn6koPdzRfpHHcskx6WSajzGMB6aeAed4zjbTX+HGRi9cQFIo4aaWZ0hRNYpIWxI2s0bAq yA1AU9/hjNvNFv8AVoo5SVm8laqIlmqxqqTTal47iIOZIZWrf12IRh+NLGV+RCL0yl5rUxSnbudJ 5TtrnkSCC00MnOHaCrbOdJbiResjqRrAH7U6kOVisbsMubfhlfjQRZbyy60hgOg2FCpAIqYnMjK3 g1VimBxwRd9CKCcBaVOZKfsFXyMXwkxRinNM+tJINcSyWVbIV4FwqfZpcM91+qe3ijNa9fnPGV4F BzgkU7cSqrGqgJGgP1uflZkobgaGlsvUIImxcsC2ZYPr2+pC3l+8Dg+frKcu/wARQi/8gLl0ffmF DWrgXdq7U/6gV36W4UPTc5I74fci/ecBfRSKtieTH1L6XjGYWaZ2+BXl4Q8JBhBBhAhOKlOCECJQ uUHsLKudlGf6pbmrzxTx/K7zQD0EFelwsadcdu++qp8O4wS4PEBncBcJgKfvrRh1LMkKYfnx1FNe 8G+gw7/rDMFfoe1p8xw4Nj85IO+AhK46QQpmclSsghrGElsLG1NYzZxclS3GCY9rqzGYYXJGfmaT UjIVqV5MYMXW/pN4J3ss4AQ7iRBbFjzSjACCqU8iddbgyprJlWa0WQ9jmgLTNgYZQrwgiBSgdCn0 OEVomM+4hCoFAoHp44iwDTPGwCLGE0mWlQYFF3esySqwS4NoO80fUeqYzhlzuD2IhUmGVvcPUldM LOAn1f7fXCCiXFl+rTBPKtvpVky8gPfYam+JGBrbs0kkju2qxIA8w71x6TOiuT8+koL8xBnfFY+u 5dwHvDLlh2IPAwagSQPbqNaAWMQ84kdEVqwKeAGDRevrCTmsgyQnaA31mLfm1qRjTPAWCNX964gB LgjjJ4ZeSHwtbJhpPBTsX9lxmYGINe2Q/If3/mKqZ8hUErYm90nHTvaeFglGa16yDnKAAUlFFp87 mXNXfiX8ff8AuW409FMFfELRA4l/H3/uWbgpqKSsQZ/v/sRaa6CMS3e+II/3DPNV7wb1BGMRbzj2 gzz63/cvzX3/ALgjqWmpfx8+8s37b6CP9yqEE0n0M5PEoQhIQSzrSBSble5KSMEqrryGGAoGO1AF tFFEDXiM9pCAEUbVEX7vaWyIbCosUdDq9xblLBK6af8Au4LISYiccDTgVny298zQGKR+9VbbA5Dy jmLX8v8Au6GpYKKDUOtQs8/zpjn5QDzM7PPBOUzTmOywENEWWPg3IQ/QAmoqR6uv4vuy5Tkrns0y aOCEzHUsk4e8R/8AjUmlAOvReBP2iGI5C+NXphRRxqCDoFBHC1EBY+pLITZrYR3UMQ7duR/HxYgW ggzN9s/9g74+feLej594OzW/Mt7v1hiE7u0AvS8eIF1k3LHt5XmDwfndE8TjOpL9WMNPVZ1Ps3YB nxieoTX1lJ6jeOD99lxonFMZoBiPxAI6Y0R1WeLDV0aYG3wjhTQAcPBZEkXHZjpLuBgx9E2p3rBz LYyDfO3JUFbiOgYHHTISI4ZSMCOg3sSF3jcNF9utvNQ6JNCwfX6J+epfG/EHHN+eorsT9/bohwp8 IvF/SCuxPn06EEcL9f6g33+j08ReDDzeKl0Y2q873XPowb+ARwvt/qW7vv8A1EQAK0BTJaBVOmQ9 Jlf2zD4b4O/cqmDZefcR+iD0zxE6R9eo5CgkNqQQOTPeM+QEB2glxiWsR1mXlc8dd0d6BTzUHJZi Gz16DTz7C/iNya+eIWFLfa/1PkzPkzCw5e80jC+/H3irQnz6Rvm/eGf9w0QwOcXgfpBTdJxX7hvP 4WJdldp7vG4YBbvO7X2Iq0J8+kBbpp+7K7LjdcnZ95//2gAIAQIDAT8Qhvpp6vwm476bOo30cdHU HHTDDD0LiJzDUd9BqHwNQbIldTHS2HdFhUxLOhb60lrA61cRJqOupgjuGui8QIsNwyxeOhvo4b6u /hNOo10S5WbiX1Gyac9CjMJNTZBpmSjcSBk9yo6QjaEtmzO4ldS7xKxPYYnaJXRcfDVBewgWB9Hr QJ7DKYKFNyzqiFdj2gd41xM89AuOCBeY9iBzHLDB0dQKzFt6modxZVgA2q8Rg8rRke4H6pxlixEd 1Xsae1wjk0cHfSV58ibn0qaVyHCdvcsRg1N9B4iWdB4iVCDmpdPiekbg5j35m5qbINMc5IIOYnaf YPzA2yH3GfnxC8p9Zx/r2mahVQyv9Snz1gZHj1IiXMbBgv58xy6FdVWJk8/aepvNXX4uDKeOVpvz XaXhxGlGALv9EEFPLRlvQee8aGbFnY8jAl4h1vB7zEIFtq1eN161KW2KgGcbWDNZuC6AnDiFUkSn nLH2gbtMZ+b+81+qH3Ac2Er0tl/0wK2r2idrFULL04iKJQ9ihpxLaw+OVo183FitmFNd24YnWK1m 3j/de3MZju0XXcqLiCVVYvGWv16xqS5ZArvXe+/EoB3X5MU9K7y0Co2tTR5lLFrBA5iwLm2uI4Pg NrZdf3M96B++aqNlj6hRxBSlsL9FtB6u1hP2rH5mbNvSZJRa0TAMmaODXl2qBjnPQ1HfQbg1HGZs hE6DfQlQaj3i4icweJVDRPzLVLIFp7dqvCdoxmhwwvoY8SzuNgvD2azUUA9ZwmGTfN/PepDTNFr0 rGfntAZFgsvi/aPaDpqr9oY6kMHNVz94dW7ZU8VfmGPFVC7EO26+eZTYx1SFebjU0R79vEfKkjnn 0gRjsJaI8NRzJi7cFnaJ1hZveP1Lk428mVt385lyqo+fxEVy1ctmqs2p9Pn9xGTS2qKOIkrYV3Nb Mw8FW951/wA9JeaKrqxPn57ZfDNMic12vxfHmKf4C1QHz893ovIaeG3i48e1zT27Vf2ib8TAay5+ TvA6hUQZW0cwwTcWsdNagVF4h1TEGj6hEK7l1VpPYnrcBcRatULPeuZlWqucsY0ePJ2qE0t96oof dPuM4hvqGo76DUYX7TN0RvmDErpuHaJB4iRcROYN4iQbiX8GoIkqW6PVcS2Wy2W9cHMOS4nS3AuB FIU9A6BKqLb02wKJVuPhMwOYsSuipIVPpp/THjX082WfyeLaIwgdxF2cVu3OM5UJgeceaEeQJ7hA hiVGpoEXk3m/DBH9EsQvNlvBnZDDnoGOiTkjvq0wyeYvE1FsjjEyTDL4YlQYnaDww7tRNbpQxAGx gXdBjsvntSc3TQYAUG7QaaxW+FF4IdKKjn9N8maobzUAoSjZtSsYHdniDQriYdItFQ0ZUsrmCmYK bVZsyCJZxzLMeTKlhMmW6MKrZwVF2IGRsLWMXvihxVXEeQKs83454zw3WITMLANi1LYC2uOe0xEF GnT2bDs5LMbhA0RXtGk1u8e5mYBIKtduQwOap7AmYUEipewg1hMXvX2tkgOBeRdOiel1nvKrBlvg 9hx38azPqIDbuqq1mrus1DkIFus5XQvBVStDaFaXsUP1aMlsRoXAuV7FD9WjzEawKgK2pV4rz84t kuAXLQ26r2Ua0Sn1km8L7Vg4v0uApAHU8El4rOMXddoTFILb23Rge22juxax7o8l6rWau6zU5ruh 7l6rWau6zUCVAlxtJgmWBKdsaGItwJroHePaVHoMdBDpyCjBqCc+TsxEyzmfAlidinqmR1aw59n1 XUD0G7i3vl0cCiybAOJiD3Dn3bndDMGmJKmmNe8SugXmaxE+sq5VTDNbmSGZ6yoNShyRqO6Gu9Nx CsrBvV0JVZ13JZBLD1OcHDhEmtAHNZt4bsY/O7rfZrxvzqckCxfYI8YvN/iY5dV7d/UA+nqwNW2e XVggjWEa768y2pogu6q1cZVu9faElYS3VNq4bM6x6yqrDObqyrWd+NeZqAXbbHsNUfV8worQt4w+ xQf1ExY0CmgVdNlAaNYqX27ad4Y8VXmDbJLDnBKbzrXm4LKwBLrARzT37TWY67apWq2YXfmoFFur 7Zfm5YtDdKHWWsmDg8VFzUeKl6xYXTGY1RVi/Z+Km1O0psy0bF7vWJ/bHufuva+YVthp6KwNVuq5 p8QG0V8UHwKQPJh7JLGqNTKaL7qxunkliMDB4BXvrDmnddB7blLFCNtQO89Jg9YxllRe3Q7ovB0B 6pWYddC4YgEeqD7bPa4ksZ7H7AIoNfbyO3g9PrBvo4my+Zp0SyGNxL6DTEvJBrDK5JhJSMwzW+g8 MrtroNQjFsier747nJjG4HoQwlWVhpkODG3PcbQKjWyQtOwzVV5SGumjSoh2cIvAsgqClKaRQ0Kv zcc3bevBgTmn7WXUBWa/ZVWXrdKrmBTmmy04CqAFLThvjMps4CKLgiNB5Fe8eYCNpRV4cF3T2rzC KmmHalB+ljvQwZKXcrCwtlFmDgHLgmNCmpSsZvDyablhspra8HHZaqyECqY+fhYBpW83YcSqFkro NeQbDg+5F1UUBpAKWpemaqvLG1U0YUUpmzNpwmIkVSjilLCqt8tnpFHMHkzhgxjLvOOGV5FOooa3 6DPGe0Tmw0iOy6sss01GB1F7y5SzRKTASdpbF6WUcAO14q5dMU5AXZKzT3mQTRgdMKR1bADAAqHC wJE5AHCtwWyHbNNBYLr0ooWUpbFoSm8JVu7MUIGEhFGwjblgnMAEXAnKuKgoUGKIKQ0U2vt8s6o3 BqRYIxTUy7urnoE8iBLQEbwos4SEFGsIAEboSkpEblBwqZRCQIoHTPSiUQiEqXXpEuBUqOCDEuZN RblYxLSbZxiDmOpklzETtBqLcKgB6DY+SdygMBS1eArgxr7y/hvVg1e6UUvwkFR1gfJhr6hG1dWU 2CPqIjLwSgWsoJvjCnbxiOFhgXaB5xn2PtD2RWIA33aC3y3KRQVdUAZKcAFpi6uaa0fDa7NeXO5d +qJ9cQAIqt6L39fPpqLjXBigD6AESDbKHa9yw4mOC2tW1bXll9qveRZwXkc49oMhsVcgtu0UUXxU uLz4Gr3Sll+Kho4KMFg8FKHgZfJwha1Sj2o894G72gGwRAAsSmgOIelEW9G6r8caiYhv4FoLDodp thS6BlCUg4c6cKS2NUbTPnbDKNFpQqBRYiAGi2rfqmHesRbopruVE3KI2LlmIaLW27Kq6wtdW3lQ KbdtxfUD3gJ7DZQIpAFVZgwyoGhVAFxEEliKRSpR2yZu8zNUQq0FAl0FQzXfBmDXDHBUoAMMXtul zXjYlsGfI4LqrZmPEr2ATW5Q6ziW+A+JhfPwO8QXnonaF+0aehcw63MzDuJ0F51MPW+83rHXMvxM MrzOemZmWy3tLe0F7S5cpUt43BPDLe0V6C5XdlHeYlkvtG5nmAS+0V8xu89MELvM1qNcxtrUwRv2 h4n/2gAIAQMDAT8Q+GmGv8BIn8Bv43f8DD+Be0CB36KEG/8Ax6Oin4LrLqFWxPEWAhe78TAbR8Ol nwuoagtoQKou9TqbaPh0y6hTfS5bFhAWvPQe/wDgt1iY+qwKq0EFGJotpyv5MTJQC0dEddeUWlZE Jy8NCRVCrtLZ0Aq0vZJSpomSvGhTwKREBH8a1/BUpmYfpMSl5D3HHz5jfCB6Hz94fzBdugl5gLDo n9wxk4C5T9SmSwq97YfE7Jj7X/U2Gxy3nXiUxynN2+lRapPPorawpuOj4cMf02VuV5vQrNly/pIZ dPQiOHDe4ncmdIhb4w/uYlGx/U2+pE4CzFUb+hKlWuXHrAoWFiafrCjTj9HiVtqc9uXFQaKbtt9i o0RY0XjHP+v+QCXYTv2zBKNl7zXYhAAxxzMk4t/XUv8AnUvVW39f3CWdAlg5RYDByBbL6IDoyk51 FYIMTth75/Exjo7HCRfcvYW64QDZAFpfyEuBT/EVYbRgwKksyd+/pAnWguvfcIpUpXPkuAlEqjIu d6hdkcWD6xdNQUa817wqPg3UUWSbs/H2jItMMc3XiZijbarIvfUtsCN2LftF5Wk/PmGDsCGYIMjV j3LguSSsbrzBBs0ek5JKPYPEo1dj5zAAxmoUoQUnchugMF25hGNLfziMOVCnoTLlb3SMxHYcXsfP f58Q44uXascxnhrkxHkHDFnf6Q4AhtePSBKOlkuvSDf8L1BrAn0WoIBnDXoXZlefGJyGgpAunRZX iYHu6nlpic1w97iVMo7QO3NoDII1Zf8An09V/hMzPfLjEGHQ+IOg38K2bV/DfEEkuw++z9kTAAng sR2SfIxmCdpqqUBoQKgBEs7awo/suFGlLxNYD1YVAushkJsZQNzT5cUWFsXVIa/lH4Wr1lL8FxQv 1C1Vrnm6472PFXckFApVFll5vXIV5i0tF3H7a74u0rmI0lA6FA3nKaqFSNAcmxaEy7cU0+I60oLG rp04Upp5lPTFgGhe8NW6AKb2CYZWsBRC85rXNpzqH1KV44rzxzjkq8x2K2RMqDDK0XzxMwgWWGTu Uvcw051GkvYPcljvVZveHEtUhug0YXZi7O9jiKQQNq0RS8jxrf3qmbDKGBqy8j61x2lzgCjz6p6H neJxXYGHZd3vF1V4uE9AKjePJDluXAaABYd20+hbhohYIZAwHdtPoW+INUSAqVQN1m/HzmjVyQw2 dG78WCXzLfMmisq73l8etSgCNFhyo1m7O9VcNVSLRWircp30W+JTi/SCt3vF1V4ucN4R2K3e8XVX i4HLLJvcRqXeutSmBXS110uWSzoYOY1MVxE7ssGA9IAg2JuU1/GAUA/bNkdBiDANYQYcWH1lwMdZ dERdWBQqooSF7JZRxsoOA/N/4SQv4M51YXurKihiARW6tG7xvsxFAUj6HGWnkRmZApxeKeSkSab0 DXdvzrxuW98Oh3KPnNY/uDd3dnT0W/r6RdtTBaurCEvInp9o5YC01V3gM4Arv94pFEDV2Uvkpx59 JYla3jdgveNedw+ZqiivdLt+h4j5YSnnJ7gUgDBkG2y3V4bV27zcQp2kayz5u/ET0QFXxVmSsb37 RxGkQ1eUJizt3manNdTdr3elzVeLmUtBXfD8VKBtaICbwXhy8wcRBzWreaIJvOMzOF0Pu/NzWHeW 0YLYVareY/rH2P1fvXEbyiBXbsXer8YjksB5s+o2InfJ4hSrrYW2/uzqzhlfHeDlv2XrFneWwItT crrUDo3xA6LXw1K+kfmKZISg9ET30+9QVSR3aPsr9oNcHRwe/l84rtz/AJCYKLb9D2z2eHOdRTYD 0brPDOF5c6MdiOFQq9wFpCmHF3fgiCsojlaaMZmWNMVlALssXLi3XtDoUUqzgbeT701cVCF/umWH 0tviKIuygWUoKbuzJkrnETb6BEEMsEtfBv2gPCDobbrJnFWd78RnStd97BT60nqkoAFTClpDRbTl 5UoMsyg21gR2rLw7KlfjE3wcjPN0u8McrZ+DwVZXrFUvMsRQLVq9hKXv9oEtUJVhsGhFG8Xd+CFQ 1d3dtl4rVD2cwxrQTNrUt3R4KfWBmILDjLLnODWM8kswAuQAvTyZxzjvC7suKTTV0007Lii38XE3 CEMpWdjsE5UZhF12+kGZO5CCIVI9CKIB0JYjQCs/IXEQSo6FDWvBnM7efHEiiJMcWY0TXvmhDJOJ I9uYcxV60kvh27dZfbNCDqLBsTgXHFUZLyb6p/KrS2JbQiRb0BBQIPkKEJv+KDJBmb2E+zXw7lS2 DZ/kIjtFJ4YHqgOVsLrK3y+ZSx00pdasGmvIxtG2w9aT9sIAXTZlE9ERlMgEDwKPvkHv5hAosqqt fGce7FQwKRVx2LWjwVABMrq7VcNmVWhNajlxs8tKp+x48Ssd2H6Zii0XT1Vr6ePXcHS+e6r9VWAg YC3vWpTenPLRe6Lo9iUmWlbTGcYTGYoIpAMKFGhBBrzcqZx5S61YNNebjyYW5aU5S6XykpAZEN7t b72+O0UNaCpSiKq0jZdvMVEaK26u/wA876ESj4Aj0ZDa2B/FSsolSHchBRLqmkGxWOC/yxiPHBtE XkU0MSUyY5psFUhqdXNSQJTZLlqUBVy7TI9SvYyV9CdjC6pAC9uUAIMA9DDhSi0SgHqaCuKm9TCD WtTKhsrxDwDJKZvjkGVDw0+EUxR0ATBoWSt2FFkvxv3hv/wH40OOtvaesT4HXw4j/AN/H//Z --_004_4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7CRPMBOXPRD02p_-- From kathleen.moriarty@emc.com Mon Dec 17 13:06:53 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB62121F884B for ; Mon, 17 Dec 2012 13:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+GrjX5RqWGv for ; Mon, 17 Dec 2012 13:06:51 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD721F8850 for ; Mon, 17 Dec 2012 13:06:51 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBHL6lP3025846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 16:06:48 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 17 Dec 2012 16:06:31 -0500 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBHL6V2i003619; Mon, 17 Dec 2012 16:06:31 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Mon, 17 Dec 2012 16:06:31 -0500 From: "Moriarty, Kathleen" To: "Cockrell, Erik" , "sacm@ietf.org" Date: Mon, 17 Dec 2012 16:06:29 -0500 Thread-Topic: Upcoming face to face meetings? Thread-Index: Ac3cfoE1i365ZNJUQriMLqwY24oXHgAG4aHg Message-ID: References: <4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7@CRPMBOXPRD02.polycom.com> In-Reply-To: <4038C3329CFD1D4EABBE867CFB81AC30013BDC1AB7@CRPMBOXPRD02.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_"; type="multipart/alternative" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Upcoming face to face meetings? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:06:53 -0000 --_004_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_ Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_" --_000_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Erik, The next planned meeting will be at the IETF in Orlando, March 10-15th. Th= e individual meetings have not been scheduled yet, so we cannot provide the= specific date yet. Our goal prior to that meeting is to have a well defin= ed scope, set of requirements, charter, and some supporting drafts for that= charter to work towards becoming a working group. https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Coc= krell, Erik Sent: Monday, December 17, 2012 12:47 PM To: sacm@ietf.org Subject: [sacm] Upcoming face to face meetings? All - are there any upcoming face to face meetings/events/conferences at wh= ich SACM will meet? Erik Cockrell, Product Security Engineer, Product Security Office The holy grail of security is airtight input validation. 7700 Parmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 512.372.7155 | = M: 512.739.4250 [cid:image001.jpg@01CDDC70.79527F70] --_000_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Erik,

 

The next planned meeting will be at the IETF in = Orlando, March 10-15th.  The individual meetings have not b= een scheduled yet, so we cannot provide the specific date yet.  Our go= al prior to that meeting is to have a well defined scope, set of requiremen= ts, charter, and some supporting drafts for that charter to work towards be= coming a working group.

 

https://www.ietf.org/meeting/cutoff-dates-2013.html#IE= TF86

 

Thank you,

Kathleen

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On= Behalf Of Cockrell, Erik
Sent: Monday, December 17, 2012 12:= 47 PM
To: sacm@ietf.org
Subject: [sacm] Upcoming face t= o face meetings?

 

All – are there any upcoming fa= ce to face meetings/events/conferences at which SACM will meet?<= /p>

 

Erik Co= ckrell, Product Security Engineer, Product Security Office

The holy grail of security is airtight input = validation.

7700 Parmer Lane, Bldg C, Suite 100, Austin, TX, 78729 | T: 512.372.7155 | M: 512.739.4250

3D"Description:

 =

= --_000_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_-- --_004_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=30036; creation-date="Mon, 17 Dec 2012 21:06:30 GMT"; modification-date="Mon, 17 Dec 2012 21:06:30 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/4QNxaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MSA2NC4xNDA5NDksIDIwMTAvMTIvMDctMTA6 NTc6MDEgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6QzVCNEVENTk2ODIxNjgxMThGNjJFM0NDOTI3OEI0OTkiIHhtcE1NOkRvY3VtZW50 SUQ9InhtcC5kaWQ6MUQ5MTg3OTU5OTQ3MTFFMThFMEZBQkY2MTNBN0I1MzgiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6MUQ5MTg3OTQ5OTQ3MTFFMThFMEZBQkY2MTNBN0I1MzgiIHhtcDpDcmVh dG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNS4xIE1hY2ludG9zaCI+IDx4bXBNTTpEZXJpdmVk RnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAuaWlkOkRFMzQ0M0UyMUUyMTY4MTE4OEM2RkQzRENF RTdCMTdCIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOkM1QjRFRDU5NjgyMTY4MTE4RjYyRTND QzkyNzhCNDk5Ii8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8 P3hwYWNrZXQgZW5kPSJyIj8+/+4AJkFkb2JlAGTAAAAAAQMAFQQDBgoNAAAU3gAAPywAAFSDAAB1 Uv/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgIC AgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMD/8IAEQgATwJYAwERAAIRAQMRAf/EARkAAAEEAwEBAAAAAAAA AAAAAAIAAQUGAwQHCAkBAQEBAQADAQEAAAAAAAAAAAABAgMEBQYHCBAAAAUEAQEGBgMAAwEAAAAA AQIEBQYAERIDByEgMEATFggQMSIyFBVQYDdBMxc1EQACAgECBQIDBAYECgYLAAACAwEEBRESACET FAYxIkEVB1FhMiMQIDBCUiRAcTMWUIGRodFiQyW1drFyU7N0dfDh8YKSgzS0NTYIEgABAwEFBQQF CQYHAAAAAAABABECAyExQRIEEFFhgRNAcSIykaFCIwUgMGCxwWJyMxRQ0VLCJBVw8OHxskMGEwEA AgIBAwIGAgMBAQAAAAABABEhMUEQUWFxgSDwkaGxwTDRQOHxUGD/2gAMAwEAAhEDEQAAAftwIWoe a+oUjyuqogoWoea49OPYUrhQh7MJowWpkhxggqOFEk1k1ClKEIgtZwwUIGoCwKVOGjq4UEFCHV5G pKl2CyZbOjSqEBTQFKGoYGlDUBDwhahyvYg8nVUQUKiChVkgKyCQ5UKjiOrEhh2KHo4w2VSwV6Zj b0UOIrdzXdSxyvDxoVE2OKshXbKPqdh56cr1WTNSNqpVDpV9ZtcsvLL504wFNAU40BY0qoTHESIV kJevzj+L/qWXuLJ5Pz3sn6D8VvfkekfULNcew5UENqHKg5HVD0iLhWHKViQypanxs8/w6lqfUzwv KjLOW9M8j3j6h+F5XzG8zxa1qejeXSbjp2NeeumLRNc83mz5vU8a5ZvPmvty9Fculzxryj35e2OH eh6yCbUcc6Y3lv8AnXuXxO6jYtmpdmxpQpoVCCKGoDWjQEc78vw/m78Z/VHpn6H8X9C+1/Prl4/k eQ/m/wBn9Z+//Hfmsego9pC1PP8Am+hBUcNRIoKilVhrhSOlKiHGK/Z85fL8WxTV2xbEvnfrz7Xz 37T8ft4V8nhYZrhnTn2jnu/51Xbnl/TPRM64h0x0LGrtm+iefTzR15wSCvLt46HmgbcYaja75w6e huXR7SFptZkjLnlemjHShUBgjEaQjivsfW/JL8y/uP7Vfe/xrs9/Bx2eC/l/3b197/8AEfHx5ms9 MRBLCV6AjdOXEjWsVaLqcfJQ96Wd8XVTRUghxgghzNEkGIrm4COrw8OjxoVF6hhhmSCXnmpPFpgh qLFeFaVENqPIoeXZrcjOqlRjrHGEE0h0477D1/z2+U/oqI+X/ZvoZ99/IVf9f9N5He893+2/G/jb H1BryRJfDjFtyhwK+tUfJSupnmyO7V6piiHtiiTUl06IIq+8cq7ceh8utQ6c92WRlvHPXLe3LPND UdZb8bjbNFmD1mZzcagOEZ1lJQWD3iNubzz6aMjnRuXZ6enR0eUoexlSlm57MwcYqEUR9FJr15p9 t6357fA/1rwD5H+gOzfffy99g/oP55lfH7ctj0GeErIQ7jL5Jr0BGoU+rXFSruBIx06yGl7IJDrV jSV7IHWa5vMRc5FSa9WHOtLWY4k86gt5yRiqMuTTdls+N0Ppi543ynry3To/LrR94m86i9YsGdQN ya9t4d3tYe5PIlca18nlexh5WsJDCNG0pEurceevbeqpfk+P2L1/sOz+v9gqPNaiFY8vAI9B2HKh 6cQQoeihxURhjQOf9uXBvI8e7Y3JZ1TOnOazrelmJazvOnXROXTkXbjfufRki9Z3pafvHUePWjbz DazmjsHHtbufRB2EFDq4rSZ496r9D4t6n9Hl+vg2/wAr5+6+T89yX1n3lj8j1Ft8j0VU8b3kLz9j K9fA617H4S7+Z82NYIeHp4QVhSuroVKVDoSuEhSvRQ4qUPqPmuOPRQ4FkIUvpjcibmtKzCaFgmjZ trKSx+pISqNG51rDM5tyx8RGpLy2LGiUqJDyKUrXDStcPcavPya7x9vn1zuXk/PwXD2gZ6T/AH9T HY8ytcPcS/XwbB29TYO3q1GnqOHCpDhI6vKYrEIPNelYea9OHCFSh6KHFRDw41aRghxCohwIh9Rz MZaQ49jojelkpajZrWZIPNLVJkwpXtOCkIcWqoLNyCsSDqqClYaCP//aAAgBAQABBQLw2wO6KNw7 O3/s+IhcDBiPfkObWOrcXZ/DHLiNX7Ozbr0a2aRsMi1uMqjrEr7O0xSU1uza9I/juLcOw6O7WyJU k/g67f8ABqd2t8Sdpa+M7cs+Va1NfPvB6dhU5oEGp75lfZK5poDzKsKVy5egRY7I2mVNXfiGQCFu 1IP/AIPCC1RDXuaq1Mwlk3n7m1vkW5FciP6fkyfPyDlGUvswbUZpKMc4n2TQX7jp15Mb+LVXLivf HI9PX9JKuT5Y4wqHP895Pi4SicPRpXv5Sk2hhm/LJ49W2XuG/kf3B/5zLpBwo6xEZZL2Fpj0ylrf LIDLXaFcUS6ZuLc/LpjOZJJXaezZpQtcymrDKUPJHKz7Fnbk/kVNF+Qyiqn/AMCbDEom4pu7Eb/F 1cTBs5ueFBCwOLtUOYtDst1ikXp1lLU+rj3kN5dU7Ez6/d1x1uLAOeoByI5/B15JYmefd0ct+076 NqppJxVIFvCck4veNEH5JgS9fKIbE9S9Q1QB8iiWewd72w5jWuTg0xVlmUbmMEicgZuItnFUh9IQ yPjtfeX4+8SmCcqxd9kkNmPH69NNojFNW1Bx7xi/62/h6HyZhrmKOPUqhSBDoTJ5zG5LqlDMyzGW zjj6AuCfi3ghscnZSZqnHH8oe4/yK60laJtO5fD4bJGri16hEnV8Hveh+K7dgm0xaDaU3cCPYTlD c+c3K9mnk5kKj2Ny/wCjc5ovNJzW+6ljbyN/n3tYUaNfD3uC3Ma7lSRcuzSRTDXy5yNx4/zkb+6n ijlJ5mEh5p5SceOUci5emznK2OXc7MEok/L0wfJn/wCt8l8bPPKnMsmg86f+WeauLl8m5F9wrWyx WTOUybqOTuSjagG/xP8Af2txL9uTxhslzYysrZHmzvAOYtBtAavfsCPZX6ztjrzjH/z3TjLlz0xo RzSKPqiRctQ1iJG40tl3JvI3+e8GcAQTkDj2DcJQDjrf7T9mlM3+7JW3a+KXDSrTe4PlLWPGnNTG T/1P3G+2XZpSSHZu1EH2r7NSTd7rFbbp4ictC1JzR7sv865Y/wAl9un+L/A5Ow+Ldray7ZM+7l3q DQZ2f5UrZ3JbMUzaOiZN2LW9aXPZomSv9lvmKItPEhVNrwzTHSsStr/ocFCuWtiE55mhBQ8znQmR yCWA16n56Utbb6pRfmPD6oa3T1UhPpWShGjTEfk+13Vv+lEuJMEZlC6XYbnN80NqkZMiKqLJkZlf dB0oNo15gVftbdWvcSTsn4YvXEgqzqIRLE5onAlCVRGGv9Q0P7SV/YeMYDo40iVTTg9K9yVg4JOa SPnGqZ75I9wc+4zeeOeAYIeBccTvhNDJ5Cx8GOmyTTjhBHIpIycC7VEjkPGCaQcj8pccJ+T4/KI7 rk8W4/iGqBQ/4nJ8XZD+0akzHsSu6+MGXvcgje153K4uCqnCHpnIY8xEY6PFhMfXFTaXJ3ZNjku9 JaNiZgi2pk3OcQTOjsnh6tv1mhCYqB2i6xbsdGQXBrPE94blDb57v6D0F0O8I1uQN7OCBeuh35jx 6ZD8U0TVZySPGkOrVCkmh0SwtGkdO+uNZVkHY3adSjU4wxSBgiT+YzJEdKDZ29fFPHGp/wC9MTKv lUr2q9EZ2vslbTuMuctLlO1B9CZqcpDo3Nr26Or0jme5XpO9P7ayvMmkLMOuSSPXtkL8ZgOM7ddS dvUuz6LfJHBasY5a5OypwUP/AKrJPXBcQrm7uDwufnhPp1yKRqF4S5wMgZF6hybu5lT1ujqhlmT9 urfyC8KSukpeTtDC+rl6zfKJWDjv5B1J0ZJho2x9ZNvKIsmzs1OCXkEiwrG7ndtXjxDKlSXUpTlj LIVMpYGpWsVIUq0zk0t7vrTsraiMysepqTpowxpdPpRi06RZ20acG5A7pjMTQc6BtSNhNLW3p3BK xNSJU4xtmdlW6Os2/arYWlcsPGGBapMwNyTcZgaDpkzaiSHv3Lu0Nz8g2R9m2rPRcdHXuiEe3n1N yLSs9NMouO6LMm/Xsa0G1s9Pswp9UIjOmvS7MKJtbETSm/gRKHbN9vwuPb0COR8MduspB8R//9oA CAECAAEFAv7UICFWEe38u5tesTfEbh27D4MegbV+/acqRxNWS9NWraTcTwwfPZ9QF+kCluAl6YFC iABa6XPjY2GeHUShYhcjAUg0BQtgFykvVvp1fcAbL2AaEoWMUDHKXpYoBiUaxKIYkAcC3L9vgSFp 2V2pEm8jUJC0JRChD8ZT4b/nMPMA4ZEN0MNZANFMGQ0OIlMICfMLmHoQbGIIAYpvpEaMcKOIDRBA DUUQsIlApjfXsr6TAAlq5SgIgJ8g8wLeCHprWlsr8zzAL8iGpz+kf4wBtQjfxBfrI6pxMlROHkgV RoEmxboJSjSba4eGALmxLbHoUtwAl6wGhC1YdMBopbgJKEtqwEa8saDX1KS9FLccBsBbhgNAQax6 Y3DCgJQBesRrEfCB0rWYNpVjOcg/hLLtrSbUbYICbwwDYcrgB7FKa1ZUB7UY2VZVl0A1gzox8qA9 gzvWfUDWoBsOdX6eZQbLUJrgB7BnWdFNjXmDbMbeEAbURQFefqrZvE3iCWyxKNAQLa6EC0IAADrq xRMUpTViWilyrywobFoSgFGIAUGOHlgFWAAAoViW2AXMFh7lTtHSOpVuGhW7DVsUbfL1bjHMO9Rm K0Cl/KAdJlVqMq2azlW5Vq2eYH8B8qzNWQ0A0AiFXEaE16zNWZqyGgG1ZDQjerjbIRoDCFZDWQhW RquNZDVx7rZrJuIOnUJvxdNCl0jWBAN5GrMU+oa8sgk8nVYEmgK/H1Yk1k1B/Tf/2gAIAQMAAQUC /tV71cA8DkHjdZDbdjZDWhvS7pHBtInTw5/FxblTWq8OToI9REaA3XIRow3rrYt7lyxy6X6mGwXM FCPXIbCa1X+rZ9oiS1xCgEbgNiiNXERyGriA5GEMjWN93gTmrjpgJuLJnozu4gc1AYDVq2GfmHw+ I4CXoYvUArG1GDpQXAQAcMRsAdThcDAIgIdQCilGiAIUcLhQgN+oiUv0krqA2NXURABxsOHXwQdd kT3+ZGtyY6Tcb5nLUH1Cf+NEL18vEG+g/HjqTS7y2F/tT72N40bEUVeFVJHLS2xPwwjYMjXy6mNY RPaswoBvWfXOhNYQPQGvWYBWYUJ6Ma1CawZBQmsOQVlWXXLrnQnoRtWVZeEEL0PmJ9jByFo3h6nj vly+daFukmWPhh6hbqJbiYt6EtCS9FLasax6iFxwopbUJLjhasOgloQuGNW6+XQkvQBYcLjjWNGL lWHXDr4QQvRk415G2tegC+IP9uRgoTjfZQCagERED1cwAJjBWRqMbGvMGguasqAwjQ5ZZiNXERyG sjXzGwDcO5Y23W7anGPNeutUUb9IomRvKvc2xMmT6mVj/E1RQ+5QZg2kdU8czMnjiBcl3xQycXJv KhP/AAOIViFWoQAasAUBbViWsC1iFCADWIUAWqwXxAKEoDWIViFYlrEKxCrB3SBwWNaorq4kT+on bIkgddRTrFGxP+4cfxNb25azlXKiLf2rj5p5I87K/dOH5CxapX7f6b//2gAIAQICBj8C+lVqs+Xb 8zYrttvasxuXS0keaeVVj3lPV95T9azwu7RxCy4ssxuTxTF3RBvXBBW3ovcE4TJg7rMUNxRdZtlt yMvZWaKbFkSU8k/sp4prVlxUuxOUNPDmhm85vVh2CUfyql/f2h8ESVluV7p8zIurEN4T4I7ir3Tl WpnZXuvCmFyt2ZSsoWYLKFbYQsvsphaSgcE+CPYuSNWV1iEx5TsY+VQp+1m/ZrhOe0ZcV1RfG/ud dKr+X9SsnF+9ZYnNPcFGcvLGA+s9nZOTinXNc9nBDeuCdWb9nLZbvQdNsdWpsU+zkrdyfs5pztWb SDw+tN05v3Lr6nz4BWXdndNxTLmubrns4MmwTI96xTcVaLE/FB8E64ptrJlyZXWtsZNb2VwvHsaN 3aA6A4lWo9yc+pcwm4pgsWWNy4rhsfBcVbvVqtQHtFY3I7vm4VCfdOx9Fnr+tRhU/MDyl+FnH/Ie hNCIE80N90i2Mfs4h1UnTj4YiVr4xfBrn/2XTqBpZQb3vf8AcmAH52W/7j7ufq7w4iKhMhbJh4bD b/oo1wPATbwtbnb6rUKn/XmlzEYkv6lmqhodN7+MQLWDX9yyxETVcCyTi1ze3A4IuGlEsf2G2yxW /JsXdsbDZZsZN8706geCM28Ugx7kQxtbE4WjFFxfxONnp43rOPMzcguo3id8b2a665M2JN5F99t6 6R8jMoxbwxu9DfUrsGvJs5lZLW7y/pd1lhd9Dv/aAAgBAwIGPwL/AAZFKkM1WRYAL+4/+mrR/A7R HAm+R4R9a6Wn+HCpAY9OH83i9KyaCUtDrzcJeQn0kegjuKlpNXHLVHoI3jeO0cCs2DphemKcMyBF y4oqxcUxTp8EwXHY2yy9Ae0mlsACaK+8mknWbBDsTBVPjOquicsP5j9npU5QJ/RwkRTGDb++V/qT EbKlCv4viGhGaEsTS9qJ/D+7tDYoAJ1cyZnVmzgmxQ3q5WbHvVytVt6s2OE5TFOrLk+Kcpk2KHYu ao6Gh5zKoJd5mfsZT01UNVhIxPeNjjzLV6uX5A0xie82/wAv0GzYL+3Vj4KtsPxNdzCPxL4bljrv aibBPi+EvUeCy1dNXDfdJHIhwV1K1M0NLEOZ1PCwHC8/5tVXSUT/AFFfUSiN+XLDMfs59ndMNyZc ly2cdrK3ds57LFYn22J8E2zmrN/aI16BMZxLgjAi5Ch/6EyFT+OPlP4h+5+4LONZp8jfxj6r0fhv whzQPnndm4Rxbecbl4r+zsn4J1yXJly2cXT4p0O7Y/BWG1NwRbFMuCfa6dc1wfY6fsrFeDY8rT2g sieCsQ7031rkVyTlcVheuC47GxXBWblYrE+AWF6G/wCb1WihB/ifTjOiXPszAnFri8JZrQWyWYqt qtDEy0VXpUdP5j76VWVOZveR9zUllt/MjZcjV1Vec9L0dT5Y0yRUoUs/sV5RIALgZxIyGSYg7jRa bW1jLUV6mnkaWQ5TTrShZ1RNxI05OWiwuzuo63RVZVdPKtUpl4ZDGUBA2eKWaLTDSsO+IQq1J1nP wrryOTyy/VRp5ogVfFZmhkLRZpu5aFXpTrVNFTpUZvTompUkK8c8PdCVlj5nmwa8uFW+EVJtqqdI zh4T7xodQRYsYSlDAuRPwNa6q6EGMviHQ0xtBHTqV61KGSyTWRqDMZRLF45XGZGj8Nqyraz9bCnm NMxaIpV6k8sBOed+m8bBMszB0K1adal8P6M6kjUoGnVHTlCBHRM7XNSGU9Ri5cjKVTNKfU01akKk JNlOUmUfFF5MRKMh5jvf9hvstVnybV37Hx2W7HT/ADsdboJ9PUxdjYbwxvcXFUtLCrIUKFXqwFnh qfxA34b7FGUZwjkMyAKVGMXqRyzzREBGWaIY5gVTjCpH3UomJ6dPMMks8Rmy5sgkHEHyfdQ0s5e4 FSVRrPPMREjvtEY8N2K/Q5/6bpmn5YPkMxUy5suds4cB7MLys+cF6UKZEoQnExpgRgDCUTA5QLCQ +LuSh8QhLLq4zEwQAGkLRYBl5M3BVq/VPW1BeobHJExUB+744g+FrmuQ96ItUFTw06cPGBKOY5ID MSJSEsz5n8ToaqMqcagiY+GlSjAg3iVOMBCQOOaJddfVSzTYC4RAAuEYxAjEcAAPod//2gAIAQEB Bj8C/o2v2f0Av1NPt4mPs/oGo/5PhPH2F/D/AKPt/wADfd+uxzjFalAbWsOdBBYDJGZTPoIjHDm4 LL4/LrrGK7B0LSrMJM43ALOmU7JIY5a+vFWll83jcbbv6dpWuW0ofY3M6QypZlBHEtnb/X+swzmB Ed5EU8ogR1mZn7ojheQxF6tkaLZMV26bRegyUcrZAsCZGZAxmJ+/9Td9nr/V/wCr9Wb+Xv1cbSEw XNm44EJhjOQBLDmB3F8OAq1PLfHnWGzAqSOVpwbSmYGAVBNHqMKZ5DHOf0xfw9+rkqcma4s03A9M sXyMOoEyO4J9f16GPv5KnTu5U5Vjath4LfeZBAEhWWU7mlBNGOX28cuNGf8Axf6eOX9AdYuW010V 1k17WHoClhG4zYXoMDHE4H6b0DYRyQBkCR1bj4HXc9KHaV6VaP43a8vXbx3F3ztuOcfumvGWyJ7Z 05RI01xVGNf4dY46+crVvN8CnnafQLXKVkxpuaP5KXnARznetkfaQ+vCMxhrMWKjtYmJ9rq7h06l eyrWZU9evOP8caxMT/QNONP1s3/5Rkv/ALN3HjFuy2YwX1Iq5DFSRclpzuHydhNIeXxmDAB19ZtF 9nH9/epM4ZXneG8O8e+K30sf1rL7C5nnsY3a2PvsFHw4xXhnjI4UfIcnTZk35LyOyVfC4jFgbUw5 3RYD7FpzlFABH2RrExPK94n5qzx1l6vhneQUc74xZbYxF/HViOLanKabXVL1UVkcxM6SIzyj2ydj yzx+PAqWAWVpmP8AH87kXh5NladNjVmxhJsjVpWbHSnpBPLX13DpJfSzyPAV8QGCyWewz8cu8Vuc inzFNzI1nUbpKNaDwqJRAyQCLSKJmOWnAnfXhx8q+XOklVZtfJPmvTZ24xLGTb7KW7d3u36a8fUz u0+PRjz8k8iLyokTe7pWc25CdmE3tlc43u/+13M2fHXhN/xWj4svD4SM3ee3NvuuyGWivZt27I0K 1TpV66lDqH5zAMzHlMRx4Q3D0McPlHnKrE1VZW0SMJiox0kvJXr74IHzVBgT0wiYIo156xoWO8S8 wd4vkSzyLTMHmvFLLTrzZpLh1jH5Gq82GlsrnUDjQZ5RzmZ25DyHFJpPu1X0FrVkFvbVmLVxNdm8 K9iq2ZgGctDjnxhPI85iPE1+LZXI4+g7F1LF+xnaS78EwTsWS6dKbPTCf7Lqhry0/e4ueHeJM8cp WcTVr281mfKLDF0kFbBbqtCihDAY+ySWRJFOsRGvpMa8eXL7Lx53lvhfy+5cioy1fwOXwts1wy/j iTaS9R11M3GJsnZ9muoj4hYw9StfpZmnW8gzROFzG0fGHvx6BsohLk7HuO7MCRCYxIcx4x3h+KXQ fjF+PtzueuGD2WEgwiTj00mrsLrjLGmoi3Azcs+WnFn/AM2xf/enxZxnj2LxtryexUQjFrwnitrH 5H5oUAKz7r5XShoQ38Y7yk49InjwHwbHY+vkfP8ALYKu60eYYyKWIqVkyDLOTJJw5zghRDOhczXP 4imBKr4T9QKOHG9l6b7mBzPj5Wfl13tQY6zUau5o0XqWsuegeke2d0Fx4/nKlanaw4eYWKnkvXTY ZarYy3ZUvvKRpspUtiz9nvFkSbA5evHhXjfja8fcyXlF0m2DuA+wipgKy+rcvANa1VLqyvUlTMyM 9Mo09OM54/8ATylgFVfGGjUy+c8lK7KG5Itd1KiqhvPVMgUFMgf4ee327vHcG7xvFT9RPJbt+pSo pusfhVVMfOrczZmDh60Gqd4p6sl04kpOJjp8Yfxb6h0sEY+SQ8cJnPHCt9n3lcd50Lar21u8twxE wI8zH8XORznlGKxXhteh43YypXXWpyfWv1sWmLLk0qI2m7Tr1+bCY4OproERMTrjfqFXwfjFfxRn YxYx1i3es5ux3JjXbZBiujUr1Stain8bRiYIxmNYj6KWFLk1Tlc6fpEyO+th7ATI859oJktfSNP0 8v8AJ8OP4Z/9Pj+2mqktNP7Yo9Zmf9nH+L14x/iynGvuVjkMmlX4jCT0oVmT9kmBGQ/cPFWtVSb8 zcUp+VtctTsGO/tQLZLOhU3bRiOWus+s8dJ2OfOnp7p36f8AV6Ws8uJhZSLB/GlkbWD/AO78Y4xd +jpV8c8/czGZWkPtq1PIVj1KN5K49iyuyUjMR8ZOfs0y2buC46mHxt7K2griJ2Dr4+q224UAw1AT iWmdsSQxM/GON6vHfqC0P414TEGPL19w+QzHLgsHi3ZLFZvaZpxPkFRVC3bFcbj7SU2rlZxgHu2d Tqbee3SJ/T499ObVbKnnPJce3JULCK9UsWtCYyMkNp53V2Vt/wB2M5Ck45jz+z9l9/62UrIHe+xj rqEhqI72trMWsdxyIjuMvWZ04qeMW8f2vl2HyNvL4ut3lAi7j5hYOExdTaKoHd0bBafmxEHtkvw8 fTjxrx+gF6x4/wCQY7KZsgs060b5B7snc33LCOsPdvmBEZI9mkRGkcYjzbF+O4rzCKmPnEZjxbKH WR3lSGuei5RsXNawXEE+Y589IiIgtZjjLOyP0r8f8FpuxjsfSbWtULeeZN9Nipkd00EQhFVtR22I mROJj96C9jPHbf0d8a87ch1gcV5b32HohbrNYbFFmEXQO2DasHpPpuGNsTOm8vCh8X8cxK8n4x5F ivIrnjWJeupRNyway+rHveKAke9Zr7ogpCZnnMaTSuZjEzgslYXJ2sSVxOQmkXUOBXNyvApfquIL WIj100148/x7PG4t4Dy3O5rOJ8kVlKa11AtLvPrVyoMnuHtY94JL8GydS9wc+Lfi+SodtnGY7ydA Ue6pO1bkJvdmPcosNpx1esP+00HXnpx9O7c4PGZLyHw5eSRk/FMs+kypl6GQu2GzWi5DXY8LKRPc uZLZEnu13BAym/Y+kPj3hdKihjUXzt463mZyW9cJKmGPRtSkF74LftmdYmJ5bZyeGwVTvslYsY00 1+vVrbxr30ObPWuOroHasJnmXPjDYrC0e8v1c1hLb0dzTr7K9RFgLDOrbsISXTI45QUzPw4yHl9L w3FefYvPVay8jhbjaVW/jL9RKq4XaDb8Ek1PWqN4x7pmZ1iNInjPRlvAcF4Z83rvxQVMa6ravtxF qvAWF5J1VMVtxN9wwM+nKRiR1Lymp5soRbawMeGYQ+vUsbMGJW3y9c1mvlYzaaswg9pjK+ccZzMe ZIhWcvxiMTX1sVLTIxGDx6qlY+rSc9UQ+IGCiZ3zKdxRz5uxOBp99kCyFB41+4q1dVJYUsLq3H10 +2J/i14q6VUKeuuoCkFKghKFQJxvCOMD9QPEatbLZPEUnYnI4Oy8Kk5PFONzdKttswpVhJ2Tnn8d PxabCxPmnluFR4tj/GadxGFwnfpyl2xbvrNFi3ZsV4ABUIlrGsBOojoPqU3/AAzyulFCxkCy4MVL 6lvoja0mraFlN9hG9LIhg+7lI8+L/l+ccFssPj6nguAaM71RRxIjNtqDmNWAUyECz96SZx5RlPGP G0eY4Dy2783dSDKVsRkMXlTIysTLLINh6Hm4p9oF8PwaTv8AE/PAxWGrebeMW8pu8dVe6la/hcjB JipN5hdsrJKrGYToyVFv3wUTovjxvyDyrx5HiGD8QZYuUsYWSr5bIZLKOEIFpPrCoFV0kkC9wD+H T3btR838cv43oZnL/wB7/l1PvKDe4+aYqK1H+YTaZVV13cveY7f3tI4x/iFfGdTyJFfFA3Hd5jx2 lWyQWHR3Z2xozsVGvJnP4ceA/L/GMVl69SwYZbKXmri348k6qEtfjfzR0a1W/WRhm/ZAaRu3fq/b H2Tx9n9f7RgHziLdktPt6RnIx/mji6OhFADhGDE/vgNGoW0f9TfBa/fxTu05Fy7tZFkLHKZYD1iw ZifgOhenFVkfik9v+SYmP+njuq35d6vHUUwfU9vOVH/FBRx4JSrz/vK55PVvgoJ/MV2UFVPSPWN1 i5G37dOPO/8Ak3yf/gl3jDix6QL5rnfabQGf/wAi34TOvH0qT4eVZ31BDO1O/diyA3LqjfoljgyZ 15/tFELi0P3Cjdu9unGU8C+jeBxmWuYCZV5H5RnWMHCYyzBEE1lCli5YYNWQa6nJmJQK5gZPjD4f 604LCLwnkFmKdDzLxhlj5fVtmURCsgl8nMAETqXJRwGpRviJ0+ksjMc/Er22fWOYeXaT98ceceHe WY7GYnybw7IdLo4zuYRex/VZXm4A2n2GaC0QnXXTY4OPG6njuNp5nynyrNLxmLxl3rdI1RAi9u2s 5LpPubCFjziPzPu4Z9N/pfgMVnPKsTUUXlufyDHq8awdzph3KEj1AazpWC2+4yLd7IA5gpjC4Tz3 w3EeQYjP2e1DP+FE3biGbZYbciFtoiNZKhki3wrWInYRlGych9Pfo7gcdmcpg4mPJPJc21gYPDug tk1hhRqlrVtiQmdSmTghFZbZKMRR+tOBwX93c7bilV8x8WZY7OhbZzgMgh5EXTAPcXtUeyCIeptm OPE/E/G/GKnlUeTYo7SawNevI2LrHXK9RVWwLe0VV3qA2GYFovdOscYXL/U7x/xW14fm7/YujxYr LL+JawScKIY+xo60CQKRGYJbemUb4nSeLH1CX4f4rjfD6gDePxu++zY8oXhyONtrIEpykpb0Tg2C HvVHqHKePFPKcQGLV4vnMP3uQr2ptzm6t0wKARUar+RcpFkZW3eIz7ZmJ+H6NY/Y6/qF/wBaf+n9 fdHrHr+v8oy3d9nL1WCinabUYRqg4ESYrmSp38x9OKmHw9UKWOpL6deuEmW2JKTMiNhGxjGGUkRF MkUzz/a/6eOfL9kF+ImUNZvnT7TjRwT986zMcK8npRDYqrWi5Ic9a5VVSl3/AMo5mJ+zXgMF5DDn 4UJns7ao6j8ZumSNRL/E+nJTrpHuD4axyhb6fkOJOpWHfq26mscnP2psklwafeMcbE5JOcyJzC6+ Ow7QtkxxTtAWWlyVWuO711LdH8M8Uc3eVPyrx7HovM1ie3i9Nm72NJOvLdDfzS+4OfrHHnf/ACb5 P/wS9xj/ACXOsz45GxeyldkUMmFatsqXDSraqajZidg8+fOeHZHxzFsLNGlqgzGVsnkLyRYMwQ15 OARV366FKwEijlMzHH1Fwt2RHyal5pZZmFM9tolkoaymEM++Vxcr2I+4v6+GUrUgWQyGexC8Mj1e dtLia80BzKdlGGDMx/Hp8Y4+gVe/u75H02rpubtd3dKxvkwWN0zz3dWJ148E+qiI6WF8pMPD/Ljj ksTYAor23/f2kAyP/A8ZnyEv5jxn6S1Bw+MnXdXb5CZPWTR09hku3Ng90f8AYK+HH1lw2R0X5Svz J1u+DeVl9LuL6lsHWIJilWyZMz6R1h/ijhSzapbbBEuuJmIk5grJsioJmJaQrCSmI/diePqthr8w HlNbzV78qpsbLbK/51dTJgp6hgF5djX+GWf63GRrXenNu/lcOjEKmY6x3l3BeZIH8Uyuktu7T92f v4//AJrrZHfGQr+BUkXYZr1ItLxuTB8HrpO+GROvGG/52wf/AHGQ485/5Oyv/Dz48E/8DkP+N5P9 OsfqZfIohZPx+Lv3Ui2ClRNq1GvWLIAgOQkw56TE6fHixjMZhxbajx7FZao58pGmyxdcwXdWfmK3 DS2jsHl1IYs9Ykdu5+ITTyFhlRlZV20haCq0220jYQL4myNyRJLBmTBRLHXmUcPprxjLKEeL5jPT Y1Ts6uO6cgJ621nFaPws0CT3sDby3THTdjsnbYrCVs9dZjk12VqtBxWAY4ysW6zNElVKZiBktvpE 89L52K+RodjVp3dlyuAsvVMg5lai6kpL3sPurK+mIHAM3zESMcWq01LuOu04Qb6OQBAvFFrqdtYE qti3Wal0pOIkWTMEExOk8ZkLOMsDSpZWMDjadesl2TyeU7ZVsoU/5t2+2K29kialgCtpS3XcApiM dmDu2MhYxk4oKqJyNe7XpzfNVgJtxXgSraFBiwl7SiddusxjcarGtem7jMtdOz+RtWyhFeRHnbA9 iYZ+d7J/GGzd79MeeUqWsY61gfnU2npBWNsrrV6zckdKYtWLMKrTYgo6gjMr0mNfXgas08hQc6rN 6mOQSlffUoJYHYr9GxY06ZODcDOm0d8ajw5dkbS2IzVPBmHTVM9a9WVcVbHR/OhFVkmRfiiAL28u LVWtjsxkbFJ1xdhdGtXZIJonCX3fzLiomt3UGkY/tTYo9AnTXjIniKtm86rhUZldya8TiQTdRZdS K0zuUWI6vb6bIjfMlH2HI5ldGhev28TjXWrD1VwZjqFiah2Ka8gU2q9ghOIEjhMHIrnWZGOfGJyF egdw8jfxFViU9L8uMg1QshfWs1/zDgtqtZ29SY3aDx201ch0IvBi2ZToK+WqyRlCopG2LEv6kWCh UlC5VDJ27uMTTVQfkF5CrlnMTTWB3d9Ccd0uj1rNavC9to9+6efLTnymm2lVyOTm5jwyvRopSTq9 A52w+wL7FcYmTghgAk2EQztGdOE3gp5O9j2UQyTMhSrAdWtQZG6LDic5BlouJKQWLGCMayPpxOHR VvWGhXrWnXEqVOPQi4Fk0E2xLxL8zttIiBmZko01jdIppvo5KFOtVaUZKK4fLht3dsVkSwnDYPqG YjuBZLE50konXjo/L8sKPnLMBOQKvW7EciFw6IL3RcmwS3WB0EhXMRrG7bxXVj8fbco/Icfg25Ry A+WSbskqleWgxtBaJydTETlfR6g+s+k1KXa3btq4uw8EUVpMxr1ZTD3lDn198BLx9i97S15DPEo7 e9NUcgOKPKwpXy1eSJgoimR9fut3clCt/S6UM9u7XiEdtf7YsgWKDLSpXy08kBkkqgl3Hd69wEq3 9LpSz27tf2nPnx9nHL9YltCDAvUS9P8A28Q9PvpWI6LlOGHLgpiY6bBKNpKavlz9eG3PH8kidSI5 wV5vakGus7aNs/ybK9fQWSBxHxLiVs8eyYQM7d/bHKf8Tx1TI/frpwGSy+wHBzrVBmGks5/2jJHU CZH7sRrEevCK8hsayZsPH4wxkRpBfaQrGInjN4I3FWDNYjJYk7ABDDQORpupk4QKYEyVDtYiZ56c VPFK2SblVVbN2zFx9cKpnN15PkeiDGjEBJaev6J848P8nyv0/wDMWhsu5LEALqeUjQY1yFCW14Yw 4AYOd+w9NSAi58Y/y76keZ5X6jZnETDMRWv110cLjXiUMF68ctrlsYto7x06YbtJISmI48S+ox5V 9ex4pQuUF4saqzTdi2F8JYyzLRYqQ76eUDP4ePK/HS8hx+TzyLi6WPxePdD8knyOlaDp6KiNRUid wtZ+HbuGJ3cuMTTuplObzMlns5DI/PC5fAJVVdr7upTpAtZR8GQXCvNvGfIcp4H5stcKbnMNEMXk VCEKEclS6teHl0hgN2+NwREHB6RpiPLPqJ9Rc95xkcA4bOFpwv5LjaNoCEof0alk9+sj7hDpQz0P ePLgfOPFPJMr4B5p04Vay+GGGoya4EQ/3jR6teHMlYQMlv0MYjeJ6Rxj/K/qb5vlfqNksPMMxNC7 VVQwdF8FBw75etr1ukWDBaRCgkojfB6Rx4h9RTy761jxKo6qrFhVWxN2Hd772WSaJp0734DP4eKm Bs5V+ICrmaWYiyisu0ZlTB4QiVsaqIE+v668tOM14uy0dRWZxNnEnbWsWsQNlEolwqIhEyGJ1014 wniKLzMkrCpekLrkjXY/r3LNyZJIGwQ2zY09Z9P1NY/Tk8Z1eh8xx9yj1tnU6Pd12V+r09y+p0+p rpujX7eK2TVdHprwlTC2ax1dSeFJllyHqfFiO3nqWp3RsPWIjnHFXLFcrLipaqWVyvFrHKiNXnNI cuuws5x9oteotimTMFMRMcE6vkRok7B5fAWepS7yGVMrCZkl/wA3V6TUNRE6+7dHLl68ZT+dlfzH xNfi0fy+/owHzH+dn84erM9//Z+38H4ufK3FizMqtYLFYaF9uBbDxN+xkUWy6hGt8E9gaqkdswHO Z3crJwGHh1jpCU4jBVsIrpqgtIYCnWWuIiLXUmaR+7EcW7dXJdtkT8iZ5FQszUFw02uxNfEWKj0S 8O8rPrrPdoSp98fEdZpZW1ke6yS8nayt58VBQu4djDMwiq6VQ85poqV9m3Umz7Z1/FrGOuquRVKi jJ1GAVbuIfVyg1ReIz3COg4e0jaXvjnPt4wdSzaJqMT45f8AHXCKelN1WQp46k18F1T7aYXRn2+/ 8fry59bTDGQVu1U2h49TxVqQ3DJMt21Ncyw04CNdvSXPrt14t5JtkhXcwjsUypC9R7lgPQvKQzqR pYRUtGuI2/HXXimWKzk1L4Y48dkbrseFvv4ZbsZA7Qpm0qatvvrjTgt7I9+hQWnGZxtW4SK+UwWK wityIadWMUF0BslMNXFkn93qUeznE8+fLOdhmYx9fyKp2+UQ3HBemWRR+Xi+q3uq0o3VRETGYPXT lIzz4qUFWu2dRsYu3VtGjuAh+Kel6pbWhyOqtkp0mN4+vrwSjyu7DPygZqzjuxGGOyEWAvsGLs2C 2Um5FcN6fTIv3d+nGMynW2/La2TrwjZr1fmM0ff1N8bOj2fppO7d8NOeKEXY2zYx2KXiGNy2DRlK 70KYxy2pqtsrmnYBjj0mGHEwWhQWnG1Vmilc4YcOI2MOu12MCLo7rDim3RVjGt635kCJQUDEctOL t6LEs7yhh6PSle3p/KRuj1d++d3Xi36aRt2+s68vmveVueUxOT1fje4yKvlbKp9hVyXeq6GOsdtr K+kWjCkufpx23ez/APtX959/Q+Pzn5t2W3remn5fU1/1tv7vCUJzIqw9fPIz6seWNFjgcGSjKNqj e7tf8qyxJ7fytwbvUojSVI7qtXWEMgpdjQuPURyvbax1nuKzsfeTs9p6mPPmE6cHeCMU1LchOTZ3 mBp3Mr3Jn1mwrMNZuBR2Pf8A2RGGvtKOXHeqDDlX+YtyYw7x+m7LLe1pWOmrMkzcCFWS3L/J6oRE RB6R+39f1jQ8BYpkbTAvSY4I8a4GrmeSLBbGD90M0kDiPv040mqoI/iKyjb/AF+wiL/NwFq6wbdo OawGP5dJfxRu5tOPhM6afZ+w/vOvw3BhnOv3cXhqR7be7f3Y19e0G1v93UgN+7nrr+21j1/Rnn0X xWtV8Tfep8iZSvo12MOVdNqSB/TGemevsPQtC02znb8WqFsMV474zkLleyq70Wy6MoTRx6Rubabr Ij+Y0pZzAfbMfhyaaFBtlGHs16zaisFn79vImaK1qx2+QoJLHY+VpsxsFsHLJjWdozE8YCIflkqs eR1q9qMIy6vIPrljcqyUKjHzFpmrFjO2PiPA4mnFoQymQyL8LZ8vXdddRisbUx83O5RLq190tyFq Yr9VglC9ZnltjiuAEuvZDx3ydDK297MSWZxeex+NG3C4NZPr7wnbOu+FnI7tdeHXBrL7bD+N2Mrn 1xBS9OWUTg+UVylsCslFj7EnuE506fprw7MZEMRY6qcdNBFGLlfpWsnaRUUm2x7bMPrqO0Ek0IXM xE+zhtS4OFtXyq0LdKxWr3q9TpuzuMw9pFuuy5YdvH5lBLMWaTpzHlpM9yOFNFTyuj4zc6Fe8ttm b5Udtqt1LrQqRXDID7S63UkZ/Bxj7TxV8qb8wVeaUH1lPTj3XqPTOD2CDppsXOolqZhpp8Ui6hWj JVq5KzVcEXWjWydnNIw+LBS65vsdu2Oq+R2sYwBER0IuCr2GW6E4vJYy9GQRiMzg05ar+abaEU8s QviOorY73OCQKPSZ5Y3FSqp8yC7mFeQQAO6VWrifyxdWCXyS5yDLdUl7yPQDn104xzOwaWNysv2w vCZ1BYtYra2s+1l7KflN9bulAF0tmwzjSTjWeLlfEWqQLV4xj7hV8nFttSW/MswGqlos1xrueIRB O92gjHtL4FYxmNaYVaeMstoRhs7krF916inIMrVshjUFRx0rU+BAnCfULnMCPPi/TxwY1VPEsxyr o5FVsrVor1ZN1nQJDVhT6FV46SQN1ZExpEc+MxmUqx3yXC5K7QbVaFmclaHG2e1uOXaF41kMk4mV BKj3RpqUa8lVkxhBVdzvkGDqy2veliPk03GBbsSN2BfvRUmJWML1PnuGOXGEjopXkco3OLa5OLy2 WrJHBXSotNeNxxHfPuj2TGrIFcTOpTpGqbVuo2lZknLalqLNbWUOYmHrTcUm0CLIhDAgxgoEtJ/Z YHJtsyrBzdt0c0rpJLWLNB7cdZ6hh1V9C7VhftIYLr89eWmLx+VsKr5PHlms55P7aa9uBr4mtlMf XZJoFNZJHnqyZdEDP8sXu/FqCKGIqVr8ZPxSJi3byaq78bn8uWPHbN3x2naW1jE7CKEGsVs6qybp tnym9jMapFPEU/Jq6svOQWdtWVwdS6JvjEuoSltJeSqysZJskXrKts8WMXlMcqhdRjMZlVlXv98u zTyLLqAJk9nT7ayDaBblx1BjWNDnhtdVXGlCvqBHj9dAXpHu6U+JWMr21tzcQc1Qh3SfLl72bty4 GRGJZQl9bG0cpcv53HnXy2eTjMTXb45dmjkZnMupFLYJ0h0YGvvZv5wMQUxi/JE1d+PuX69K+fdL mMcDL54p9wWqFqb1arkRiJIZESTMtidI0nHZWVORh5y3lCJJLK7/AJnjPH8Fmbp39jKnUAW28UfR BbB3DAnJyJbOFWc5Qr43Gf3Yu5MKaMnXuRYttzPjmOx02r1ijQigSiycgz3EgYZu3Ft5HVq1Mbfz HzKhja6cVn05HDPPJVb91LCzaqQkkVV8VY6ozWlgyEaCW8Z4vDYqRRvYvItxeQrBY7tIWV161uCr WujXmwhtW4somVrLnpIxMf4BfUsrh1a0ltd6y12tS4JW1ZaaToYFMcXKnaGaMhSRj7kNuXnG+pWm zKFE9tk3xK+7PQoKD5+vKNO/dXZ3M9Hqym5drKs9vOqO9rVrCq17o6e3rAekcUzsq6pULY3qk72D 0rQJcgW6AYweirBxoWo8/TXThS76JZ0GdVDFPs1LCGbZCSTaptRZVuCdC2lG6PXiuyjWXWdToPxt M46pAmtYamwwCV1YF2+xXEyIvfM6+7nPF4Wkq5ayt21fyb4qhWVZfa5EI1t7tiBVEDAkZz6zMzMz xarKo7q9xEVXpsWbdtXbDukayQtvcNZASXIF7BifThyxpmyHnTJp2bt+28ooWQt1F9zatOsChNlc FC4KF/bHDd1WJ6+Vr5pv5r/dk6na9C1yZ7ZDsl+2PZO3nHOde0yFcLVfqpf0jkx/NrsFyi1WQF7T H+qY5TynjKmdFRFm+3+aSUsnuu0X0q0zG/RRJH0kNs7vd+LnwwKov/NODadm5cvvMhGAHdYvWLL5 gQjSI3aRxcyqawhkMguuq5Z3MknLqjsQO2SlYbR5e2I3aRrrpHE3KyDU3c4xDu7pVVHY1l516B2C o1jbrO6VrGZ147y9WYyzNUKRMVeyFXfUWxzYrMGpaQDEyywUkJRMF8ddI4W4qkrJSUV9tazcppZX q/8A06LNao9Ne2pH7otE4iOXA37FWStD0Yk12bdcXRXPqV4tprvUi7CTnUeqJ6cFffR3PNy3uGLV 0Kj7KdvTs2MeuwOPsWB2x7zURco4Q0K0bq9+/k67Oo+ZG7kxsDdbOrNJlw2j9s6hGvtiNI0TT7Yg TXs2bdeUWrlexXsW3OfZYi4h67aesywesCcRpOnppHCTrrICr1jqK/PsHEIY0XsghY0hYw2hrLC1 Z9/Of2TsXlqo3KNiVE1BG1e6UOB6p3pNbR2tXE8p5+k8uL99tBLLWUx0YnIMOWENrHRvjtWJk+js mGTE6DElHKfSOLCzq23dyqgljbGZzVm0K8XaO5j4r3H5BlupNSyySCVGExxbNlJs9+m0m2mMjkwq u72odG24qYXRqRdfVYQlYgIfOuu/Xg8gtO22yjVxpN3tn+SpNsurJ2ScrjpsuMnWI3Tu5zOkaTlu 0LvpvKyUnFu7CO/TQbjAudlFjsuv2LiWRdP3xpu1kRmBXNVqtl+/k1vqX8jSuKu5Swy1kGpv07aL qRtubMkAshfpGmkRHDMM1HWxzqjKTUOa9ssrNCVsBj2MKyZGJfjk9+vPXXjF05oKmrhVkrG1ylhK QpmOfimLIJOYsgePtGuYbv13a/i58M0x7W9SizGaW8llbwhQY6tY7ZA3brxrLW+msl9Pb0pH2beD oMVbeg3Ks77eWy9y6qwiNEOrZK1ebkajEx+CVNCR+Hrx2tBPRVLWOOTa+y9z2zqx9m1ZY6zZez4m wyKft/wFymP6tf15/T6fr+k6T/m+zid+m347vTj2GJjP2FEzH9en9J//2gAIAQEDAT8h6nxHU6EY PQ6ktK729P8AUuD8B0JqV7zp9eh8Cv1A+gEHqDLQpiq7X/H3Op1OldalfBfau60dkgOPIvz2Phej Avo9X4TqdTqfATiHwbnqDJ/Xt0IvodCIPArpMNVeAjb6BHcjSODBrTMU6KiFXEhCnAyfE5emHLDO AFsyZc82L4ssCoPXGTP/AGRfwIyi8QiIUw5iuEA9zcByeIxA6JJ+8SCVIwvHw10BXUTNdLQXbPeX YUiZEdeiTV6QD8f2QQChHSZH4F+B6sVL+AqELl/IBttwIqSq4DbZk7cMyuikM7TnEYeZtFaoRMp2 4EGhhWIFgJyQUWYREUfAdT4L6kNF7PZiJWzqPeWQenOowL6QOGX6dNVw1igOG8qjjc5WA1S90ckV tCkKGjQkMAajFgEFrh16Qk2VDW0Erm7T1YDaEwwXwy8UYWMemTdQC0wghWVJj7klSs/VVyJSoGrV vOZSKG5lPknJolpyP+S2LjMswVgNSc5qCl2YiN/D6YwmiMDym1socHhrGIKsMPDVAzUThBmIypc9 pHMj1rS6YrH4njuNzDF9PuGjZFEvKdUi0lhI/ZY7OoUZMplmvLHeTSqQaEemorCK9IgBkSffoaxc yXssoULjkiqhzPRWLMQW7x9C3AEvKCAnfo4rXUNkAM9CkbcGSNSpmatU1bjKxXAtANFnyWalhoWo XlqYldE88crK9uJj30XT6cur1er0ueOqJCS3gbEMgLTLdd5oH5yvRF8otspB3RndgKkWG1l47tGw XVgexPuxGHVcnJcCfNCwEhSjBQgFFckQxZG1BDMIvCgpqoCRW4QnWDy+TlEVuYHRbhBFhYhVwgW9 SQep1GU7NPuduh8Hae1tOSgUByhBpnsGzTQS1/hpRrcDPWloiagpaIoavPKl0SZ+qjDeFEssnOQy AV8hWhQ3IN9FXdR6xASrRuihlucxjwZgElHfzOqkmlrH4O5CzSvdYiNjRpglD5mvnZ+4wNfPIOUK lbd5mj4y47U4rAtKLcTtouO2QJZSwZle9pNehoacIws+YVZqWR5ERxdJM+Za61sW1ACbktdliInW AxxLbBF6aGGzgYSBvxpmTkRRphE7+5IBW77MLIGnwdJubwcqwZszB/J/cDmYqQvWjgHIDJ1fKTsV HzDcW6OapKJITbEH0BZJcAMIRBAJ6EFhH+WoyAQ3l7E72xcu0i7qaWcS9yM7h1ogA6BHpXSnPmOH ZMXdu2H0dPxsuwe8rrmcPWcivA+0Tgho5fvxbtmUKCFaWt3xY1zmcA+4H5Y+sVckD1ToTXUXz4uB JyDrraUlOi3TUWnXWEEWMcDd+8BngxiK78ICHKcRnzVi+uEUxnsDGamrpqTnyYAkc/Ck2XhyQRQt opr6NXYYrb6VsbReRQKl4NQ6QJKgvOgXkZplxyDIMz3zUkfiFSmgVryTm+UNiltIyFTE5xuJPBUP IjFgIboFMQpfWEC6AJ6NUSxNM9pm64/eyyDEjtYJd3uTv59eh8A9BiunudyGbP8AnXD5XKXL6HWl xGHc7+p1NQh0crYrqhgQ7MmnYRiohKluPxRKV6XN/ATXwBc1jZ2yP7Jrl/qSmQieG/g4D3i9Doit 68ELaqs9+zNvbUFv5TnLbqXQN1uvyEM5daMQuNUZlxTpB4nki/WChaNRGwaTERVA0s/ENizws2UG s5PL01Pde+yHD06SxEOx9olTF3qRG83gzrfE80B06UpSit7J5wTdjRBHKZuPZFSq1Ch8oHc3BYBq W5rcE09ak4GnnmIlobDGSxigapZo4orQssLL6F7xzwAtxtnMpOM1z6DYPcJSOiR/FBr5ubnJQ8nZ 7RX8Fi/9+fs6D0F6jZVG3QraBzMEzsgdAFWri2wUoqxx6cBX7l0D+JiLCXObnomYddI11DqOjVaG cMMOPVmoQakZjYXY4ti0CcqihUvajitt8fLgor/Nt1IX+VMeygIqNbIQ5iX0Ca6WN5DyQGRRyHhl BTjU4PpRGM/WCJDJoj7/AKN84L2tqqqaka4a7znqYOu6JiDpmuTRaEZE+GVRqAAAV3ErOxlNDvA5 tHDHaXmbWypyV/LKoXDVMHeeHYMVuyjBGdWMb/HlC7DeHhhsxtodAJM/SGsyUVGxrADuunKKgz7L qsHqq0CnGHUUY5K6sSXzOvOxGauLA/bFHOhbbGxAmBsd5lYYZLR/CvpXXcTkKPhgf+D9oLu/V/ZG +x6xlSodAbfRLX7BwmSDeW7VQRqsC4I3cfU71K74GGNJ2OBAA8Sg8IkKtCDmoTvVLQ5LQHgCsxKv fluJVfsJPHLVBUWL03oVenUN76K6ReH0INHBiiRSxjI1sQMGiRYxKV3RiwGoyWxcw/vezFTt6jIr pwSTVwKS+oMUjHsnCHZAgEcZkumtHBBoUCJqVg7bRzQ4XJVUeM99+incVhD+9c0JQq7FundhBDBp oLrcyhhlRLMoeaSmBeYWask3qHZC4t1GW93k7+nnpc+QA+5hxqqbiwVEWql3l6YMqnulQuW/jES+ wdm6lHjo1qltcBgmZgezrDsw6N+XZ58it4AKQrsNDyZeUhuW2p5Vc1ou2xxICYbtkZXSitmLBSvy /W2mSoBYsJuFek6rNByT2dJKR4FWFaMsSUAsdiu6p8GhTVIdDpp1/PZ4yMwsLRmRs9Gro1bJuJqe FEfdupV9OH70wNqwwlOi9eMhPFh0mDb5qdlsSPrTBe4WHGNh+AQCICbNuC5O26rBsmgLoNOPecgN G/2JKDg1YHNHB18pMuCu4NjsypcMoXIr5K5Nhpmq7OlSuRPZ2+nhbVDlEViFpnyeuCOFdL6h8Pr1 9GBcvfMHyfP3nrHW46lYFq+4jkTI5I7Dihb+/Et9dzKoN8PRT/VHzAMQeg8IA4Wz138BARqxtRc2 XC+oPgGJL+O4XA/L1iKpKZbuahe6p/dHYlAIigKVz38m5UIQYrhWBbjNxP7ulyatXfogpiGOQN54 iUBjEtYBPLUJW0qpBNQWLdW0BiMeade2ISAwKgKcMK+9o06cQvYpg7jXl1zAXlKKl+C4iIwAjVcM iCDYn3MGoSmGLrZrgkaUbGuApI7uY6twsIMO7FSwXh6tpIrRC9ykSWokfYGgEcC8JPKUB/EbKN5I YzSE3cCh66qDX1N9w2ENgNtPCkmogMpYhG4nfJA2AwJqpB8lOiwScg9Bgy+hL6nOA2SazCTSmkk8 URmyR2FXa28GV4rCq8EIKnRobza1hmAVlyZhpzY286VgqrDpEY7CksCvRS8eaQIw08lLRIq0TE/u +FLoSuGpEW4e8AWQJfjKDRUC+Vp0mHwVe5b8rEOIgoAgK05afhbBNdLg9Lly4MuD0uXB6XBly+l9 Ll9bg9LhjPs8k36oKXwBIpGmWnie/NccaAGk2QAtQTdXIaGAwVLKR57nvV5XAg0XbUli30hJViZB /wAIdhHQT4L1Q8H7tteCWTJy8Ck0kvlLkgIQFkHvC3fdxMoo4eODGkqdhq3mLUEeQ0zK7LygWHGk eOhSslZS2Q1AkpJHPV09BCOeRGkYY0rHBDk6cR6cFzBF7Y0bJxvW45AQqAPWF1zKbYxLCsQb1thu qg5JxlYPnmAW0ctCXYQU6iMZdRXTCAzM6czcebQrqD7c5ONItEs3rZFwZfwEGHyrYcZnhmg2JEVp 8E7JX40KiAZQ6EkddbZNXQEE9izdgsGQHIuGjMO4BzOsXCAEXOKscbgiuFrEAJVkBcBzI6NHlJKO m8UVaLO6jUzjGhtrKDbYAwrFlq+s3+Z1ZXhN2UgXd6EKlLW+dbMiubgqEA0D+A6n8Rf8OerVN1XN 6hMu9D7fDmX4gEXFjlweN+ehfF34hyL1r4DqBFmJQUXJ7QIM/FgeGWqb1LHpL0KK+/wjnUt7TPmZ 89CEz8HEz0Znpnr/AP/aAAgBAgMBPyH+Aj8R1f4GHxv8d/DfwX/mkehH+Nh8VXNKqBrGPjRVYPwH wiVbRLKuoSsHpUr4BCzR/h5OAm5dF7LfXsHl+0Cvdr+jEMUD2mn4fswE9v7eH/H1esNgf6YPdjBS 2naHtVdUyx75xFLmH2jxXOpu6K9IVW9q1CJKz8d4FjUtUp+k3LntO6fenlBj3lc27on4YS6+uXk1 Y3No2MYrwQHQH5gXbntBDbGKN+OGJLbMNuzj7UvrX82OTPl5/Q/f0mDAC1zfb0IrITe6h4wlDg4v v/cf59fAdTAeJVTvO4YgjS+Upqmr9otqvCZxaSrgBpWRqXg1KT7Jgre5NAahloih0qC22EzlKkuD 3XK6K5aRZY4R5iJbWHCwO5lljHAG7NuZYrAYdKgOWFSyn7+LX8jpTsnDwI9g/czxgs95miUPOjqe FPQ/71f8I/kr4T43fJEXJ11L/j11fiZ2YgU+L5HD+Zut4PP9j8S+MXhj1GIAHaMmfXRNyFPrhP3/ AAn81QtKQLTWPnEvvMwblzU+sXMQ0zHFVN/qPlYrtE4HIt7B9PntDvGF3xAW2RIwuxh58RBdiXDU 8pgtQGOi9GHmbYAvv7QGTVD9psWXV1zUJ01SfuZEoU1EOQWqXzpDME9OZersvKvEwZF5VzqKHACY rxdXXNTFeLq65r+K/wCJKs3AhLGu47iYz2uno/39YNmvU/OocqB5a8vF9jjcdurEf8ar7GIw+6aC 5O+Pp3gmkvB+kK1jX6otaOT9cTyK8tziJwfe45ia197l1TdfaWtBlt9LiCvyuKY4t/qJtmtZnUvR GRP1h4Fqxn3mtYb+8pV1rV+P+Qq++vtL27pbw1O0d3v895Qdi/eaXwm8Z8d5tdf8qlNvCu/FTe/f 57xTZdVvH0i12VVvH0+G/gv4a+NHyTTFPclHL9GG6vv+E/w7C0ucoL/RuICsvkK9tsFunq1s7yp2 gvyb9tbnh/uUiwB7mh6d/wATcXP2mQKW/S/qXmMs5lB2zLh8PSrYMxmx5GvpBHPAr3/rMBc4eTPt uChvtr0JoPl5D7O5Wt7b1Fq3R7ZldnID9Z6ArkN+XECgbOtSvhuU8LtPKt7CtxYAOG6EtUGC/LO4 V3gGj2IeKuxTZpFEAk3BZXpgrefCNQng5CjsU3kZ9Zf1JUci1V14sW7pRGI4IQq2TOarZvjMMKBM vJeQEFapKuKewTu6B7N5qDB3qAbcwsDB8rtqBqFAloHaxdtjTZHLi0uy6HDRZScHp/4Iqs3Mg3kb gZTUQ1ydFPjFuMysAYija5Jc7nk4r2iq9ppz4RNosOKIqYHWntAcQFTUqKOPnncuK8V9JlvmKb+B 6X8Dy0VZ6N8RDF9Tdlal4iUFrueBbFOqSJpMUTA0s1dWOz1QqzT9Qh92fk2pRWyytWs86IHkNwQK ugQW8XUWRt4G3Hrv3u5qmmhwZe/JM39ZZZt7toNFlZBK1WKmyFe8vY0iQriklBKte1VeVbV8rL/9 J6X1z/hZ+D//2gAIAQMDAT8h/wDpK+IGk0F+MRya/hUMupbydRHJrrXwKGHf+GmwAC1XQBA4QFo8 YD6dzg5zWhmJfurfQ+k4Yt/jGhf6eifUzHgLyd/ZpE/x3TMaH0wjjihNO64lKAx5D7w5I7ZV5iF6 UTVW0Ho57RKkaiqF0veZmqTGrT+JbDqugyn2JSHhBYVxzeLzEHYYuUY7xECsoYwzBQVRHUH+GOeW GJmvGLvdYS3ZMVltLpa+ks+mgQWTNduW0AMy7CNvIvw73/jOputYvaGIgl+JfsQLR8otaZHUFS3D C0rJhrO6cVhxNyoRKdpUTdxddGYmwSg+NS0ZJTtAlRvgVegiTFc/SU5FqKVjWUcKCAXLMZJyof4W aPdLoaw3gR9y9KmVg57qP3JiGWGsSt29tW4ewr9T/wA0DTqACjX8N/Df8Re/sx13Wa+cHkrmG4WZ mHg4KsW8Nqy1XnIcfD9gsNW8MQK1HWLVFeE+6asd8U184af8e5Gwl1DNGUxjiLVWLP0gbDyxNl2V BwyCCtZgaO6/WU7N3VcxhphGEho5ePMBVSMdjwjYgKkMHdq/EyqKhGAF2kzVmrq+LjAVd3+piGzZ cSGC0uUx3EFEa78Sl1TWHvMmGML43BVZWVus1dXxcrdZq6vi/gf5b6gKdRjGKFKrQ8I6YPiYoPWG ke7RBw34KX78vFXE3wqjR2nbyAjApVwF559L/wAcX9xCtT2Slv8AbP1iuxrI+stvO/3QNuw+k8G/ BU7x5PtUMTdr+1Sstq/vKUHRT8S3ePpUBVzT/cEO0pxuVsHCD6R3JQMyk5FfaX773XmNj2395SjV hWS542q1+O0tO4PtHZ8jrOPPaa1ff97l9Dza83ND9Spoq71n6wBoq71n6/4oDYS/as7Mu4PqR3+p /wAiw21ThDQ/csAYPDn9RUbV2ejCNeVrwJ5X7FjUsL4LPr2/M1Nx95jWv+g/czZwKzAWcOTy9boi xOKThL+sEp3m/b5I6Yy8OPfUVpX1erNwcHC/iWpSiIiau98Syhgo+k9QXwuvBGsSmH8NXKpBw0cl yHAu1HuZtxHplCtHY1EIzKZh2WwZkG0j+SgmodGghsRXD9nVwybZYLqYFmVo21lFsDbIvAIBHr02 4ZfD1BrWJMiB6IKgACtRTSqNWNa05fAQGLTVGt7SwcgE79McJrCkDpwEyRLlPtfSmQyAOAIf/BQS nUxpWEirbcQ1fD0UeYCpVbyrmBFVhngn5L94DWk248oGkqXNBFkTvaK5irbcubGZQ35v6zDXEA1/ ExQYEouxFLQyNbKQZWmSqODQzEJaFaArdd9nMCxu4J3teYVRkZpRt1RLFBhiWZClOQWtCpaVgLYI 10qbuO2XcrKAKIHQeuX0wrvkDmXKJCwIATTDjDEqOJw0E4haC3Dg2IQHaymyKdDBRolNSYeZPBoA qu6JgIS1pchPBjOM/wDpn+G/wf/aAAwDAQACEQMRAAAQCus4gFQUoiDOgSwXVgAGSDtlZ5fjbo5w CWGwQgVFrAAwGGDA2BggDsQwAwiX9JT4jDmbaGygTAGA40IRi4WKzSwjSqXS8W4FqkWXMAdfkWia GkCmADjBImFQyX8HB0Ak+8mYD84IDKMRLUVNHeSgG2Ax4LyN0mQmSHBkAg2EAtN0WNte4ruWqt4h YEmyKqrEgzGk0CGSmAksIDfreQtL8jjTOw0EeGnKm32y/iXeCAU2eXf1au41/Pi72Ooedew1MgeF GwFt/wAPVJdmFIslhEkXVfnMcbYHK6++4t5RVy+Ibz79Wudvs0EkjtokUGFJJfLtsR0WFXllUMKs OGAS7ZrlbdKhgolhBAJAsBv/AHuf4otBuXuJvAO1BT//2gAIAQEDAT8Q6qwYblnchz6/o68/b99V Z6Y6bHr/AKnH3/UsPQLiZvvn6lzn7fvrsfO4/Cleff6/hDgyha9M9AsXt0V47fjpr6S3IaTI6yZx 5g4ngnA39d9Hiu37v4L72+RmMSzdX1Ke2B4eTyOTzOCEX3Nh4S+vqgvd+suekfPJMuCDvOvWAGug /SUK5/HvFuV03xqLib3e8OE4YNEGWwXG0x+U5Itt/Bs/Pjpsz2B0Ve99dfX4Xiu37vrkdXs79Xmu N/jodFUWwcn+4qfHPUcnhgg7jhH8MfCbV7d/X+EFl1DussB33s7kavGoqfbot04vo0qnQQsd+PLH tNEqjMwBXpGAefIotsoEGn8wR/rnq5mxzBxyujgC4HT9MdAhES1ZJstfzBH/AH0rXJUDbdcO6fov aUeTobPU6O7T47MI4raMQ0RWCloabGVEgHl7zcMK716UgQLJz0WP2noS2IAQPx8UcDWkB3SCVSwB RpoIkxAXVk+jv5DmHEa0AO4mHoobjKMc1Ftl0UWPP66K3611Y47MFF7Hd4PgP37D1DblGUEcb9lr DXkkFTSmpkKTWe5aJqgd5QkuyW3si6JkcIdrLHMJPR+AGm4ZD06Knqlu4lP4g2Hp0LB9+qpDiYiL z2DTAZpKe3qeGDWSDgfSB/Yu/wBzJuC4UvjzF8nUkUAJlB0WrAVI1M/kQQeRqHbSqkVYNY6sPErg Do95eizYLGspMILtwxMG4BW6PhMFAdRA0Q3OJJgqFdcWuyvYNOeueyxSNx3ki67ifjDWCTqw4QWm 2oDwYcmaR2/6MvMppPTtXsp5/DhFAlbZqT8utPbJtCN2kfEenlekwW94gzl3ZpaIpyHEAqbMYw+S gc3nHK0dI1qSL+L/AIkxZnbqoRGqtHRpxyRwwmMj0qJKbnSXZBVRohIW27JbBVdQFCZalpwAdxXM QIrl12YsBC+FUJLvOxxA7O/hQFZ0rcL9GHhAOTYmKKbHogaEdFjbcHKPBJ5bSJ2RHoF5I07dLhlt 2/IbFvJTARdBfkcBUCXQ0xV3FrcVv4hWb9vMW40x4/vqqPxF2vqs0mmj9+/UGC9GVZqUbrOwG/8A Aq/mbhIZZkVKa3OjAyUSCaMCoMWZzjqsWtNCPjeYeMSCBpwvBzS1LjFCENnTOAWTDLZBy/nhlIxN IL3MwlhQGx3M7KaZXMxTAl1nf0v4Qmtidu6GHmWTQev99BqK2utlzHvb/I89oiKJSYRwibHzHx9P v0c1jOsdjxBpPE9bs9ZqiGrYCjBsajpaXLHDSAzBk4DGQwLIJBuGnj2vUJKoCNi+cY2yLIMKwZxT nE8ACJO8TtU3GPMVBBJloxxV92zXxq69RQh9QwocAiHZtGC+OM8ET7FHdVTSohAYN/hgUVT4EPJn tifWKan1Covd+1yrBlRjiiIHEo0e/PXq0spBX5tnMBHBCxKOUkycQNggxWVUOL3TKEF3Tf1sb/Kt uZL5uj61tZox5RlDcazG9I2UGRUFU/G26cODjglAXo8BH4qrmmrgW74MBLqBsVfeznZiITEhAisX 21dJNw5ExV8yvEvslBtuj9OhAuPBg6elHNOIzYMupi1lnjnBLLWuGhKIALc+uONSlzgxxiAK08io ds+D1PErBb8xa+7Y58Sr9O/BHGLuufv++i231VvpdRuz5Xvwc1L5vFff7461CDsoBg2NkHDRMkIR DQaPUgX5nF9mgYQMIDuWYjZFpdnRrLSXopjWri4AAPivSrYI3IuTmZdZ/KvIj5Px/fKcA/H2Z0sF 5cxHf9E4ZD7UVkwMrYtfbF5migolges09QRsxUd3iwxrPTA4Eu4W8m71D8NO2ukAey2YXIFlyaSD ylFE/rzThCVQd1178nJxoBFZkW1hM5ObUKxPc0IN6a0zE0Lpane4g6/SGhZd54Zcqb8GWTb7Wzsg dvci/dI1gVSg6ALeePeXDsPk9HeM3v8AHTfqXnvzn0OnA229KN2kH+6aTYwO9js5XInCdRQzg+3/ AGnvlfPz79AN9bYeBGvhRkft6Q2ep+emj0/7948J5+fxOb6fvoEe8F130N0dVoRBAITHEqpqHoiq LID6PWAGj356BBbUsFZ5qUu1r1lYwXVfPEx+c/6lhzQZe/bBKwqSs2Dtn6DMM3c2+4We5AVoaQH1 Omsy3u/VlWTPL9Eos5lry/WKz+ug1cPU1iDGgWxciFA+AZRg+1Sml6J2ila4I8ROzDt7C7qBaIuA N7l3nt+6hqTauqdaR3FdNW3gNum1ZMttilS7hsmYoXQvRKUYVCodWijGdRiINCuX2xhIEO1kW+HB wic/WB0ErKlAV1LgCFNIS1EpWyUWi1DiSx16Z2/kClQEg3ckbFcQT7gvBXOxShAgL45WYZTSz7Ys WxfRwFBCpVoUhD2ID300mFLeYRqCmgKJqqtJ2ljttsXat697vpjFNQZZZZ2fPcO/c6cDquiT219m 0TOKUQBKVUPwGOpxjxWMfu2wJmkQYQWLfchgY4QWNn8dVioMt6YIAcu72NihVbaBvgf0dD+2KBvs Orfm5ZgHGrQ22XwTxndYK8FH2PqeZK2kHgKkGk6zjnkFPkQTqKqHdTpbLjxYZjJ2sGNYQZbTpigD coqBxgsMUIBqrJgzSqzw+Hz3TBuInpfCOurqg1K5/wAtEQlUwbUH7s1Ub3KXxOAtreDmu+biYUuF H3Zg4bXB4Va4o0Ofn4xJgSzsT652w3SoQINnZEOZUJKPco2NlLmdIV0QTl7L+5r0NJM8UWadShMh 6+dAPjmYiaC/I64ISy4Y9fnzDGXmAvVxV/1AGvrzGguj1Av6yzevE2xgrtEfKCF+tOSJgA+n0XD7 Tnd4Kfcr3qAaZ3CP0q4HQ+rmW7ynmcobmOpzt2JpXKBMiMChnT8Eshm2cElbkbJwwXDuhIkUCObd FuEN3QZXcSQ1HAvA2JkgwDfeAAvUsaPOFFA+tOw/9ikPAFYynstPrnCcltahLE1T5VDYAA8Blyed +qHB5quAgdQVILhoQSyOsjXMj0if30cfK9clwauzLMKOHcRmTrMiD0tWLNIdQdmRrgZHMXe/nBhl VKXBeFpmIEEG2isqvNDW7BBdyqlrAiDgFKSk/O64yXB5SDMWgFFrPiqiabU6CkBxzM862E+rs/Ka 3BG8wmPn6koPdzRfpHHcskx6WSajzGMB6aeAed4zjbTX+HGRi9cQFIo4aaWZ0hRNYpIWxI2s0bAq yA1AU9/hjNvNFv8AVoo5SVm8laqIlmqxqqTTal47iIOZIZWrf12IRh+NLGV+RCL0yl5rUxSnbudJ 5TtrnkSCC00MnOHaCrbOdJbiResjqRrAH7U6kOVisbsMubfhlfjQRZbyy60hgOg2FCpAIqYnMjK3 g1VimBxwRd9CKCcBaVOZKfsFXyMXwkxRinNM+tJINcSyWVbIV4FwqfZpcM91+qe3ijNa9fnPGV4F BzgkU7cSqrGqgJGgP1uflZkobgaGlsvUIImxcsC2ZYPr2+pC3l+8Dg+frKcu/wARQi/8gLl0ffmF DWrgXdq7U/6gV36W4UPTc5I74fci/ecBfRSKtieTH1L6XjGYWaZ2+BXl4Q8JBhBBhAhOKlOCECJQ uUHsLKudlGf6pbmrzxTx/K7zQD0EFelwsadcdu++qp8O4wS4PEBncBcJgKfvrRh1LMkKYfnx1FNe 8G+gw7/rDMFfoe1p8xw4Nj85IO+AhK46QQpmclSsghrGElsLG1NYzZxclS3GCY9rqzGYYXJGfmaT UjIVqV5MYMXW/pN4J3ss4AQ7iRBbFjzSjACCqU8iddbgyprJlWa0WQ9jmgLTNgYZQrwgiBSgdCn0 OEVomM+4hCoFAoHp44iwDTPGwCLGE0mWlQYFF3esySqwS4NoO80fUeqYzhlzuD2IhUmGVvcPUldM LOAn1f7fXCCiXFl+rTBPKtvpVky8gPfYam+JGBrbs0kkju2qxIA8w71x6TOiuT8+koL8xBnfFY+u 5dwHvDLlh2IPAwagSQPbqNaAWMQ84kdEVqwKeAGDRevrCTmsgyQnaA31mLfm1qRjTPAWCNX964gB LgjjJ4ZeSHwtbJhpPBTsX9lxmYGINe2Q/If3/mKqZ8hUErYm90nHTvaeFglGa16yDnKAAUlFFp87 mXNXfiX8ff8AuW409FMFfELRA4l/H3/uWbgpqKSsQZ/v/sRaa6CMS3e+II/3DPNV7wb1BGMRbzj2 gzz63/cvzX3/ALgjqWmpfx8+8s37b6CP9yqEE0n0M5PEoQhIQSzrSBSble5KSMEqrryGGAoGO1AF tFFEDXiM9pCAEUbVEX7vaWyIbCosUdDq9xblLBK6af8Au4LISYiccDTgVny298zQGKR+9VbbA5Dy jmLX8v8Au6GpYKKDUOtQs8/zpjn5QDzM7PPBOUzTmOywENEWWPg3IQ/QAmoqR6uv4vuy5Tkrns0y aOCEzHUsk4e8R/8AjUmlAOvReBP2iGI5C+NXphRRxqCDoFBHC1EBY+pLITZrYR3UMQ7duR/HxYgW ggzN9s/9g74+feLej594OzW/Mt7v1hiE7u0AvS8eIF1k3LHt5XmDwfndE8TjOpL9WMNPVZ1Ps3YB nxieoTX1lJ6jeOD99lxonFMZoBiPxAI6Y0R1WeLDV0aYG3wjhTQAcPBZEkXHZjpLuBgx9E2p3rBz LYyDfO3JUFbiOgYHHTISI4ZSMCOg3sSF3jcNF9utvNQ6JNCwfX6J+epfG/EHHN+eorsT9/bohwp8 IvF/SCuxPn06EEcL9f6g33+j08ReDDzeKl0Y2q873XPowb+ARwvt/qW7vv8A1EQAK0BTJaBVOmQ9 Jlf2zD4b4O/cqmDZefcR+iD0zxE6R9eo5CgkNqQQOTPeM+QEB2glxiWsR1mXlc8dd0d6BTzUHJZi Gz16DTz7C/iNya+eIWFLfa/1PkzPkzCw5e80jC+/H3irQnz6Rvm/eGf9w0QwOcXgfpBTdJxX7hvP 4WJdldp7vG4YBbvO7X2Iq0J8+kBbpp+7K7LjdcnZ95//2gAIAQIDAT8Qhvpp6vwm476bOo30cdHU HHTDDD0LiJzDUd9BqHwNQbIldTHS2HdFhUxLOhb60lrA61cRJqOupgjuGui8QIsNwyxeOhvo4b6u /hNOo10S5WbiX1Gyac9CjMJNTZBpmSjcSBk9yo6QjaEtmzO4ldS7xKxPYYnaJXRcfDVBewgWB9Hr QJ7DKYKFNyzqiFdj2gd41xM89AuOCBeY9iBzHLDB0dQKzFt6modxZVgA2q8Rg8rRke4H6pxlixEd 1Xsae1wjk0cHfSV58ibn0qaVyHCdvcsRg1N9B4iWdB4iVCDmpdPiekbg5j35m5qbINMc5IIOYnaf YPzA2yH3GfnxC8p9Zx/r2mahVQyv9Snz1gZHj1IiXMbBgv58xy6FdVWJk8/aepvNXX4uDKeOVpvz XaXhxGlGALv9EEFPLRlvQee8aGbFnY8jAl4h1vB7zEIFtq1eN161KW2KgGcbWDNZuC6AnDiFUkSn nLH2gbtMZ+b+81+qH3Ac2Er0tl/0wK2r2idrFULL04iKJQ9ihpxLaw+OVo183FitmFNd24YnWK1m 3j/de3MZju0XXcqLiCVVYvGWv16xqS5ZArvXe+/EoB3X5MU9K7y0Co2tTR5lLFrBA5iwLm2uI4Pg NrZdf3M96B++aqNlj6hRxBSlsL9FtB6u1hP2rH5mbNvSZJRa0TAMmaODXl2qBjnPQ1HfQbg1HGZs hE6DfQlQaj3i4icweJVDRPzLVLIFp7dqvCdoxmhwwvoY8SzuNgvD2azUUA9ZwmGTfN/PepDTNFr0 rGfntAZFgsvi/aPaDpqr9oY6kMHNVz94dW7ZU8VfmGPFVC7EO26+eZTYx1SFebjU0R79vEfKkjnn 0gRjsJaI8NRzJi7cFnaJ1hZveP1Lk428mVt385lyqo+fxEVy1ctmqs2p9Pn9xGTS2qKOIkrYV3Nb Mw8FW951/wA9JeaKrqxPn57ZfDNMic12vxfHmKf4C1QHz893ovIaeG3i48e1zT27Vf2ib8TAay5+ TvA6hUQZW0cwwTcWsdNagVF4h1TEGj6hEK7l1VpPYnrcBcRatULPeuZlWqucsY0ePJ2qE0t96oof dPuM4hvqGo76DUYX7TN0RvmDErpuHaJB4iRcROYN4iQbiX8GoIkqW6PVcS2Wy2W9cHMOS4nS3AuB FIU9A6BKqLb02wKJVuPhMwOYsSuipIVPpp/THjX082WfyeLaIwgdxF2cVu3OM5UJgeceaEeQJ7hA hiVGpoEXk3m/DBH9EsQvNlvBnZDDnoGOiTkjvq0wyeYvE1FsjjEyTDL4YlQYnaDww7tRNbpQxAGx gXdBjsvntSc3TQYAUG7QaaxW+FF4IdKKjn9N8maobzUAoSjZtSsYHdniDQriYdItFQ0ZUsrmCmYK bVZsyCJZxzLMeTKlhMmW6MKrZwVF2IGRsLWMXvihxVXEeQKs83454zw3WITMLANi1LYC2uOe0xEF GnT2bDs5LMbhA0RXtGk1u8e5mYBIKtduQwOap7AmYUEipewg1hMXvX2tkgOBeRdOiel1nvKrBlvg 9hx38azPqIDbuqq1mrus1DkIFus5XQvBVStDaFaXsUP1aMlsRoXAuV7FD9WjzEawKgK2pV4rz84t kuAXLQ26r2Ua0Sn1km8L7Vg4v0uApAHU8El4rOMXddoTFILb23Rge22juxax7o8l6rWau6zU5ruh 7l6rWau6zUCVAlxtJgmWBKdsaGItwJroHePaVHoMdBDpyCjBqCc+TsxEyzmfAlidinqmR1aw59n1 XUD0G7i3vl0cCiybAOJiD3Dn3bndDMGmJKmmNe8SugXmaxE+sq5VTDNbmSGZ6yoNShyRqO6Gu9Nx CsrBvV0JVZ13JZBLD1OcHDhEmtAHNZt4bsY/O7rfZrxvzqckCxfYI8YvN/iY5dV7d/UA+nqwNW2e XVggjWEa768y2pogu6q1cZVu9faElYS3VNq4bM6x6yqrDObqyrWd+NeZqAXbbHsNUfV8worQt4w+ xQf1ExY0CmgVdNlAaNYqX27ad4Y8VXmDbJLDnBKbzrXm4LKwBLrARzT37TWY67apWq2YXfmoFFur 7Zfm5YtDdKHWWsmDg8VFzUeKl6xYXTGY1RVi/Z+Km1O0psy0bF7vWJ/bHufuva+YVthp6KwNVuq5 p8QG0V8UHwKQPJh7JLGqNTKaL7qxunkliMDB4BXvrDmnddB7blLFCNtQO89Jg9YxllRe3Q7ovB0B 6pWYddC4YgEeqD7bPa4ksZ7H7AIoNfbyO3g9PrBvo4my+Zp0SyGNxL6DTEvJBrDK5JhJSMwzW+g8 MrtroNQjFsier747nJjG4HoQwlWVhpkODG3PcbQKjWyQtOwzVV5SGumjSoh2cIvAsgqClKaRQ0Kv zcc3bevBgTmn7WXUBWa/ZVWXrdKrmBTmmy04CqAFLThvjMps4CKLgiNB5Fe8eYCNpRV4cF3T2rzC KmmHalB+ljvQwZKXcrCwtlFmDgHLgmNCmpSsZvDyablhspra8HHZaqyECqY+fhYBpW83YcSqFkro NeQbDg+5F1UUBpAKWpemaqvLG1U0YUUpmzNpwmIkVSjilLCqt8tnpFHMHkzhgxjLvOOGV5FOooa3 6DPGe0Tmw0iOy6sss01GB1F7y5SzRKTASdpbF6WUcAO14q5dMU5AXZKzT3mQTRgdMKR1bADAAqHC wJE5AHCtwWyHbNNBYLr0ooWUpbFoSm8JVu7MUIGEhFGwjblgnMAEXAnKuKgoUGKIKQ0U2vt8s6o3 BqRYIxTUy7urnoE8iBLQEbwos4SEFGsIAEboSkpEblBwqZRCQIoHTPSiUQiEqXXpEuBUqOCDEuZN RblYxLSbZxiDmOpklzETtBqLcKgB6DY+SdygMBS1eArgxr7y/hvVg1e6UUvwkFR1gfJhr6hG1dWU 2CPqIjLwSgWsoJvjCnbxiOFhgXaB5xn2PtD2RWIA33aC3y3KRQVdUAZKcAFpi6uaa0fDa7NeXO5d +qJ9cQAIqt6L39fPpqLjXBigD6AESDbKHa9yw4mOC2tW1bXll9qveRZwXkc49oMhsVcgtu0UUXxU uLz4Gr3Sll+Kho4KMFg8FKHgZfJwha1Sj2o894G72gGwRAAsSmgOIelEW9G6r8caiYhv4FoLDodp thS6BlCUg4c6cKS2NUbTPnbDKNFpQqBRYiAGi2rfqmHesRbopruVE3KI2LlmIaLW27Kq6wtdW3lQ KbdtxfUD3gJ7DZQIpAFVZgwyoGhVAFxEEliKRSpR2yZu8zNUQq0FAl0FQzXfBmDXDHBUoAMMXtul zXjYlsGfI4LqrZmPEr2ATW5Q6ziW+A+JhfPwO8QXnonaF+0aehcw63MzDuJ0F51MPW+83rHXMvxM MrzOemZmWy3tLe0F7S5cpUt43BPDLe0V6C5XdlHeYlkvtG5nmAS+0V8xu89MELvM1qNcxtrUwRv2 h4n/2gAIAQMDAT8Q+GmGv8BIn8Bv43f8DD+Be0CB36KEG/8Ax6Oin4LrLqFWxPEWAhe78TAbR8Ol nwuoagtoQKou9TqbaPh0y6hTfS5bFhAWvPQe/wDgt1iY+qwKq0EFGJotpyv5MTJQC0dEddeUWlZE Jy8NCRVCrtLZ0Aq0vZJSpomSvGhTwKREBH8a1/BUpmYfpMSl5D3HHz5jfCB6Hz94fzBdugl5gLDo n9wxk4C5T9SmSwq97YfE7Jj7X/U2Gxy3nXiUxynN2+lRapPPorawpuOj4cMf02VuV5vQrNly/pIZ dPQiOHDe4ncmdIhb4w/uYlGx/U2+pE4CzFUb+hKlWuXHrAoWFiafrCjTj9HiVtqc9uXFQaKbtt9i o0RY0XjHP+v+QCXYTv2zBKNl7zXYhAAxxzMk4t/XUv8AnUvVW39f3CWdAlg5RYDByBbL6IDoyk51 FYIMTth75/Exjo7HCRfcvYW64QDZAFpfyEuBT/EVYbRgwKksyd+/pAnWguvfcIpUpXPkuAlEqjIu d6hdkcWD6xdNQUa817wqPg3UUWSbs/H2jItMMc3XiZijbarIvfUtsCN2LftF5Wk/PmGDsCGYIMjV j3LguSSsbrzBBs0ek5JKPYPEo1dj5zAAxmoUoQUnchugMF25hGNLfziMOVCnoTLlb3SMxHYcXsfP f58Q44uXascxnhrkxHkHDFnf6Q4AhtePSBKOlkuvSDf8L1BrAn0WoIBnDXoXZlefGJyGgpAunRZX iYHu6nlpic1w97iVMo7QO3NoDII1Zf8An09V/hMzPfLjEGHQ+IOg38K2bV/DfEEkuw++z9kTAAng sR2SfIxmCdpqqUBoQKgBEs7awo/suFGlLxNYD1YVAushkJsZQNzT5cUWFsXVIa/lH4Wr1lL8FxQv 1C1Vrnm6472PFXckFApVFll5vXIV5i0tF3H7a74u0rmI0lA6FA3nKaqFSNAcmxaEy7cU0+I60oLG rp04Upp5lPTFgGhe8NW6AKb2CYZWsBRC85rXNpzqH1KV44rzxzjkq8x2K2RMqDDK0XzxMwgWWGTu Uvcw051GkvYPcljvVZveHEtUhug0YXZi7O9jiKQQNq0RS8jxrf3qmbDKGBqy8j61x2lzgCjz6p6H neJxXYGHZd3vF1V4uE9AKjePJDluXAaABYd20+hbhohYIZAwHdtPoW+INUSAqVQN1m/HzmjVyQw2 dG78WCXzLfMmisq73l8etSgCNFhyo1m7O9VcNVSLRWircp30W+JTi/SCt3vF1V4ucN4R2K3e8XVX i4HLLJvcRqXeutSmBXS110uWSzoYOY1MVxE7ssGA9IAg2JuU1/GAUA/bNkdBiDANYQYcWH1lwMdZ dERdWBQqooSF7JZRxsoOA/N/4SQv4M51YXurKihiARW6tG7xvsxFAUj6HGWnkRmZApxeKeSkSab0 DXdvzrxuW98Oh3KPnNY/uDd3dnT0W/r6RdtTBaurCEvInp9o5YC01V3gM4Arv94pFEDV2Uvkpx59 JYla3jdgveNedw+ZqiivdLt+h4j5YSnnJ7gUgDBkG2y3V4bV27zcQp2kayz5u/ET0QFXxVmSsb37 RxGkQ1eUJizt3manNdTdr3elzVeLmUtBXfD8VKBtaICbwXhy8wcRBzWreaIJvOMzOF0Pu/NzWHeW 0YLYVareY/rH2P1fvXEbyiBXbsXer8YjksB5s+o2InfJ4hSrrYW2/uzqzhlfHeDlv2XrFneWwItT crrUDo3xA6LXw1K+kfmKZISg9ET30+9QVSR3aPsr9oNcHRwe/l84rtz/AJCYKLb9D2z2eHOdRTYD 0brPDOF5c6MdiOFQq9wFpCmHF3fgiCsojlaaMZmWNMVlALssXLi3XtDoUUqzgbeT701cVCF/umWH 0tviKIuygWUoKbuzJkrnETb6BEEMsEtfBv2gPCDobbrJnFWd78RnStd97BT60nqkoAFTClpDRbTl 5UoMsyg21gR2rLw7KlfjE3wcjPN0u8McrZ+DwVZXrFUvMsRQLVq9hKXv9oEtUJVhsGhFG8Xd+CFQ 1d3dtl4rVD2cwxrQTNrUt3R4KfWBmILDjLLnODWM8kswAuQAvTyZxzjvC7suKTTV0007Lii38XE3 CEMpWdjsE5UZhF12+kGZO5CCIVI9CKIB0JYjQCs/IXEQSo6FDWvBnM7efHEiiJMcWY0TXvmhDJOJ I9uYcxV60kvh27dZfbNCDqLBsTgXHFUZLyb6p/KrS2JbQiRb0BBQIPkKEJv+KDJBmb2E+zXw7lS2 DZ/kIjtFJ4YHqgOVsLrK3y+ZSx00pdasGmvIxtG2w9aT9sIAXTZlE9ERlMgEDwKPvkHv5hAosqqt fGce7FQwKRVx2LWjwVABMrq7VcNmVWhNajlxs8tKp+x48Ssd2H6Zii0XT1Vr6ePXcHS+e6r9VWAg YC3vWpTenPLRe6Lo9iUmWlbTGcYTGYoIpAMKFGhBBrzcqZx5S61YNNebjyYW5aU5S6XykpAZEN7t b72+O0UNaCpSiKq0jZdvMVEaK26u/wA876ESj4Aj0ZDa2B/FSsolSHchBRLqmkGxWOC/yxiPHBtE XkU0MSUyY5psFUhqdXNSQJTZLlqUBVy7TI9SvYyV9CdjC6pAC9uUAIMA9DDhSi0SgHqaCuKm9TCD WtTKhsrxDwDJKZvjkGVDw0+EUxR0ATBoWSt2FFkvxv3hv/wH40OOtvaesT4HXw4j/AN/H//Z --_004_F5063677821E3B4F81ACFB7905573F24CE2B0B76MX15Acorpemccom_--